1.1　データ革命

　PCやスマートフォンの普及に伴い社会全体がデジタル化されていくにつれ、企業に貯蓄されるデータ量は増大してきました。2011年にMarc Andreessenが「Why Software Is Eating the World¹」を寄稿し、ソフトウェアの威力を示してから10年強が経ち、この数年はChatGPTをはじめとする大規模言語モデル（Large Language Models; LLM）が新たな体験を生み出しつつあります。LLMを支えているのは巨大な計算リソースと、インターネット上の膨大に蓄積されたデータです。企業はソフトウェアやIoTデバイスからより多くのデータを収集することができるようになり、人々もSNSなどを通じてより多くのデータを生成するようになりました。このような背景から、「ビックデータ」という言葉が2011年ごろから広がり始めました。その言葉の広がりに合わせるように、膨大なデータを一箇所に集積し分析できるスケーラブルなデータベースのニーズが急拡大します。そのようなデータベースは90年代頃からデータウェアハウス（Data Warehouse）と呼ばれていましたが、近年になってより多くの企業で必要とされるようになったのです。

　Google BigQuery、Amazon Redshift、Snowflake、Databricksといった現在主流になっているクラウド型データウェアハウスは2010年台前半に立て続けに登場しています。それまではセットアップすることすら大変な労力を伴うデータウェアハウスでしたが、クラウド型のフルマネージド型サービスが登場したことで、利用ハードルは劇的に下がりました。

　近年はソフトウェアや企業活動の改善のため、仮説検証をデータを用いて実施する例も非常に増えています。例えば、A/Bテストに代表されるようなソフトウェア上のユーザー分析などでは、多くのユーザー行動データを蓄積して分析していきます。また、顧客セグメント分析を実施し、より効果のあるセグメントに営業リソースを集中させたり、潜在的なターゲット顧客を見つけ出すことも行われています。これらの手法自体は昔から存在しますが、ソフトウェアとデータウェアハウスの普及に伴って、より低コストかつ素早く実施することが可能になっています。

　2016年ごろからは機械学習やAIの時代が本格的に到来し、多額の投資が行われるようになりました。機械学習、特にニューラルネットワーク系のアルゴリズムでは非常に大量のデータを必要とするため、データウェアハウスは機械学習のためのデータ保管庫としても利用されるようになりました。2022年から2023年にかけては、MidjourneyやChatGPTといった超巨大な機械学習モデルによる高精度なコンテンツの自動生成が、社会に衝撃を与えました。多くの企業がこのような大規模モデルを自社サービスや営業活動に組み込むことを考えており、ファインチューニングのために、自社のデータウェアハウスに蓄積されたデータを利用することになるでしょう。

　「データ革命」や「AI革命」と呼ばれることもあるこのような社会の流れは確かに存在しますが、一方で批判の対象にもなっています。このようなバズワードに釣られ流行りに乗ろうとして、ユースケースや意義を十分に検討しないままデータやAIの利活用を進めようとしても、その多くは失敗に終わってしまいます。よく聞く例として、営業活動そのものを疎かにしてデータ活用や分析でどうにかしようとするケースあります。「データ分析やデータ活用は売上を一定割合改善できるが、そもそもの売上が少ない状態では効果が薄い」と言われるように、データ分析は万能ではありません。このような場合は、データ分析やデータ活用に投資するよりも、営業活動を増やしたりターゲットセグメントを拡大するソフトウェアへの投資といった施策の方が重要です。

　本書では、データの取り扱い方や考え方についてはあまり触れません。しかし、データウェアハウスやデータ基盤を構築する際に最も重要なことは、「導入して何を実現するのか？」というビジョンを言語化し、初めのうちはそこから逸れないようにすることです。そして、そのビジョンを仲間と共有してプロジェクトを進めていくことをお勧めします。

1.2　データ基盤：データのエコシステム

