データウェアハウスからレイクハウスへ

これは、「データウェアハウスの父」と呼ばれるアメリカのコンピュータ科学者、ビル・インモン氏が書いた Integrate.io への寄稿です。インモン氏は、データウェアハウスに関する本と雑誌のコラムの執筆、このトピックに関する会議の開催、そしてデータウェアハウスのクラスを教えた最初の人物です。

このトピックに関する主なポイント５つ：

1. データアーキテクチャは年々進化しており、データウェアハウス以前は、シンプルなアプリケーションがデータを扱っていた。
2. データウェアハウスは、構造化されたデータを大量に作成することで、データアーキテクチャに革命をもたらした。
3. テキストETLで、企業は非構造化データの処理ができるようになる。
4. データレイクハウスや機械生成データもデータアーキテクチャを一変させた。
5. Integrate.ioは、データ統合要件に対応するデータウェアハウス・ソリューションである。

概要

データアーキテクチャの進化は現在進行中で起きています。まず、シンプルなアプリケーションがあって、その後、データウェアハウスが登場しました。それからデータウェアハウスにテキストが追加され、そして今、データレイクハウスが誕生しました。この変革には、それぞれ類似点と特異点があります。そこで本記事では、今日起こっているアーキテクチャーの変遷を検証します。

はじめに

データアーキテクチャは１９６０年代、最初のアプリケーションの登場とともに何気なく始まり、それ以来進化を続けています。進化というものは、大抵は氷河のようにゆっくりとしていくものですが、データ・アーキテクチャの進化は光の速さです。本記事では、その進化と今日の状況についてお話します。

Integrate.io は、データウェアハウスとデータレイクハウスの両方の進化を見てきました。このデータウェアハウス統合ツールは、ウェアハウスとレイクを統合し、ビジネスにレイクハウスのあらゆる利点をもたらします。Integrate.io はまた、ETL（抽出、変換、格納）、リバース ETL、および超高速CDC（変更データキャプチャ）ツールを使ってデータ統合プロセスを効率化します。１４日間の無料トライアルで、Integrate.io をぜひお試し下さい。

データウェアハウス以前

当初はアプリケーションがあり（ジャルケ、他、２０００年）、そのアプリケーションで、面倒な作業は大幅に軽減されました（グールド、他、１９９１年）。アプリケーションは、エンドユーザーの要求を調査し、その要求に合わせてアプリケーションを調整することによって作られ（グールド、他、１９９１年）、集められた要件は、開発プロセスを迅速に進めるために、エンドユーザーの差し迫ったニーズに対して非常に具体的なものでした。そしてすぐに、組織でのアプリケーションがたくさん出てきました。（デローン 、１９８８年；ヴァンロメル と デブロンダー、１９７５年）

そしてある日、特定のアプリケーションのデータではなく、組織全体のデータを探したいと考える人がいました。データが不足するということはなく、どこにでもありましたが（マキューン、１９９８年）、同じ要素のデータが複数の場所に出現し、それぞれ値が異なることが問題だったのです（コッド、１９７０年; デート、１９８６年；  ウルマン, １９８２年）。どの値が正しくてどの値が間違っているのか誰にもわからないため、分析処理は困難を極め、このことが分析結果を非常に疑わしいものにしていました（チェン、他、２０１７年）。

今にして思えば、要件収集に企業の視点が含まれていれば、このような混乱は起きなかったかもしれませんが（インモン、２００５年）、アプリケーションの開発期限に間に合わせるために、要件の絞り込みが繰り返し行われたのです。

データウェアハウスの台頭

このようにデータの価値が疑われていたところに、データウェアハウスが登場しました。データウェアハウスがデータを吟味、統合し、その結果、企業のデータに対する理解が深まり、このように企業がデータを理解することで、経営者が分析対象データを信頼できる分析環境が整ったのです （インモン、２００５年）。

データウェアハウスは、「経営上の意思決定を支える、対象志向の、統合された、不揮発性の、時間的に変化するデータの集合体」と定義され、現在もそのように定義されています。

データウェアハウスには、企業のための吟味されたデータに加えて、長年のデータの履歴が残っていました。通常、データウェアハウスには、５年から１０年分のデータが保管されています（インモン、２００５年）。

デザイナーは通常、ETL（抽出、変換、格納）と呼ばれる変換プロセスを使ってデータウェアハウスを構築し、アプリケーション内のデータは、企業の型に変換されます（ゴルファレッリ と リッツィ、２００９年）。アプリケーションのデザイナーは、データの解釈を自由に選べますが、企業におけるデータ理解には、企業全体での単一の解釈が求められます（インモン、２００５年）。

