モダン・データスタック

Definition:Modern Data Stack

モダン・データスタックとは、クラウド・オブジェクトストレージ、データ処理、テーブルフォーマット、カタログ、クエリエンジン、BIなどの機能を疎結合な専門コンポーネントとして組み合わせ、標準インターフェースを介して柔軟に構成する現代的なデータ基盤アーキテクチャである。

従来型のデータウェアハウスでは、ストレージ、メタデータ管理、SQL処理、最適化、セキュリティなどが一つの製品に強く統合されていた。これに対してモダン・データスタックでは、「データをどこに置くか」「データをどういう形式で管理するか」「現在のテーブル状態をどう発見するか」「どう計算するか」などを分離することが基本思想となる。

また、「モダン・データスタック」と「レイクハウス」は同義ではない。レイクハウスはデータレイク上にDWH的なデータ管理機能を実現するアーキテクチャであり、モダン・データスタックは、それを含めてデータ収集、変換、ストレージ、カタログ、コンピュート、BIなどを複数の専門コンポーネントで構成する、より広い概念である。

モダン・データスタックの成立以前

現在「モダン・データスタック」と呼ばれるデータ基盤のレイヤー構造は、最初から現在の形で設計されたものではない。むしろ、1990年代から2010年代にかけて発展したデータウェアハウス、分散処理、クラウドストレージ、オープンソースのクエリーエンジンなどが、段階的に分離・再編成された結果として成立したものである。

1990年代から2000年代にかけての企業データ基盤では、データウェアハウスが中心的な存在であった。Teradata、Oracle、IBM DB2などに代表される従来型のDWHでは、ストレージとコンピュートが強く結び付いていた。データを格納する場所とSQLを実行する場所が基本的に同じシステムの内部にあり、現在のように「計算資源を必要なときだけ増減させ、データは別の永続ストレージに置く」という発想は一般的ではなかった。

Hadoopによるストレージとコンピュートの分離への転換

2000年代後半になると、Googleが公表したGFS(Google File System)およびMapReduceの論文に影響を受けたHadoopが普及し始める。Hadoop Distributed File System(HDFS)が大容量データを分散して保存し、MapReduceがそのデータを分散処理する構成は、従来型DWHとは異なるデータ基盤の方向性を示したものである。

ただし、Hadoopではストレージとコンピュートが完全に独立していたわけではない。HDFSを構成するノードが同時に計算処理も担うため、データ量と計算量を完全に独立して拡張することは難しかった。それでも「大量のデータを専用DWHだけに依存せず、分散ファイルシステム上に置き、複数の処理エンジンから利用する」という考え方は、後のデータレイクの基礎となった。

データレイクの登場

2010年代に入ると、Amazon S3をはじめとするクラウドオブジェクトストレージがデータ基盤の重要な構成要素になった。S3はコンピュート資源とは独立して大量のデータを保存でき、必要に応じて異なる計算基盤からアクセスできる。この性質によって、データをまずオブジェクトストレージに集約し、その上で必要な処理を実行する「データレイク」という考え方が広まったのである。

ここで現在のレイヤー構造につながる重要な変化が生じた。データを保存するストレージと、データを処理するコンピュートを別々に考えることが可能になったためである。ストレージにはS3などを利用し、処理にはHadoop、Spark、Prestoなどを利用するという構成が成立した。これは現在の「ストレージとコンピュートの分離」の原型である。

クラウドDWHによるコンピュートとストレージの分離

2012年に創業したSnowflakeは、2014年から一般提供を開始し、この分離をさらに洗練させた存在である。Snowflakeでは、従来型DWHのようにデータ保存とクエリー処理を単一のサーバー群に固定するのではなく、ストレージとコンピュートを論理的に分離する設計が採用された。

この考え方は、現在のモダン・データスタックを理解するうえで重要である。永続データはクラウドストレージに保持し、クエリー処理に必要なコンピュートを独立して増減させることができるからである。後に登場する各種のクラウドデータサービスも、程度の差はあるものの、この分離を基本的な設計思想として取り入れていった。

分散SQLエンジンとオープンなコンピュート層

一方、Facebookが2012年に開発し、2013年にオープンソース化したPrestoは、Hadoopのファイルシステムそのものに依存せず、大規模データに対してインタラクティブなSQLを実行する分散クエリーエンジンとして登場した。2019年、開発方針をめぐる対立からPrestoの原開発者たちがFacebookを離れてプロジェクトをフォークし、PrestoSQLを立ち上げた。Facebook側の系統はLinux Foundation傘下のPresto Foundationに寄贈されPrestoDBと呼ばれるようになり、PrestoSQL側は2020年にTrinoへと改称された。以後、コミュニティ開発の中心はTrinoに移り、S3などに置かれたデータを独立した分散クエリーエンジンから直接検索するというモデルが広く定着した。

Apache Sparkも同様に重要である。SparkはSQLだけでなく、ETL、機械学習、ストリーム処理などを含む汎用的な分散コンピュート基盤へと発展した。これにより、永続データを持つストレージと、そのデータを処理する複数のコンピュートエンジンを組み合わせるという構造が一般化したのである。

ETLの分離と「モダン・データスタック」