　文字通り、データウェアハウスは、データを保管し分析するための「データの倉庫（工場）」です。この倉庫に「原材料」となるデータを送り込むための仕組みや、この倉庫から分析結果を「出荷」してユーザーに届けるための仕組みが別途必要になります。その流通システム全体のことをデータ（分析）基盤と呼びます。例えば、以下のようなツールがデータ基盤に含まれます。

　・ETLツール： データソース（各種アプリケーション）に蓄積されたデータを収集しデータウェアハウスに保管する

　・データ変換ツール： データウェアハウス内のデータを利用しやすいように整形・クリーニング・集計する

　・BIツール： データウェアハウスの分析データをテーブルやグラフのような形でビジュアライズする

　これ以外にも、要件に応じて、データ品質管理ツールやリバースETLツールなど、さまざまなツールがデータ基盤に統合されることになります。データ基盤の全体像については「1.6 データ基盤を構成する技術」で詳しく紹介します。

1.3　Big Data is Dead

　データウェアハウスでは、膨大な量のデータを処理する必要があるため、それに最適化された分散型システムアーキテクチャが採用されています。しかし、多くの企業にとって、データ基盤の真の価値は、膨大な量のデータを処理出来ることではないかもしれません。2023年、BigQueryの創業開発者であるJordan Tigani氏が「Big Data is Dead²」というブログを投稿し、話題となりました。そのブログの中では、BigQueryユーザーのユースケースを分析したなかで、ビッグデータと呼ばれる非常に巨大なデータ（テラバイト以上）を扱う必要はほとんど存在せず、また巨大なデータに対して問い合わせ（クエリ）を行う必要もほとんど存在しないと指摘しました。例えば、古いデータにアクセスするようなユースケースはほとんど存在しないため、過去データを圧縮したり集計データのみを保持するようにすることでほとんどの場合十分であると述べています。また、近年のコンピューティングの発展によって巨大なインスタンスもクラウド上で簡単に調達できるため、分散処理基盤が必要になるケースも限られていると言っています。これまで、BigQueryをはじめとした分散型のデータ基盤の有用性は、加速度的にデータの蓄積が進んでいくことが前提に存在しました。しかし、そのような予測は多くの企業にとっては当てはまらなかったということになります。

　このような事実を踏まえると、データウェアハウスの選択肢は非常に広がります。セルフホスト型のデータウェアハウスのオープンソースソフトウェア³などを採用する選択肢もあるでしょう。もちろん、クラウド型のデータウェアハウスは運用コストの点で分がありますし、コンピューティングリソースを柔軟に割り当て可能なため、引き続き最有力な選択肢に入るでしょう。

　一方で、組織内でデータ活用を行うという目的を達成するためには、何を考慮する必要があるのでしょうか。

1.4　サイロ化の課題

　データ活用を進める上での最大の障壁は「サイロ化」であると考えられています。サイロ化とは、各部署で使われているシステムが分断され、部署間での連携が困難になっていくことを意味しています。各部署のデータを横断して利活用を進めることが難しくなり、業務プロセスの全体を管理することが難しくなります。また、組織や部署を跨いだコラボレーションの阻害要因にもなり、イノベーションを生み出す上での障壁として立ちはだかります。

　サイロ化の課題を解消するためには、各システムで管理されているデータを抽出して、データウェアハウスに集積することが有効です。これにより、データウェアハウス上で複数のシステムのデータを自由に組み合わせて分析することが可能になります。たとえば、新規顧客開拓のため、営業が成功する確率が高い企業やユーザーを見つけ出したい場合を考えてみます。既存顧客の情報は、マーケティングツールや自社サービスのデータベース、ユーザーロギングツールなどに散らばっています。まず、それらをデータウェアハウスに集積し、ウェアハウス上でデータを掛け合わせて分析することで、既存ユーザーがどのようなセグメントに多く属しているのかが分かるでしょう。また、どのようなメディアから流入したユーザーがより自社サービスを愛用しているかも分かるかもしれません。このような分析をもとに、新たな顧客セグメントを発掘する施策を検討したり、どのような媒体にマーケティング費用を投下するかを検討できます⁴。