アプリケーションデータから企業データへの変換の簡単な例として、例えば以下のようにアプリケーションが３つあるとします：

1. アプリケーション ABC
2. アプリケーション BCD
3. アプリケーション CDE

又は：

1. 性別　男性／女性
2. 性別 − 　男／女
3. 性別　１／０

又は：

1. 単位 − インチ
2. 単位 − センチ
3. 単位 − インチ

又は：

1. ドル − 豪
2. ドル − 加
3. ドル − 米

アプリケーションのデータが ETL を通過するとき、データは単一の企業の解釈に変換されます：

データウェアハウス

• 性別 − 男／女
• 単位 − インチ
• ドル − 米

ETLで、企業の解釈が一本化されているデータが作成されます。

Integrate.ioで、すぐに使えるネイティブなノーコードのコネクターを介して、サポートされているウェアハウスへのデータ移行が可能になります。ソースからターゲットへのETLが簡単です。また、Integrate.ioは、ELT、リバースETL、超高速CDCも実行します。14日間の無料トライアルで、Integrate.io をぜひお試しください。

ウェアハウスの進化

データウェアハウスの初期には、プログラマーが手作業で ETL プログラムを作成していました（インモン, ２００５年）が、すぐに、データウェアハウスを自動的に作成する ETL ソフトウェアの産業が発展しました（バシリアディス、２００９年）。

データウェアハウスは、BI（ビジネスインテリジェンス）業界に革命を起こしました。データウェアハウスの前に BI を行うのは、当たり外れのある提案でしたが、データウェアハウスの出現により、BI は成功のための基盤が確立されました（アルメイダ、他、１９９９年）。

データウェアハウスは、あらゆる業界や組織に適用されるという点で遍在していました（アリヤチャンドラ と ワトソン、２００８年）。小売業、製造業、保険会社、銀行・金融、政府機関、接客業、航空会社、スポーツ団体、エンターテイメントなど、データウェアハウスはさまざまな分野に適用され（チャウドゥリ と ダヤル、１９９７年）、世界中どこでにでもあります（サリネシ と ギャム、２００６年； グールド、他、１９９１年）。

データウェアハウスの特徴は、それまで想像もしなかったような大量のデータを作成したという点ですが、データウェアハウスは、トランザクションベースのシステムではほとんど行われない、過去のデータを保存するものでした（キンブル、他、２００８年）。

データウェアハウスは概念であり、どのベンダーも所有するものではありませんでした。ベンダーはデータウェアハウスのさまざまな側面を提供しましたが、どのベンダーもウェアハウスを所有することはなかったのです。

データウェアハウスの利点の反面、制約もいくつかありました。その1つは、データウェアハウスが構造化されたデータのみを扱うという点です。構造化データは通常、トランザクションベースであり、高度に構造化された方法で収集・保存できるということになります（インモン、２００５年）。

問題は、他の多くのデータが非構造化フォーマットに存在することでした。それは主にテキストで、構造化されていないことで有名です。さらに、テキストは非常に複雑ですが、テキストには途方もないビジネス チャンスがあるという事実が問題を複雑にしています。医療記録、コールセンターの会話、契約書、メール、他にもテキストベースのデータセットが存在する場所が多くの場所があり、そのような場所は、過去にはほとんど調査も利用もされてきませんでした（ブルムバーグ と アレ、２００３年）。

この方程式に、『テキストETL』と呼ばれる技術が加わります。テキストETLは、テキストの曖昧さをなくす作業を行い、テキストに曖昧さがなくなると、分析に入ることができます。

テキストの課題

テキストの曖昧性の解消には多くの課題があり（チェンバロ、他、２０１２年）、まず第一の課題は、テキストのコンテクストの特定です。テキストとコンテクストの両方を扱わない限り、曖昧性解消の本格的な仕事はできませんが、テキスト ETL はまさにそれを行うものです（インモン、２０１８年）。

それ以外にも課題はあり、その１つに「予測可能なテキストの適切な管理」があります。テキストには、【予測可能なテキスト】と【予測不可能なテキスト】という２つのクラスが存在します（オブライエン と マイヤーズ、１９８５年）。ほとんどのテキストは予測不可能ですが、一部のテキストは予測可能であり、予測可能なテキストのコンテクストの特定は、予測不可能なテキストのコンテクストの特定とは大きく異なります（インモン、２０１５年）。

