データ分析基盤の基本と構築のポイント

このエントリーをはてなブックマークに追加

こんにちは。データデザイン部の福本です。
主にデータエンジニアとして、データ分析基盤の設計構築を行っています。

データを有効に活用するためには、活用するために適切な環境を構築し、そこにデータを適切な形で流し込むことが重要です。
今回はデータ分析基盤のベストプラクティスとされている構成と、そのメリットや構築ポイントについて整理します。

データ分析基盤の構成

データ分析基盤は三層のデータレイヤーで構成されることが多いです。
それぞれデータレイク、データウェアハウス、データマートと呼び、持っているデータの性質が異なります。
これらのデータベースを収集・整形・加工のプロセスで連携させることで、データ活用がしやすい環境を提供します。

各データレイヤーの役割は以下のようになっています。

データレイク

データソースとなるシステムやデータベースから収集してきたデータを保存しておく役割をもつのがデータレイクです。
ここではデータを加工せずに、取得してきたままで保存しておきます。
このようなデータを「生データ」と呼びます。
このようにする理由は主に二点あります。

1. データのバックアップ

後続の整形や加工で不可逆な処理を行ってしまうと、後からやりたいことが変わって削ったデータが欲しかった、なんてことになった際に大きな問題になります。
データソースから取得した生データをそのまま保存しておくことで、そういった場合に備えることができますし、慎重になりすぎることなく整形や加工を行うことができます。

2. データソースからの分離

バックアップだけであれば、またデータソースから収集しなおせばいいと思われるかもしれません。
しかし、データの収集はデータソースに負荷をかけるため、パフォーマンスに影響する可能性があります。
また、データ量や環境によっては収集にはとても時間がかかります。
データレイクに生データを保存しておくことで、再収集などによるデータソースへの影響をなくすことができますし、時間的にも短縮できる場合が多いです。

データウェアハウス

データレイクに収集してきたデータを整形して分析しやすい状態で保持するのがデータウェアハウスです。
整形では、データを補完、修正、削除することで品質を高めるデータクレンジングや、正規化などによって分離されているデータを特定のキーでつなぎ合わせるデータ結合を行います。
データ分析担当者はデータ分析環境でこのデータを利用して統計解析や機械学習を行うことで、データの価値を探索します。
整形では、どのようなルールでデータクレンジングを行うかや、どの程度データを結合するかといった設計が必要です。
データの種類や量、性質によって適切な方法は変わってくるため、整形のフローを設計する前に生データを良く観察する工程「データアセスメント」が必要です。
データ結合をせずにデータソース毎にデータクレンジングを行ったテーブルと、そこから必要な組み合わせで複数の結合データデーブルを生成するといった、データウェアハウス内で多段のデータ構造にすることもあります。

データマート

活用に特化した形式に加工したデータを保持するのがデータマートです。
データウェアハウスのデータは分析向けの整形はしていますが、性質としてはニュートラルなので、自分で観点を持ってデータを扱える必要があります。
店舗のマーケティング担当者全員が自分で欲しいデータ取得してくるのは難しいですし、必要なデータが一部の集計済みの数字などであれば、事前に計算してBIツールなどで可視化しておくのほうが望ましいです。
こういった目的ごとにそれぞれデータを加工し、BIツールやDMPに提供することで効率的にデータ活用ができます。
図ではデータマートを一つの図形で表現していますが、実際は提供先ごとにテーブル単位やデータベース単位で分離して配置したほうが、相互の影響が減るため望ましいです。
そうすることで、データの提供先が増えた場合にも新しく加工のプロセスを追加するだけで周囲への影響なくデータ活用を拡張することができます。

また、機械学習モデルを利用する場合、推論対象のデータが事前に手に入る場合は推論結果をデータマートに入れておくことで、計算時間を短縮して結果を返すことができます。
リアルタイムの入力には使えませんが、前日のデータから予測を行う場合などには有効な手法です。

構成のメリット

このような構成にすることはデータを整理して持つということ以外にも、以下のように多くのメリットがあります。

影響範囲の分離

ビジネスの状況に応じてデータは求められる形式や着眼点が変化していくため、データ分析基盤もそれに合わせてデータソースの数やデータフォーマットなどが変化していくことが多いです。
データベースの層を分離しておくことで、そういった変化に強い基盤とすることができます。
どこかでデータフォーマットが変化した場合、影響する部分の整形や加工のプロセスを変更することで、その他の部分への影響を最小限にすることが可能となります。
例えば、データソースのフォーマットが変更になった場合、整形で変更を吸収できれば、加工やデータマートへの影響はなくすことができます。
また、データ提供先のデータ要件が変更になった場合も、加工のプロセスを変更することで、データウェアハウスには変更を加えずに対応することができます。

リソースの分離

それぞれのデータベースやプロセスの実行環境を分離することで、パフォーマンスを最大化することができます。
すべてを同じデータベースで管理した場合、データウェアハウスへの書き込み処理によってデータマートの速度が低下する可能性などがあります。
それぞれのデータベースを分離することで、相互のパフォーマンス影響を防ぐことができます。
特にデータマートは用途によって求められる性能が異なる(読み出し速度優先、複雑なクエリが使えるなど)場合があるため、用途に合わせたデータベース選定を行うことが求められます。