　もし、これらのデータが各所に散らばっていたら悲惨なことです。各所に散らばったデータをまず手元に集めてきて分析するような必要が都度生じるとしたら、途中で諦めてしまうかもしれません。データが一箇所に集約され、常に使える状態になっている⁵ことで、より多くの人がデータを活用しようとトライするでしょう。データ基盤は、データ活用のハードルを下げる役割を果たします。

　しかし、仮にデータ基盤が存在したとしても、データのサイロ化は進みます。なぜなら、各部署は常に改善を試みており、新しいデータの収集や作成、新規システムの導入を行なっていきます。もしデータ基盤の管理者がこのことを把握できなければ、それらの新しいデータはデータ基盤に集積されないままサイロ化します。多くの場合、組織間のコミュニケーションが減少し部署ごとに最適化を試みるようになることで、このような問題が発生します。つまり、組織のサイロ化と、データのサイロ化は切り離せない問題なのです⁶。

データマネジメント

　サイロ化の問題をはじめとして、データの利活用に向けては、データの管理・運用に関する課題が多く存在します。そのような課題に対応する業務はデータマネジメントとして体系化され、非常に幅広いトピックが含まれます。例えば、データ取り扱い倫理に関するトピックには、個人情報の取り扱いなどが含まれます。個人のプライバシーを侵害することなく、組織のデータ資産を活用していくための取り組みを実施します。また、データセキュリティのように、組織のデータ資産を保護することもデータマネジメントの一部です。図1.2は、DAMA International⁷が公開している、データマネジメントにおける10の知識領域について示したものです。

　データ基盤を構築・運用する上では、このようなマネジメント領域についても深く理解し、実践していくことが必要になります。

1.5　データ基盤とアプリケーションシステムの違い

　サイロ化を阻止するためのデータ基盤は、通常のアプリケーションシステムと何が異なるのでしょうか。当然のことながら、そもそもの目的が異なっています。まず、データ基盤が「分析・集計」を目的としているのに対し、アプリケーションシステムはデータの「保存・変更」を目的としています⁸。

　データ基盤はデータをスキャニングして集計する処理を高速化するために、データアクセスに対する並列性を向上させたり、列指向（Columnar）のストレージシステムを採用しています。列指向とは、データを列毎に格納する方式のことです。この方式の場合、ある一列のデータをまとめて取得するのが高速になります。分析・集計の場合は列ごとに集計する場合が多いため、このようなデータの持ち方を行うことで効率化が図れます。一方、アプリケーションシステムでは、行ごとに参照・更新するユースケースがほとんどのため、行指向のストレージシステムを採用しています（図1.3）。

　また、データ基盤は様々な種類のデータを一元管理して分析するため、柔軟なスケーラビリティが求められます。一日の中で、小さなデータセットに対してクエリすることもあれば、大きなデータセットをクエリすることもあるため、常に柔軟にスケールできる必要があります。一方で、アプリケーションシステムでは、一時的なアクセス集中などを除けば、システム負荷は予測可能で、緩やかに変化していきます。そのため、スケーラビリティは必要ではありますが、比較的緩やかに対応できれば良いケースが多いです（図1.4）。

　アプリケーションシステムはデータを正しく保存し適切に変更されることを保証するため、書き込み・読み込み性能の要求が厳しかったり、様々な制約（Constraint）を付与することが出来ます。一方、データ基盤ではアプリケーションシステムほどの厳密性は要求されず、分析パフォーマンスを優先するケースがあります⁹。

1.6　データ基盤を構成する技術