タクソノミーやオントロジーが「予測不可能なテキストの曖昧性解消」の管理に有効であるのに対し、インラインのコンテクスト化は「予測可能なテキストの曖昧性解消」の管理に有効です（インモン、２０１７年）。タクソノミーとオントロジーは、インラインのコンテクスト化とは似て非なるもので、単純に両者の間には、類似性はほとんどありません。

さらに、テキストに関しては、他にもまだ大変なことがあります。単にテキストにアクセスするのだけでも大変なのです（アキラン、２０１５年）。インターネットには独自の考慮事項があり（チェン、他、２０１５年）、メールには別の考慮事項が（ジュライラティ、他、２０１８年）、音声からテキストへの転写には、これまた独自の考慮事項のセットがあります（ボッツェンハート、他、２０１１年）。テキストが存在するさまざまなメディアには、曖昧性解消を行う前に考慮しなければならない独自の考慮事項があるのです。

さらにややこしいのは、テキストにはさまざまな言語があるという事実です。そして、その言語には、それぞれ独自の考慮事項があります。アルファベット、慣用句、方言、言語構造、テキストが書かれる方向まで。要するに、テキストの扱いは複雑な作業だということです。

テキストETLのメリット

上記の考慮事項を全て考慮に入れる技術が、非構造化テキストを読み込んでデータベース、構造化フォーマットに変換する『テキストETL』です。テキストETLは、テキストとコンテクスト、タクソノミーとオントロジー、言語の違い、アルファベットの違いなどを考慮し、その結果、出力としてきちんと構造化されたデータベースが得られます（インモン と ネサビッチ、２００７年）。

テキストがデータベースとして出力されると、標準的な分析ツールでの分析ができます。そして、テキストETLは、データベースの形をしたテキストをデータウェアハウスに入力するための出力を生成し、データウェアハウスが提供する機会の幅が、それによって飛躍的に拡大します（インモン と ネサビッチ、２００７年）。

テキストデータと構造化データの融合

テキストデータと従来の構造化データの組み合わせには問題がいくつかありますが、その問題は、分析を行うための共通の属性セットを見つけることに集中しています。会話や記事など、ほとんどのテキストには、構造化データに見られるような重要な構造情報がないため、テキストデータをデータベース形式にレンダリングできる場合でも、テキストデータと構造化データの比較は大変なのです（インモン と クリシュナン、２０１１年）。

それでも、分析用のフォーマットでテキストデータを追加できるようになったことで、データウェアハウスの可能性は広がりました（インモン と クリシュナン、２０１１年）。

ただ、企業には、機械的に作成・送信されたデータである『機械生成データ』という、もう一つのタイプのデータがさらに存在します。

機械生成データ

機械生成データには、以下のように様々な種類があります：

• 製造された素材に関するあらゆることを測定する製造管理機器
• 特定財産に代わる活動量を測定する運搬機械
• 小売店の駐車場を把握するドローン
• 航空機のブラックボックスなど、航空関連からのテレメトリー情報

機械で生成されたデータには、ユニークな性質がいくつかあり、その多くはほとんど、あるいは全く価値がありませんが、一部の機械生成データには大きな価値があります（タレブ、他、２０１８年）。

機械生成データのもう一つの特徴は、膨大な量のデータを生成できる点です。機械によって生成されるデータの量は、テキストと構造化されたデータの両方によって生成されるデータの量を上回りますが、機械からの膨大なデータには、それなりの課題があります（バレンドゥ、２０１６年）。

機械で生成されたデータの初期は、データレイクに入れられていました。データレイクは、機械で生成されたデータを保持する場所に過ぎず、データレイクにあるデータを利用するには、データレイクの上に置かれたインフラが必要でした（アームブラスト、他、２０２１年；インモン、データレイクハウスの構築）。

このインフラの目的は、データレイクにあるデータの分析的利用の促進であり、インフラの要素には、以下のようなものがあります：

• メタデータ
• タクソノミー／オントロジー
• リネージ
• ソーシング
• データの関係
• 確定
• 要約アルゴリズム

