データが大量に蓄積されるようになると、一つのマシン上にデータが乗り切らなくなるという問題が発生する。こうなると複数のマシン上にデータを分散させなければならない。ところがデータが分散するようになると、理論上の困難が生じる。
この問題に関して、CAP定理と呼ばれる定理を聞いたことがあるだろうか。CAP定理とは、分散環境におけるデータに関する定理である。分散環境上のデータは一貫性（consistency）・可用性（availability）・分断体制（partition tolerance）の3つの性質により表現される。CAP定理の名前はこれら3つの性質の頭文字をとったものであり、CAP定理が主張するのは、これら3つの性質のすべてを同時に満たすことはできないということだ。これらの性質をシステムの特性に応じて取捨選択する必要があるのだが、それによってデータベースの扱い方も変わってくる。
例えばAmazon DynamoDBのようなキーバリュー型のデータベースを選択して、非構造化データを一次ソースにしたとしよう。アプリケーションを動かすにはこれが最適であったとしても、データ分析の枠組みでは構造化データであった方が良いかもしれない。なぜならデータ分析が要求するデータモデルの多くは、ベクトルや行列といった構造化データのようなデータ構造を要求するからだ。キーバリュー型のデータ構造から、分析に必要なデータ構造を取得するにはどのようなクエリを投げ、どのような前処理が必要になってくるのか。考えることは多い。
ここまでくると、エンジニアとマーケターの関係以上に、エンジニア内でも専門性が求められてくる。最終的なデータが欲しいのはマーケターであったとしても、専門性を持ったエンジニアが不在の状態では、とても必要なデータにたどり着くことはできない。データベースを適切に扱える人材がデータを取得し、それがマーケターまで遅延なしに届く環境が、データ分析をうまく運用するためのポイントとなってくる。
不幸を生まないための基盤
マーケティング部門がデータを自在に取り扱うということに対して、システム運用者はどのように思うだろうか。おそらく良い印象を抱かない。なぜなら業務を回すために設計されたシステムに対して、想定外の負荷を与えることに他ならないからだ。
しかし、攻めのデータ分析のためのデータは従来の“守り”ではなく、利益を生むためのデータなのである。よく言われるデータ分析基盤は、図1に示したような構成だ。まず各システムで集積されたデータあるいは外部から得たデータを変換し、集中管理するデータウェアハウス（DWH）に貯める。DWHからデータ分析システムに特化したデータマートを作成する。最近ではDWH自身の性能の向上から、データマートをスキップしてDWHから直接データを引き出す分析システムも珍しくない。そのどちらが良いかに関してはここでは議論しない。