　アプリケーションシステムがデータベース単体では成り立ってないように、データ基盤もデータウェアハウス単体では成り立ちません。データ基盤の目的は、データを集積して分析可能な状態に加工してユーザーに提供することです。近年、データ利活用へのニーズの高まりに合わせ、各種周辺ツールが次々と登場してきました。例えば、データへのアクセス権限管理などを担うデータガバナンス（Data Governance）に関するツールや、データを取り込み加工する一連のワークフローを管理するデータオーケストレーション（Data Orchestration）に関するツールなどがあります。これらのツールはPostgreSQLなどのアプリケーションDBにも対応していることがありますが、基本的にはデータウェアハウス向けに開発されています。このセクションでは、データ基盤を構成する技術について概観します。

データウェアハウス

　データウェアハウスは、データに対してクエリを発行し計算するコンピューティングシステムであり、そのデータを保管するストレージシステムを包括して指すこともあります。コンピューティングレイヤーでは大規模なデータに対して高速に計算をかけるため強力な並列処理機構が採用されています。シェアード・ナッシング・アーキテクチャ（Shared Nothing Architecture; SN）などがその一例になります。ストレージレイヤーでは、大きなデータを保管するコストを削減するためのデータ圧縮のアルゴリズムや、データへの高速なアクセスを実現するデータの持ち方などが工夫されています。前述した列指向ストレージなどがその一例になります。データウェアハウスはその名の通り、「データの保管庫」であり、データが整理された状態が保たれ、素早く取り出せることが重要になります。

データレイク

　データウェアハウスと似たものとして、データレイク（Data Lake）というものがあります。データレイクは、ストレージシステムです。行列データ（CSVデータなど）に限らず、ログデータであったり、画像・動画といったあらゆるデータを保管するストレージです。データレイクは、その名の通りデータを放り込んでおく「池」です。データソースからのデータをほとんどそのままの形式で保管することができます。例えば、すぐにデータウェアハウスに入れる必要はないが保管しておきたいデータや、画像などのデータウェアハウスに入れにくいデータなどを保管する役割があります。ウェアハウスで処理したデータを保管する場所として用いられることもあります。また、データウェアハウスに何かしらのトラブルが生じてデータが失われた場合のバックアップとしての役割もあります。そのため、データレイクには低コストであることと高耐久性が求められます。近年はAmazon S3やGoogle Cloud Storageなどのクラウドストレージをデータレイクとして用いるケースが多いです。

　なお、近年ではデータウェアハウスとデータレイクを一体化したクラウドサービスが一般的になっています¹⁰。そのため、データレイクを別で用意する必要はあまり無くなってきました。

ETL/ELT

　データソースからデータを抽出し、データレイクまたはデータウェアハウスにデータをロードする処理のことをETLと呼びます。ETLは、「Extract（抽出）」、「Transform（変換）」、「Load（ロード）」のアクロニムです。データソースからデータを取り出すことを「抽出」、データを変換したり必要な部分のみ切り出すことを「変換」、データレイクやデータウェアハウスにデータを入れることを「ロード」と呼んでいます。ストレージやコンピューティングのコストが高かった時代はETLの順で実施することが多かったのですが、近年はストレージコストの低下やコンピューティングの最適化が進んだことで、ELTの順で実施することが一般化しています。ELTとは、データソースのデータをそのままの形式でデータウェアハウスにロードし、データウェアハウス内でデータを変換する、というアプローチです。このアプローチでは、ETLの変換処理では失われてしまう変換前のデータをデータウェアハウス内に保持しておくことができるため、将来的にそのデータを使いたくなった場合にすぐ利用できます。また、変換処理自体もデータウェアハウスで行う方が処理パフォーマンスや管理・運用の面で優位に働きやすいという利点があります。

　ETL/ELT処理はデータ量が多く負荷が高くなりやすいため、分散処理基盤であるApache Sparkや、Embulkなどが使われることが多いです。近年はクラウド型のETL/ELTツールが登場しており、より学習・実装コストがかからなかったり、管理コストが抑えられたりすることから採用例が増えています。

　ETL/ELTツールについての詳細は第6章「ETLとReverse ETL」にて紹介します。