(シヤル、２０２１年）

機械生成データの課題

データサイエンティストが直面する最大の課題の1つは、機械が生成したデータからの「有用なデータ」と「余計なデータ」の識別・分離です（インモン、２０１６年）。例えば、データサイエンティストが直面する問題を理解するために、出入りする人を見るのに店舗の出入り口に設置された監視カメラを考えてみましょう。このカメラは２４時間稼働していて、コンマ１秒ごとに画像を撮影しています。

ある日、不法侵入があったため、店長は監視カメラのデータを見なければいけません。店長は、そこにいるはずのない人が建物に入っていないかを探しますが、それには、膨大な数の画像の中から、お目当ての１枚を探し出さないといけません。その「膨大な数の画像」には「非常に重要なデータ」が含まれている可能性があるかもしれませんが、「１枚の重要な画像」には「膨大な量のデータ」が隠されているのです。

これと同じ問題、つまり、「大量のデータのうち、重要なのはごく一部の生成データのみ」というのは、機械で作られたデータがある場合、ほとんどすべてのケースで繰り返されます（インモン、２０１６年）。

データレイクの上に分析構造を配置すると、最終的な結果を「データレイクハウス」と呼ぶことができます。分析インフラを構築すると、データレイクハウスは、エンドユーザーがアクセスや分析をするための場所となります（レステブ、２０２１年；シヤル、２０２１年）。

機械が生成したデータ以外のデータもデータレイクハウスに入れることができるのでしょうか？もちろんです。テキストデータ、構造化データ、その他のデータタイプを置くことができ（シヤル、２０２１年）、多くの場合、それが便利です。

データレイクハウスの分析インフラを作れば、レイクハウスで見つけたデータをデータウェアハウスのデータとブレンドすることができます（シヤル、２０２１年）。そうすることで、強力な新種の分析を生み出すことができるのです。

データウェアハウスとデータレイクハウス

「データウェアハウスとデータレイクハウスは同じものなのか？」という面白い疑問があります。この問いを理解するために、部屋に座っている２人のいとこを考えてみましょう。一人は太郎さんで、もう一人は花子さんです。太郎さんと花子さんは同じでしょうか？確かに、似ているところはたくさんありますね。顔、体型、民族的な成り立ち。ただ、違うところもあります。太郎さんは男性で、花子さんは女性です。確かに二人には共通のDNAがありますが、DNAが同じというわけではありません。

なので、似ている部分はありますが、太郎さんと花子さんは同一人物ではないですね。

データウェアハウスとデータレイクハウスを比較した場合、サンプルの原理が当てはまります。

まとめ

進化に終わりはなく、データレイクハウスでデータアーキテクチャの進化が終わることはないでしょう。でもデータレイクハウスは、今日知られているデータアーキテクチャの進化を象徴しているのです。

「データウェアハウスの父」と呼ばれるビル・インモン氏は、６５冊の著書を出版しており、コンピューターワールド誌の「コンピューター史上最も影響力のある１０人」のうちの１人に選ばれました。コロラド州キャッスルロックに拠点を置くForest Rim Technology 社は、企業が顧客の声に耳を傾けるお手伝いを行っています。詳しくは、www.forestrimtech.comをご覧ください。

データウェアハウス、データレイク、データベースは、技術的アーキテクチャの中核となるコンポーネントです。Integrate.io の理念は、データ統合をシンプルにし、それによって高度なコーディングやデータエンジニアリングなしに、ソースからサポート対象のシステムへデータを移動できるようにすることです。そうすると、より良い意思決定のために、ビジネスに関する完璧なインサイトを生み出すことができるでしょう。ぜひ今すぐお問い合わせ下さい 。

参考資料

• Akilan, A. (2015, February). Text mining: Challenges and future directions. In 2015 2nd International Conference on Electronics and Communication Systems (ICECS) (pp. 1679-1684). IEEE.
• Almeida, M. S., Ishikawa, M., Reinschmidt, J., & Roeber, T. (1999). Getting started with data warehouse and business intelligence. IBM Redbooks.
• Armbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021). Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced
• Analytics. CIDR. 
• Ariyachandra, T., & Watson, H. J. (2008). Technical opinion Which data warehouse architecture is best?. Communications of the ACM, 51(10), 146-147.
• Blumberg, R., & Atre, S. (2003). The problem with unstructured data. Dm Review, 13(42-49), 62.
• Botzenhardt, A., Witt, A., & Maedche, A. (2011). A Text Mining Application for Exploring the Voice of the Customer.
• Cembalo, A., Pisano, F. M., & Romano, G. (2012, July). An approach to document warehousing system lifecycle from textual ETL to multidimensional queries: A proof-of-concept prototype. In 2012 Sixth International Conference on Complex, Intelligent, and Software Intensive Systems (pp. 828-835). IEEE.
• Chaudhuri, S., & Dayal, U. (1997). An overview of data warehousing and OLAP technology. ACM Sigmod record, 26(1), 65-74. 
• Chen, F., Deng, P., Wan, J., Zhang, D., Vasilakos, A. V., & Rong, X. (2015). Data mining for the internet of things: literature review and challenges. International Journal of Distributed Sensor Networks, 11(8), 431047.
• Chen, Q., Zobel, J., & Verspoor, K. (2017). Duplicates, redundancies and inconsistencies in the primary nucleotide databases: a descriptive study. Database, 2017.
• Codd, E.F. (1970). A relational model for large shared data banks. Communications of the ACM, 13, 377-387.
• Date, C. J. (1986). An introduction to database systems (4th ed., vol. 1). Reading, MA: Addison-Wesley.
• DeLone, W. H. (1988). Determinants of success for computer usage in small business. MIS quarterly, 51-61.
• Eberendu, A. C. (2016). Unstructured Data: an overview of the data of Big Data. International Journal of Computer Trends and Technology, 38(1), 46-50. 
• Gould, J. D., Boies, S. J., & Lewis, C. (1991). Making usable, useful, productivity-enhancing computer applications. Communications of the ACM, 34(1), 74-85.
• Hamad, K. A., & Mehmet, K. A. Y. A. (2016). A detailed analysis of optical character recognition technology. International Journal of Applied Mathematics Electronics and Computers, (Special Issue-1), 244-249.
• Inmon, W. H. (2005). Building the data warehouse. John Wiley & Sons.
• Inmon, B. (2016). Data Lake Architecture: Designing the Data Lake and avoiding the garbage dump. Technics Publications.
• Inmon, B. (2017). Turning text into gold: Taxonomies and textual analytics. Technics Publications.
• Inmon, W H (2019) Class notes, Practical Textual Analytics, by Forest Rim Technology, Denver, Colorado 
• Inmon, B., & Krishnan, K. (2011). Building the Unstructured Data Warehouse: Architecture, Analysis, and Design. Technics publications.
• Inmon, W. H., & Nesavich, A. (2007). Tapping into Unstructured Data: Integrating Unstructured Data and Textual Analytics into Business Intelligence. Pearson Education.
• Jarke M., Lenzerini M., Vassiliou Y., Vassiliadis P. (2000) Data Warehouse Practice: An Overview. In: Fundamentals of Data Warehouses. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-04138-3_1
• Jlailaty, D., Grigori, D., & Belhajjame, K. (2018, May). Email business activities extraction and annotation. In International Workshop on Information Search, Integration, and Personalization (pp. 69-86). Springer, Cham.
• Kimball, R., Ross, M., Thorthwaite, W., Becker, B., & Mundy, J. (2008). The Data Warehouse Lifecycle Toolkit. John Wiley & Sons. 
• L’Esteve, R. C. (2021). Delta Lake. In The Definitive Guide to Azure Data Engineering (pp. 321-346). Apress, Berkeley, CA. 
• McCune, J. C. (1998). Data, data, everywhere. Management Review, 87(10), 10. 
• O'Brien, E. J., & Myers, J. L. (1985). When comprehension difficulty improves Memory for Text. Journal of Experimental Psychology: Learning, Memory, and Cognition, 11(1), 12.
• Salinesi, C., & Gam, I. (2006, June). A requirement-driven approach for designing data warehouses. In Requirements Engineering: Foundations for
• Software Quality (REFSQ'06) (p. 1). M. Golfarelli, S. Rizzi, Data Warehouse Design - Modern Principles and methodologies", McGraw-Hill, 2009.
• Shiyal, B. (2021). Modern Data Warehouses and Data Lakehouses. In Beginning Azure Synapse Analytics (pp. 21-48). Apress, Berkeley, CA.
• Taleb, I., Serhani, M. A., & Dssouli, R. (2018, November). Big data quality assessment model for unstructured data. In 2018 International Conference on Innovations in Information Technology (IIT) (pp. 69-74). IEEE.
• Ullman, J.D. (1982). Principles of database systems. Rockville, Maryland: Computer Sciences Press.
• Vassiliadis, P. (2009). A survey of extract–transform–load technology. International Journal of Data Warehousing and Mining (IJDWM), 5(3), 1-27.
• Vanlommel, E., & De Brabander, B. (1975). The organization of electronic data processing (EDP) activities and computer use. The Journal of Business, 48(3), 391-410. 
• Weinberg, Gerald (1971), THE PSYCHOLOGY OF COMPUTER PROGRAMMING,