コスト面でも分離によるメリットがあります。
データベースをはじめ、データを保存するサービスは数多くありますが、その性質によって費用が大きく異なります。
一般的にはデータベースよりもオブジェクトストレージと呼ばれるファイル格納サービスは容量単位の価格が安いです。
そのため、データレイクは構造化データであっても、オブジェクトストレージに置いておくことでコストを抑えることができます。
また、データウェアハウスやデータマートも必要なスペックがデータ量や使い方によって変わってくるため、それぞれに最適なサービスを利用することで、トータルコストを最適化することができます。
ただし、上記の説明は近年主流の従量課金のクラウドサービスでの構築で最も効果を発揮する使い方で、オンプレミス環境や仮想サーバ上にデータベースを構築する場合、リソースの利用率が低いと分離するほど割高になってしまう場合があるため注意が必要です。

ベンダーロックインの回避

近年ではデータベースから豊富なデータ活用機能までを備えた統合データプラットフォームと呼ばれるサービスが増えてきています。
ブラウザベースで使いやすいものも多いですし、導入すればすぐに使えるというメリットがあります。
しかし、その多くは機能化のトレードオフとして自由度が制限されることが多く、やりたいことが増えてきた際にできないということが起こりがちです。
また、データ量が増えてきたタイミングで割高になったり、データフォーマットが独特でエクスポートしても扱いにくいケースもあります。
トレンドサービスの入れ替わりも激しいため、そのたびにデータの載せ替えを行うのは大変です。
ニュートラルな環境でデータ活用基盤を構築しておくことで、こうしたリスクを回避することができます。
データウェアハウスでベースとなるデータは保持しておき、利用したい機能があるサービスにデータマート経由でデータを送り込む構成にすることで、ベンダーロックインを回避しつつデータ活用ができます。
もちろん、データ分析基盤に加えてサービスを使うことで費用がかさむケースもありますし、導入スピードでは構築済みのサービスを使うだけというのは大きな強みなので、まずは統合サービスでやりたいことができるか検証してみて、いけそうなら基盤を構築して接続するといった段階を踏むのも選択肢として考えられます。

構築のポイント

実際に構築する際には抑えておかないといけないポイントは色々ありますが、特に陥りがちな問題を回避するためのポイントをいくつかご紹介します。

事前にデータアセスメントを実施する

いくら立派なデータ分析基盤があっても、データそのものに価値がなければいくら分析や加工をしても意味がありません。
目的に即したデータが用意できるかを必ず事前にチェックしましょう。
また、セキュリティポリシーによって一部のデータしか取り出せなかったり、活用先が限定される場合もあるため、良く確認してください。

データソースとの自動連携可否をチェックする

データ分析基盤の構築で最もネックになるのはデータ収集の部分です。
データソースのシステム担当者と十分にコミュニケーションを取り、どのように自動連携するかを確認しましょう。
手作業は必ずエラーや分析ミスの原因になるため、自動連携できない場合はデータソースにはならないと考えてください。

データの流れは一方通行

基本的にデータ更新の流れはデータソースからデータ活用まで一方通行にするのが望ましいです。
逆方向を許してしまうと、状態の管理やエラーへの対処が複雑になるためです。
一方向のフローであれば、どこかで失敗しても一つ前のステップを再実行することで対処できますが、逆方向のデータ変更を許してしまうと、それらの処理のタイミングによって状態が変わるため、復旧が難しくなります。
データ活用先のデータを分析にも使いたい場合などは、それをデータソースとして再投入することで、一方向のフローを守りつつデータを再利用できます。

データはできるだけ疎に持たせる

データ整形の部分でデータ結合を行うと書きましたが、どんな分析でも結合して使うケースやあまりにも時間がかかる場合を除いて必要以上に結合すべきではありません。
データソースや提供先が増えるほど、それらに変更があった場合の影響範囲が広くなるためです。
結合はデータ分析環境でもできますし、結合データ用のテーブルを追加で用意することも可能なので、過度に整形してデータウェアハウスに密結合データしかないという状況にならないように気をつけましょう。

最後に

データ分析基盤の一般的な構成やなぜそうするのか、構築のポイントなどについてご説明しました。
データの内容や用途によって各データレイヤーの内部やデータ処理は大きく異なるため、基本的な考え方を抑えつつ状況に合わせた判断が求められます。
この構成が最適とならないケースももちろんありますので、構成の意図を理解したうえで判断する際の一助となれば幸いです。

個別の支援をご希望の場合は、お気軽にお問い合わせください。
最後までお読みくださいましてありがとうございました。

WRITER
Kazuya Fukumoto

エンジニアチームリーダー

福本   和哉 Kazuya Fukumoto

主にデータ分析基盤の設計構築や、開発プロジェクトのPM・PLを担当。JDLA Deep Learning for GENERAL 2018 #1、認定スクラムマスター(CSM)、GCP Professional Cloud Architect

最新記事

ページTOPへ