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

前の記事の続きです。

<a href="http://sechiro.hatenablog.com/entry/2015/05/02/%E3%83%87%E3%83%BC%E3%82%BF%E5%88%86%E6%9E%90%E5%9F%BA%E7%9B%A4%E3%81%AE%E3%80%8CScheme_on_Write%E3%80%8D%E3%81%8B%E3%82%89%E3%80%8CScheme_on_Read%E3%80%8D%E3%81%B8%E3%81%AE%E8%BB%A2%E6%8F%9B%E3%81%AB">データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ（暫定版） - 双六工場日誌</a>sechiro.hatenablog.com

前の記事では、分析対象データの加工をできるだけデータ利用に近いフェーズで行うようなアプローチ、「Scheme on Read」に対して、従来のBIシステムと比較して、整理できないか検討しました。

前の記事で、現状の考えを整理したあと、似たような記事を探したところ、以下のような記事もありました。こちらはBIシステムとHadoop中心のシステムを比較するのではなく、DWH/BIシステムを中心にHadoopをETLとして使うシステムとHadoopを中心にするシステムというわけで書いていますが、「データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違い」を取り上げているところは共通していると思います。

データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違いによって、ビッグデータを分析するための基盤アーキテクチャには大きく２つのタイプに分けることができます。従来からのDWH/BIの流れを汲むものとHadoopを中心にしたものです。データウェアハウス（DWH）中心のアーキテクチャでは、業務データベースからのデータはETLツールによって変換され、DWHに蓄積されます。また、時系列データはCEPエンジンなどにより、そのまま処理されて活用されることもありますが、CEPエンジンによって収集されたデータをDWHに蓄積することもあります。そして、非構造化および半構造化データに対してはHadoopをETLツールのように使って、生のデータから意味付けすることにより構造化してから、DWHに蓄積します。こうすると、すべてのタイプのデータはDWHの中に構造化されて蓄積されるため、OLAPやデータマイニングやテキストマイニングなど従来のBIツール群を使って、データアナリストによる従来通りの分析が可能になります。

一方、Hadoop中心のアーキテクチャでは、業務データベースからのデータはSqoopなどを使って、時系列データはStormやS4などを使って、非構造化データはFlumeやfluentdなどを使って、HDFS（Hadoop分散ファイルシステム）やHBaseなどに、前もって意味付けせずに生のまま蓄積できます。使っているソフトウェアはすべてオープンソースですので経済的なアーキテクチャと言えます。この方式の最大の特長は、生のままのデータが蓄積されているので、データ分析時にいろいろな意味付けを試してみる探索的なデータマイニングができるところにあります。また、従来のBIツールで用意されているアルゴリズムだけではなく、最新の統計理論をベースにゼロからプログラミングできる自由度をもっています。そのため、データアナリストというよりデータサイエンティストに向いたアーキテクチャと言えます。また、必要ならば、HDFSやHBaseから何らかの意味付けをした後のデータをDWHにロードすることによって、従来タイプのBIツール群も使うこともできます。

ビッグデータ分析の意義と、分析のためのシステム基盤 | NTTデータ先端技術株式会社

「Scheme on Read」は、実際のシステムが先行し、それに概念を与えたもの

前の記事では、アーキテクチャやアプローチなどの理論的な面での違いを見てきましたが、この記事と実際のHadoop中心のアーキテクチャを見ていて、その軸での整理は難しいように思えてきました。というのも、データ・ウェアハウスはデータベースに関する理論が先にあり、それをソフトウェアとして実装したのに対し、「Scheme on Read」の概念はHadoopの登場により実装が先行して、それを理解するために概念が形成されたように見えるからです。

私自身はデータ・ウェアハウスが出てきた当初のことを直接知ってはいませんが、BIシステムの成立を見ていると、Wikipediaの「データ・ウェアハウス」の項目には以下のような記述があり、データ・ウェアハウスはデータベースに関する理論的な背景を踏まえて実装されたものとされています。

データウェアの提唱はビル・インモン(William H. Inmon)氏で、1990年の著作によれば、「データウェアハウスは、意志決定(Decision)のため、目的別(Purpose-oriented)に編成され、統合(Integrate)された時系列で、削除(Delete)や更新(Update)しないデータの集合体」とされる。データウェアハウス - Wikipedia

データ・ウェアハウスベンダのTeradataの解説記事では、ビル・インモン氏がデータ・ウェアハウスが持つべき以下の4つを特徴を著作で主張していたと書かれており、データ・ウェアハウスは当初からあるべき姿が定められていました。