読者です 読者をやめる 読者になる 読者になる

双六工場日誌

平凡な日常を淡々と綴ります。

データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ(暫定版)

最近、データ分析基盤を設計するに当たっての考え方を整理する必要があって、要件に応じたデータ分析基盤を設計するに当たっての基本的な考え方は何かを考えています。

近年、データ分析基盤はデータ収集ソフトウェア、データストア、分析処理、分析処理の利用方法などなど、検討すべき項目が多くなり、この辺りの技術の流れを把握している人は当然のように設計を行うことができますが、そうでない人に取っては、どこから検討を始めるべきかわかりにくくなっているように思います。

自分の中でも、これがうまく言語化できておらず人に教えようと思っても、結構詰まってしまうので、ブログで言語化してみる次第です。

最近のデータ分析基盤の基本は「Scheme on Read」型のアーキテクチャ

最近のインターネット上で見るデータ分析のアーキテクチャは、データをデータソースから収集したのち、最低限の加工(ログをフィールドごとに区切るなど)をHDFSやS3、Azure BLOB ストレージなどに置くことが多くになっていると思います。

Hadoopが普及し、分散処理を利用するハードルが下がったことで、一度データを保存してしまえば、あとからデータを分析できる形式に整形することができるようになったことが、このようなアーキテクチャを可能にしていると思います。

保存したデータは、あとでHadoopを使って分析に使いやすい形に加工し、その上で独自の可視化アプリなり、Tableauなどのセルフサービス側のBIツールで読み込んで使うことになります。

最近のデータ分析基盤系のスライドを見ると、このアーキテクチャを前提に以下の4つのコンポーネントに分けて、機能が語られていることが多いようです。最近のデータ分析関連のプロダクトは、このような区分で作られていることが多いので、自分としてもしっくりきます。

このアーキテクチャは「Scheme on Read」という言葉で呼ばれることがあります。データ加工を出来る限りあとのフェーズにすることで以下のメリットを得ることができます。

  • テキストや画像、音声、動画等の非構造化データもそのまま同じ仕組みで保存可能
  • データの種類や分析内容が変わっても、「処理」フェーズ以降で必要に応じてデータを加工することで柔軟に対応できる
  • データ保存にはファイルをそのまま保存できるようなストレージや分散ファイルシステムを使うことで、データの収集・保存の仕組みをシンプルに保つことができる

分析対象と分析手法が多様化していることから、このような特徴はデータ分析基盤の大きなメリットです。

それでは「Scheme on Write」の基盤とは?

Hadoopが普及する以前は、データ分析基盤と言えば、データ・ウェアハウスを中心とするBIシステムのことを指していました。ただ、BIシステムとHadoopを利用したデータ分析基盤のアーキテクチャの比較は、私が知る限りあまりないように思います。

データ・ウェアハウスのアーキテクチャは「Scheme on Read」と比べると、「Scheme on Write」、つまりデータを保存する際にスキーマを与えるという設計の方法論と考えることができると思います。

BIシステムの構成要素をざっくりまとめると、以下のようになっています。

  • BIシステムの構成要素
    • ETL
      • Extract: 業務システムからのデータ抽出・収集、Transform: データ加工、Load: データ・ウェアハウスへのデータロード
    • 蓄積
      • データ・ウェアハウスへの蓄積
    • 分析・ビジュアライズ
      • BIツールでの分析

先ほどの最近のコンポーネント分割と比べると、Iシステムではデータ収集とデータ加工が「蓄積」の前に来ており、データ蓄積の時点で分析に必要な前処理がひと通り終わっていることが前提となっていることが大きく異なっています。

データ・ウェアハウスは、単にデータを長期間に渡って蓄積するだけではなく、データ分析の目的に特化したテーブル構造を取ることで、複数の軸でデータの集計・分析を高速に行うことができるようになっています。

データ・ウェアハウスで用いられるテーブル構造は「スタースキーマ」と言われ、各種マスタ情報やデータ集計対象期間等の属性情報を格納した「ディメンション・テーブル」と取引履歴などの履歴データをディメンションテーブルの軸で切って格納した「ファクト・テーブル」からできており、通常は業務システムとは別のテーブル構造を持っています。この構造にしたがってテーブル設計を行い、データを格納することで、BIツールから効率的にデータ分析ができるように工夫がなされています。

そのため、データ・ウェアハウスにデータを蓄積する際には、そのテーブル構造にデータを合わせるためのデータ加工や不正なデータやフォーマットが合わないデータを弾くためのクレンジング処理も必須です。しかし、一旦データを入れてしまえば、後段の分析では前処理が終わった状態でデータを使うことができる、というのがこのアーキテクチャの特徴です。

上で見てきたデータ・ウェアハウスを中心としたBIシステムは、その特徴故にデータ投入時の検討事項が多くなり、かつ、事前のテーブル設計で漏れがあったり、新たに分析対象となる軸が出たりした場合は、またテーブル設計からやり直す必要が出てきます。そのため、最初の要件定義の際に分析軸まで決められるようなデータの種類が増えない業務システムであればいいですが、そうでない場合は設計が困難です。

BIシステムの設計は、企業内部に閉じていることが多く、設計自体が各企業のノウハウを含むので、Web上では概論を超えるような設計内容があまり公開されていないように思います。書籍としては、以下の書籍が参考になりました。

BIシステム構築実践入門 (DB SELECTION)
平井 明夫
翔泳社
売り上げランキング: 55,350
BIシステム構築実践入門 eコマースデータ活用編 (DB Magazine SELECTION)
平井 明夫 梶 幸司 野澤 ひろみ 佐藤 宏樹 深井 淳 駒原 雄祐
翔泳社
売り上げランキング: 510,026

「Scheme on Write」は「Scheme on Read」に乗り越えられたと言えるか?

「Scheme on Write」はデータ分析基盤が世の中になかった時に、業務システムとデータ分析を行うシステム(情報系システム)を分割し、業務にしか使われていなかったデータを分析用のデータに転換することでビジネス上の価値を生み出すことを意図して考えだされた仕組みです。

一方、「Scheme on Read」は、上記の背景から生まれた既存のBIシステムが近年のデータ増加のために行き詰まってくる中、Hadoopによる大量データの分散処理が一般的になったことから形作られてきたアーキテクチャだと思います。

ただ、後者が前者を単純に乗り越えて、後者だけですべてが成り立つ世界になったかというとそうでもないかなと思います。どちらにしても、最終的にデータ分析を行うためには、データ分析の目的に応じてデータを整形し、分析する必要があり、また、データの前処理は後に回せば回すほど、余分なデータをあとに持ち越すことになるため、処理のオーバーヘッドは増えてきます。

・・・この関係をうまく整理できればいいのですが、今日の時点ではまだまとまっていません。 連休中に考えがまとめられたらと思いますが、なんとかなるかなー

長くなったので、尻切れですが、今日はここまで。続きはまた考えがまとまり次第ということで。

--

追記

メモの続き書きました。このメモはアプローチの整理までで一旦終了で。

データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ(暫定版)・続き - 双六工場日誌