というような疑問を浮かべてしまう、データチーム以外の方に向けた記事になります。

データ、すでにあるけど

昨今（に限らずですが）、データ（分析基盤）が大事と言われます。AI 利用のためにも、データ分析基盤を整えようと言われます。そんな中、次のような疑問が浮かぶ方はいないでしょうか？

データ分析基盤にデータを貯める？データは、アプリケーションのデータベースにすでにあるけど

「アプリケーションのデータベース」という部分は、ログデータだとか、CRM だとか、Web の行動分析ツールなどと言い換えても構いません。データは既に存在しており、必要なデータは（少しスキルが必要だとしても）取得できることが多いです。プロダクトマネージャーが、仮説検証のためにソフトウェアエンジニアにデータ出しを依頼し、アプリケーションのデータベースに対して、SQL を書いてデータを取得して渡すという作業を行えば、分析は可能です。実際それで済む場合もあります。であれば、データ分析基盤がないと困る瞬間って、あまり思いつかなかったりしないでしょうか？
そしてそれならば、データエンジニアリングに携わっている人って、日々一体何をやっているんだろう？と疑問に浮かぶかもしれません。

データ分析基盤があることで...

データ分析基盤には、データが一元化されています。2つの意味に分けて説明してみると

一元化 = 見渡せる

組織内のデータは、基本的に散らばっています。プロダクトごとにデータベースが分かれているだけでなく、Web の行動分析ツール、CRM、ログ、CSV データ、議事録、などなど。これらのデータを見たくなったときに、どこになにがあるかわからないということもあるかと思います。データ分析基盤に、組織内のあらゆるデータが集約されていることで、ここを見れば良い、となります。

一元化 = 一緒に使える

また、単に集まっているだけでなく、同じ意味のデータを関連させることができます。例えば、Web の行動分析ツールだけであれば、そこからわかることは限定的かもしれません（例：あるユーザがある画面にアクセスした）。一方で、データ分析基盤に、そのユーザの所属する属性の情報、さらにその属性の特定の情報がそれぞれ格納されている場合、データ分析基盤から、複数の情報を横断的に一度で確認することができます（例：あるユーザがある画面にアクセスした、そのユーザは XX という部署に所属しており、その部署は xx という性質を持つ）。

データ分析基盤のために...

データ分析基盤、役に立つかも！と思えたでしょうか。... まぁそう思えるようになったとして、では、データ分析基盤のために、なにをすることがあるのでしょうか。それぞれのプロダクトやシステムから、データを引っ張ってきて、終わりなんじゃないの？なにすんの？

人が読めるように

まず、使い勝手を良くする必要があります。単純にデータを引っ張ってきただけで「用意しておいたんで使ってください」と伝えたとして、ビジネスサイドに近い方が使いこなすのは難しいと思われます。ここでは、基本的な考え方の違いを意識しないといけません。それは、アプリケーションのデータベースは性能を重視し、データ分析基盤（データウェアハウス）のデータはわかりやすさを重視する ということです。

アプリケーションのデータベースは、更新頻度が高く、書き込まれることに最適化するため、正規化されています。データの挿入に何秒もかかることを防げるなら、複数回 join することになるとしても、テーブルを分割します。一方で、データ分析基盤で使われるデータは、参照が前提であり、人がビジネスの観点から読めるように、整理されている必要があります。
人にとって読みやすいということは、例えば、明確で、関係性が単純で、誤解の余地が少ない ということです。テーブルの join は少ない方がいいです。これはすなわち、BI で使いやすい、AI が正しいクエリを生成しやすい、ということに繋がります。

で、なにしてんの

やっと、データ分析基盤のためにやっていることを説明する準備が整いました。
先ほど、データ分析基盤には、あらゆるプロダクトやシステム（データソースといいます）から、データを引っ張ってきている、と書きました。一方で、データを引っ張ってきただけでは、使ってもらうのは難しいので、人が読めるようにする必要があるとも書きました。ここの間を埋めないといけません。

データソース ---> （いい感じにする） ---> データマート

データマートと書きましたが、つまり、人が分析のためにそのまま使えるテーブルだと思ってください。データ分析基盤のためには、上記の（いい感じにする）をする必要があります。

レイヤー

実際には、データ分析基盤は「一枚岩」ではありません。いくつかの役割に分かれたレイヤーで構成されています（おもしろいと思いませんか）。レイヤーの分け方は色々とありますが、データ分析基盤のアーキテクチャを構成する上での、主要なレイヤーを紹介してみます。一般的な話です。

（１）コレクティングレイヤー

様々なデータソース（アプリケーションデータベース、CRM、ログファイル）で常に発生しているデータを漏れなく集め、プロセシングレイヤーやストレージレイヤーに渡す。

（２）プロセシングレイヤー

コレクティングレイヤーによって取り込まれたデータを、分析しやすい構造に変換・加工・クレンジングする。ETL（またはELT）のTransform（変換）を担当。

（３）ストレージレイヤー

データやメタデータを保存する。各種レイヤーのアクティビティは、このレイヤーに対して行われる。

（４）アクセスレイヤー

ストレージに保管された処理済みのデータに対して、ユーザーやアプリケーションが直接アクセスし、データ価値を得る接点。

※ 改訂新版［エンジニアのための］データ分析基盤入門＜基本編＞の 2.2 節から図を利用させていただきました

頭のつかいどころ

レイヤーを考えることは、責務分離の観点が含まれます。利用しやすいテーブルを考えることは、データモデリングといった設計の観点が含まれます。データソース変更を追従するための変更耐性を考えたりします。エンジニアリングですね。

その他の仕事

代表的なことを書きましたが、他にもクエリの実行時間だとか、コストだとか、メタデータ管理であるとか、フリクション（提供されてから使うまでの時間）だとか、色々考えることはあったりします。

ときに地味ですが、ビジネスへの貢献（と自分たちのおもしろさ）のために、粛々と頭を捻ってます。