2010年代後半になると、データ基盤そのものだけでなく、データを取り込んで変換する処理も分離され始めた。Fivetranなどのデータ統合サービスによってSaaSや業務システムからDWHへのデータ取り込みを行い、dbtによってSQLベースの変換処理を管理するという構成が普及した。

これによって、従来一体化していたデータ基盤が、データ収集、ストレージ、変換、クエリー、BIという複数の専門的なサービスに分解されるようになった。この「特定の巨大な製品ですべてを処理する」のではなく、「APIや標準的なインターフェースで複数の専門サービスを接続する」という思想こそが、モダン・データスタックの重要な特徴である。

データレイクハウスへの発展

しかし、データレイクには大きな問題があった。S3などにParquetファイルを保存するだけでは、従来のDWHが提供していたACIDトランザクション、スキーマ管理、更新・削除、時点管理、効率的なクエリー処理などを十分に実現できなかったのである。

この問題を解決するために登場したのが、Delta Lake、Apache Iceberg、Apache Hudiなどのテーブルフォーマットである。これらは単なるファイル形式ではなく、オブジェクトストレージ上に存在する複数のデータファイルを「一つのテーブル」として管理するためのメタデータとテーブル管理方式を提供する。それぞれの出自は異なる。Delta Lakeは2017年頃からDatabricks社内で開発され、2019年にオープンソース化された。Apache Icebergは、既存のHiveテーブル形式が抱えていた性能・整合性上の問題を解決するためにNetflix社内で開発され、2018年にApache Software Foundationへ寄贈された。Apache Hudiは2016年にUberが開発し、2017年にオープンソース化、2020年にApacheのトップレベルプロジェクトへと昇格している。

これによって、S3のような安価で大規模なオブジェクトストレージをデータの永続層として利用しながら、DWHに近いテーブル管理機能を実現する「データレイクハウス」が成立した。ここで初めて、現在のモダン・データスタックにおける「ストレージ」「テーブルフォーマット」「クエリーエンジン」という明確な分離が形成されたのである。

カタログ層の独立

さらに重要なのが、テーブルフォーマットとカタログの分離である。IcebergなどのテーブルフォーマットがテーブルのスナップショットやManifest、スキーマなどを定義する一方、クエリーエンジンが「どのテーブルを利用できるのか」「そのテーブルの現在のメタデータはどこにあるのか」を発見するためにはカタログが必要になる。

従来はHive Metastoreなどがこの役割を担っていたが、クラウド化とマルチエンジン化が進むにつれて、より標準化されたカタログインターフェースが求められるようになった。Iceberg REST Catalogはその流れの中で重要な位置を占める。2024年6月、SnowflakeはDremioなどの協力を得てPolaris Catalogを発表し、同年8月にApache Software Foundationへ寄贈した。これがインキュベーションを経てApache Polarisとなり、Iceberg向けの標準的なカタログ実装としての地位を確立していったのである。

この段階になると、データ基盤は「DWH」という一つの製品ではなく、カタログ、テーブルフォーマット、コンピュート、ストレージという複数の独立した構成要素の組み合わせとして理解できるようになる。

モダン・データスタックの現在

現在のモダン・データスタックは、この分離をさらに進めたものである。最下層にはS3、Google Cloud Storage、Azure Blob Storageなどのオブジェクトストレージがあり、その上にIceberg、Delta Lake、Hudiなどのテーブルフォーマットが位置する。クエリー処理についてはTrino、Spark、Flink、Databricks、Snowflakeなど複数のエンジンを用途に応じて利用できる。

さらにその上または横に、Polaris、Unity Catalog、AWS Glue Data Catalogなどのカタログ・ガバナンス機能が存在する。このため、現在のレイクハウスは単純な上下の階層というよりも、カタログ、テーブルフォーマット、コンピュート、ストレージがAPIや標準仕様を介して疎結合に接続された構造と捉える方が正確である。

「モノリシックDWH」から「分離型データ基盤」へ

この歴史を一本の流れとして捉えると、モダン・データスタックの本質は、単に新しい製品が増えたことではない。1990年代の「ストレージとコンピュートが一体化したDWH」から、Hadoopによる分散処理、クラウドオブジェクトストレージによるデータレイク、Snowflakeなどによるストレージとコンピュートの分離、PrestoやSparkによる独立したクエリーエンジン、Icebergなどによるテーブルフォーマットの標準化、そしてPolarisなどによるカタログの独立へと、データ基盤の各機能が段階的に分離されてきた歴史といえよう。

したがって、現在の「Catalog → Table Format → Compute → Storage」という構造は、厳密には固定的な四層構造というより、データ基盤を構成する責務が分離された結果として生まれたレイヤード・レイクハウス・アーキテクチャと理解するのが適切である。そして、この分離こそが、複数のクエリーエンジンから同じデータを利用すること、コンピュート資源を独立して拡張すること、ストレージを長期的に維持すること、さらにはベンダーに依存しないオープンなデータ基盤を構築することを可能にした。

Mathematics is the language with which God has written the universe.





















データ基盤におけるデカップリング ソフトなディクショナリ コンテキスト長 FreeToken LLM並列化方式 通信機器の歴史