リバースETL（データアクティベーション）

　リバースETL（Reverse ETL）またはデータアクティベーション（Data Activation）は、データウェアハウス上で分析したデータを、別のアプリケーションに書き込む処理のことを指します。これまではデータウェアハウスがデータの最終到達地点であることが多かったのですが、近年はデータウェアハウスで行った分析結果をアプリケーションに戻したいというニーズも高まっています。そのための処理がリバースETLになります。基本的にはETLと似ておりETLツールで行えることが多いですが、リバースETLに特化したツールも存在します。こちらも、詳細は第6章「ETLとReverse ETL」にて紹介します。

データ変換管理

　ELTが一般化するのに伴い、データウェアハウス内でのデータ変換を行うユースケースが増加してきました。変換のプロセスでは、異なるデータソースからのデータを組み合わせながら、ユーザーが求めるデータセットを作成していく必要があります。しかし、そのような作業は容易に複雑化し運用コストが加速度的に増大していきます。近年登場してきているデータ変換管理ツールがこの課題にアプローチしようとしています。これらのデータ変換管理ツールでは、一連のデータ変換をコードなどで管理した上で影響範囲を分かるようにする機能などを提供しています。データに対するテスト機能やドキュメント機能なども含むツールも存在し、ソフトウェア開発でのベストプラクティスがデータ変換に対しても適用できるようになっています。

　データ変換管理ツールに関する詳細は第5章「実践的データ基盤の構築」にて紹介します。

ビジネスインテリジェンス（BI）

　データ基盤は、「データを分析し、ユーザーに提供する」ことがゴールの一つであるため、ユーザーに提示するためのインターフェースが必要になります。多くのデータウェアハウスはCLIやドライバーで接続してクエリを発行し、結果を取得可能ですが、最終的にはそれらをグラフやチャートにして見たいのではないでしょうか。また、ユーザーにはクエリが書けないメンバーも含まれるため、より直感的なGUIで操作可能なツールを提供する必要があるでしょう。

　そのようなニーズに対応するのがビジネスインテリジェンス（Business Intelligence; BI）ツールになります。BIツールの基本的な機能は、ユーザーの代わりにデータウェアハウスに接続しデータを取得することと、データをビジュアライズすることです。おそらく人類にとって最も親しみのあるBIツールはExcelでしょう。しかし、Excelは他ユーザーとの共有が難しかったり、データ量が多い時のパフォーマンス問題や、運用保守が難しいなどの問題があります。そのため、そうした課題をクリアするためにさまざまなBIツールが存在します。なお、近年LLMの発展を背景に、自然言語での問合せをSQLに変換する取り組みも盛んになっているため、今後のBIツールのあり方は大きく変わるかもしれません。BIツールについての詳細は第8章「BIツール」にて紹介します。

データオーケストレーション

　データ基盤の一連のフローは、ELTツールなどでデータソースからデータを抽出し、データウェアハウスにデータをロードした上で、データ変換管理ツールでデータを変換します。このデータのフローをデータパイプライン（Data Pipeline）と呼びます。もしあなたがこのシステム管理者であったとしたら、このデータパイプラインを楽に構築・管理したいと思うのではないでしょうか。その状態を実現するのがデータオーケストレーション（Data Orchestration）ツールになります。古くから存在する一般的なワークフローエンジンを利用するケースの他、近年ではデータパイプラインに特化したツールも登場しています。データオーケストレーションツールは各種ツールと連携し、一連のワークフローを構築・管理・実行できるものです。データオーケストレーションツールに関する詳細は第7章「データオーケストレーション」にて紹介します。

データオブザーバビリティ

　アプリケーションデータベースと異なり、データウェアハウスは制約（Constraints）¹¹を備えていないことが多いです。また、データ処理の前提となっているアプリケーション側のバリデーション（Validation）が変更される場合もありますし、異常値が紛れ込むこともあります。このようなケースにおいて、意図しないデータをユーザーに提供してしまうことがあります。このような「バグ」は非常に発見が困難です。データオブザーバビリティ（Data Observability）ツールは、このようなデータの破損や異常を検知してくれるツールになります。データの利活用を進める上でデータの正確性や品質は非常に重要になるため、このようなツールは役立ちます。

データカタログ

　ユーザーがデータを利用したいと考えた場合、まずどのようなデータがあるのかを把握する必要があるでしょう。そのためのドキュメントをデータカタログ（Data Catalog）と呼びます。データカタログでは、どのようなデータセットが存在し、各カラムがどのようなデータであるのかといった情報や、そのデータセットの利用目的などが記述されています。ユーザーが適切なデータセットを発見し、利用することができるようにすることが必要です。データカタログも、データの利活用を進める上で重要な役割を果たします。専用のツールも存在しますが、データ変換管理ツールやデータウェアハウスに付属しているケースもあります。また、ツールに頼らずとも「ドキュメント」という形でユーザーが利用可能な状態であれば十分なケースもあります。データカタログもBI同様、自然言語による問合せとの相性が良いため、LLMによって今後大きく変わる可能性があります。

1.7　モダンデータスタック

　データ基盤を構成する技術は前述したものの他にもさまざま存在します。各技術はデータ基盤で必要な各機能に特化してきており、多くがクラウド型のSaaSツールやOSSとして提供されるようになって来ています。このようなツール群を総称してモダンデータスタック（Modern Data Stack; MDS）と呼びます。従来のデータ基盤はオンプレミスでホストされるETLツールとデータウェアハウスの組み合わせであるのに対し、モダンデータスタックは主にクラウドベースの各種専門ツールを組み合わせて、管理コストや学習コストが低く使いやすいデータ基盤の構築を目指します。

　モダンデータスタックはETLツールサービスを提供するFivetran社が提供した用語ですが、近年はこの考え方が一般化してきました。特に、クラウドベンダー以外が提供するデータウェアハウス製品を採用している企業において採用されるケースが多いです¹²。ただし、モダンデータスタックにはコスト面で割高になりやすい点や、全体の管理が難しくなるなどのデメリットもあるため、闇雲にツールを導入するのではなく、そのツールを導入することで得られる利点や、中長期的なコストを鑑みる必要があります。

1.8　参考文献・リンク

　第１章では、データ基盤の概観を紹介しました。データ基盤は歴史的にも非常に奥が深く、かつトピックも非常に多岐にわたります。その上、近年は技術の進歩が目まぐるしく、トレンドが数年で大きく変わっていく領域になっています。各トピックについて、本書で説明を省略している箇所があるため、より深く理解を得たい方に向けて、参考文献を紹介します。

データエンジニアリング

　・西田 圭介, ビッグデータを支える技術〜ラップトップ1台で学ぶデータ基盤のしくみ, 技術評論社, 2021

　・Joe Reis, Matt Housley, Fundamentals of Data Engineering, O'Reilly Media, Inc., 2022

　・Piethein Strengholt, Data Management at Scale: Best Practices for Enterprise Architecture, O'Reilly Media, Inc., 2020¹⁴

データマネジメント

　・DAMA International2, DAMA-DMBOK: Data Management Body of Knowledge: 2nd Edition, Technics Publications, 2017¹⁵

　・ゆずたそ, 渡部 徹太郎, 伊藤 徹郎, 実践的データ基盤への処方箋〜ビジネス価値創出のためのデータ・システム・ヒトのノウハウ, 技術評論社, 2021

　もちろんこれ以外にも多くの書籍やブログなどが存在していますので、是非情報収集を行ってみてください。情報収集源としては、以下のようなものがおすすめです。

　・各種コミュニティ・イベント（参加するだけでなく、交流や発表を行うのがおすすめ）

　・X（Twitter）

　・Medium

　なお、おすすめのブログやコミュニティについては第5章「実践的データ基盤の構築」で紹介しています。