Table of Contents
初期のデータ活用基盤（黎明期）
ビジネスにおけるデータ活用が注目される以前、企業の情報システムは主に個別の業務アプリケーション毎にデータを管理していました。各システムのデータはサイロ化（縦割り）されており、組織横断で必要な情報を探し出すだけでも困難でした。ストレージ容量や性能にも限界があったため、古いデータは順次削除する必要があり、長期的な履歴分析も容易ではありませんでした。この結果、同じデータが部署ごとに重複・矛盾して存在するケースも多く、全社的なデータの一貫性や整合性に欠け、システム横断的な分析結果の信頼性は低いものでした。こうした黎明期には、各部門が個別最適化されたアプリケーションを導入する一方で、データの統合管理や高度な分析基盤は未整備であり、経営意思決定にデータを十分活用できない状況が続いていました。
データウェアハウスの誕生と発展
こうした課題を解決するためにデータウェアハウス (DWH) 概念が登場しました。DWHとは、様々な業務システムからデータを集約し、時系列に沿って統合蓄積するための専用データベースです。1990年代後半にDWHが本格的に導入され始め、複数システムに分散していたデータを一箇所に集めて管理・分析できるようになり、黎明期に見られたデータ管理・活用上の問題を大きく解消しました。DWHの概念自体は1980年代に提唱され、1970年代のデータマート（部門ごとの小規模データ集計）に源流があります。IBMが1990年代初頭に商用化したことで各種データマートのサイロ化による非効率が改善され、企業全体のデータを統合的に吟味・分析できる環境が整ったのですtech-deliberate-jiro.com。これにより経営者や分析担当者は、組織横断で統一された「真実の単一源 (single source of truth)」に基づいて意思決定を行えるようになりました。
初期のDWHを支えた代表的な技術・製品としては、大規模並列処理を得意とするTeradataやIBMの情報倉庫製品、OracleやMicrosoft SQL Serverのデータウェアハウス機能などが挙げられます。これらはリレーショナルデータベース (RDBMS) 技術を基盤に、業務システムから抽出・変換・格納(ETL)された構造化データをスタースキーマなどの手法で整理・蓄積し、高速なSQLクエリで分析できるよう工夫されていました。DWH導入により過去の詳細なトランザクション履歴を長期間保持して傾向分析や予測モデル構築が可能となり、ビジネスインテリジェンス (BI) 分野が飛躍的に発展しましたpromotion.jsol.co.jp。一方で、当時のDWHにはいくつかの制約も存在しました。その1つは扱えるデータの種類です。DWHは主に構造化データ（数値やコード等）を対象としており、画像・音声・テキストなど非構造化データの直接格納・分析は不得手でした。また、スキーマ（データ構造）を事前定義して厳密にデータを統制するため、新しいデータ項目の追加や変更には時間がかかり、柔軟性に欠ける側面もありました。このような制約から、従来のDWH環境では企業内のあらゆるデータをカバーしきれず、特にログデータや文章データなど非構造化データの活用ニーズに応えられないという課題が顕在化していきました。
しかしDWH技術も進化を続け、2000年代に入ると大規模並列処理 (MPP: Massively Parallel Processing) や分散コンピューティングを活用したアプライアンス製品やソフトウェアが登場します。例えば、NetezzaやGreenplumといったMPP型データベース、IBMのInfoSphereやMicrosoft PDWなどが企業の大容量データ分析ニーズに対応しました。これらは複数のサーバーでデータを分散処理することでスケールアウトを実現し、従来より桁違いのデータ量を扱えるようになりました。さらに2010年代以降には、Google BigQuery、Amazon Redshift、Microsoft Azure Synapse Analytics、Snowflakeといったクラウドネイティブなデータウェアハウスサービスが台頭し、DWH技術の発展を牽引していますtech-deliberate-jiro.com。最新のDWHはストレージとコンピューティング資源の分離やオンデマンド拡張性を備え、従来システムより柔軟性・拡張性が飛躍的に向上していますtech-deliberate-jiro.com。
ビッグデータ時代とデータレイクの登場
2000年代に入り、インターネットの普及やデジタル化の進展によって企業が扱うデータの種類・量は爆発的に増加しました。ウェブサーバのログ、センサーデータ、ソーシャルメディア上のテキスト、画像・音声データなど、非構造化または半構造化データを分析したいニーズが高まります。従来のDWHではこれら多様なデータをそのまま蓄積・活用することが難しかったため、次第に新たなアーキテクチャが模索されました。その流れの中で登場したのがデータレイク (Data Lake) です。データレイクとは、データの形式や構造を問わず元のままの状態で大量のデータを蓄積できる中央集約ストレージ基盤を指しますtalend.com。特定の目的で正規化・加工されたDWHと異なり、データレイクでは事前のスキーマ定義やETLをせずに生データをそのまま保存し、必要に応じて後から処理・分析を行うスタイルを採りますtech-deliberate-jiro.com。これにより「今すぐ用途は決まっていないが将来役立つかもしれないデータ」を捨てずに蓄えておき、多角的な分析や機械学習に活用できるようになりました。
データレイクの実装を支えた代表的技術として、まず挙げられるのがオープンソースの分散処理フレームワークであるApache Hadoopです。Hadoopは安価な汎用サーバを多数束ねて大容量データを格納・処理できるエコシステムを提供し、2010年前後には多くの企業がオンプレミス環境にHadoopクラスターを構築して増え続けるデータの受け皿としましたtableau.comsbbit.jp。Hadoop Distributed File System (HDFS) 上に膨大なログやテキストを蓄積し、MapReduceやHiveを用いたバッチ処理で分析する形態は、まさにデータレイクの先駆けといえます。また同時期にクラウドが普及すると、クラウドストレージ（例えばAmazon S3やAzure Data Lake Storage, Google Cloud Storageなど）の上にデータレイクを構築するケースも増えましたsbbit.jp。クラウドストレージは高い耐久性と低コストを両立しており、オンプレHDFSに代わるスケーラブルなデータレイク基盤となっています。
データレイクは柔軟で強力な基盤ですが、一方で課題も顕在化しました。まず、Hadoop HDFSやクラウドオブジェクトストレージには従来のRDBMSのようなクエリエンジンが標準搭載されていないため、蓄積データの検索・集計には別途SQLエンジン（HiveやPresto、Spark SQLなど）を用いる必要があり、DWHに比べてインタラクティブなデータ探索性に劣ります。また誰でも生データを放り込める自由度の高さゆえに、適切なメタデータ管理や整理を怠るとデータの沼 (Data Swamp) と化し、必要なデータを探し出せなくなるリスクがあります。さらに決定的だったのはトランザクション処理やデータ品質管理の欠如です。通常のデータレイクにはACIDトランザクション（一貫した書き込み・更新処理）の仕組みがなく、データの更新や複数ユーザからの同時アクセスに対する整合性保証が困難でした。データ品質やガバナンスの仕組みも不十分で、蓄積データの信頼性を維持するためには個別にデータクレンジングや検証を行う必要がありました。このため、多くの企業ではデータレイクと既存DWHを併用し、まずデータレイクに原データを集めてから必要な部分のみをDWHにロード・加工してBI分析に使うという二段構えのアーキテクチャを採ってきました。しかしこの方法では、同じデータが複数システムに複製されることで管理コストが増大し、リアルタイム性も損なわれるというジレンマがありました。
クラウドデータウェアハウスへの移行
2010年代に入ると企業ITのクラウドシフトが加速し、データ基盤もオンプレミスからクラウドへの移行が本格化します。データウェアハウス分野でも、従来のオンプレDWHが抱えていたコスト高・運用負荷・拡張性の課題を解決すべく、各クラウドベンダーがDWH機能をサービス化しました。代表例として2013年にAWSが提供開始したAmazon Redshiftや、GoogleのサーバーレスDWHであるBigQuery（2011年正式リリース）、さらにはクラウド専業DWHのSnowflake（2014年創業）などが挙げられます。これらクラウドデータウェアハウスは、基盤構築やハードウェア調達を不要にし、利用した分だけ課金されるモデルで従来より導入障壁が低くなりました。またストレージとコンピュートの分離アーキテクチャを採用し、データ容量の拡張やクエリ性能向上のためにリソースをオンデマンドでスケールアウト/アップできる点も画期的でした。例えばSnowflakeは独自のアーキテクチャでストレージと計算クラスターを完全分離し、複数ユーザが同一データに対して独立した計算リソースで並行クエリを実行できるようにしています。またBigQueryはGoogleのDremel技術に基づき、SQLクエリを大規模分散処理することでサーバーレスかつ高並列な分析を可能にしました。こうしたクラウドDWHの登場により、ペタバイト級のビッグデータであっても従来ほどコストをかけずスケーラブルに分析でき、中小規模の企業やプロジェクトでも本格的なDWHを構築しやすくなりました。
クラウドDWHはデータ基盤のモダン化を一気に推し進めました。従来は専門のDB管理者がチューニングしながら運用していたDWHが、クラウドではマネージドサービスとして提供され自動でパフォーマンス最適化や障害対処が行われます。これによりデータ基盤担当者はインフラ運用よりもデータ活用そのものに注力できるようになります。また、クラウド上には豊富な周辺ツール群（データ統合のためのETL/ELTサービス、変換ワークフローをコード管理するdbt、可視化BIツール等）が育ち、いわゆるモダンデータスタックと呼ばれるエコシステムが形成されました。モダンデータスタックでは、データの収集・蓄積から分析・機械学習までをクラウドサービス上でシームレスに連携させることができます。例えば、様々なSaaSやデータベースからのデータをパイプラインツールでクラウドDWHに集約し、SQLベースで統合分析したり、さらにその結果を機械学習モデルに渡して予測分析に活かすといった流れが、数多くのクラウドネイティブツールによって支えられています。このようにクラウドDWHへの移行は、単なるインフラ環境の変化に留まらず、企業のデータ活用スタイルそのものを大きく変革しました。
データレイクハウス：次世代のデータ基盤
データウェアハウスとデータレイクはそれぞれ長所と短所があり、近年まで企業は両者を併用する2層アーキテクチャを採らざるを得ませんでした。しかしその結果、システム複雑性の増大やデータの重複管理といった問題が生じていたため、これらを解決する新しいアーキテクチャとして注目されているのがデータレイクハウス (Data Lakehouse) です。レイクハウスは文字通りデータレイクとデータウェアハウスの統合体であり、両者の利点を取り入れつつ欠点を補完しあうことを狙った次世代のデータプラットフォームです。
レイクハウスを実現する中心技術の一つが、オープンソースのテーブル形式ストレージの登場です。中でも2016年にDatabricks社によって開発されたDelta Lakeはその代表例で、Apache Parquet形式のデータファイルと堅牢なトランザクションメタデータログを組み合わせたオープンなデータストレージフォーマットですibm.com。Delta Lakeはデータレイクに不足していたACIDトランザクションやデータのバージョン管理といった高度なデータ管理機能を提供し、この技術革新がデータレイクハウス実現への重要な一歩となりましたibm.com。具体的には、既存のデータレイク（例：クラウド上のオブジェクトストレージ）の上にトランザクションログ付きのメタデータ層を重ねることで、複数ユーザからの同時アクセスでもデータの整合性を保ちつつ更新が可能になりますibm.com。さらにスキーマ（データ構造）の適用ルールを設けてデータ品質を保証し、過去のデータ状態に遡って参照できるタイムトラベル機能や、変更履歴の追跡・ロールバックによる信頼性向上も実現していますibm.com。Delta Lakeと同様のオープンテーブル形式には、Apache IcebergやApache Hudiなどがあり、いずれもデータレイク上でテーブルデータを扱うためのACIDトランザクション機能を提供するものですibm.com。これらの技術により、従来は難しかった「データレイク上の直接クエリ」が現実的となり、レイクハウスは安価で信頼性の高いストレージ基盤にデータウェアハウス並みの管理機構と性能を融合したアーキテクチャとして注目されています。
レイクハウスの特徴をもう少し具体的に見てみましょう。まずデータ形式とコストの点では、レイクハウスは基本的にオープンなファイルフォーマット（ParquetやORCなど）と汎用的なオブジェクトストレージを用いるため、従来のDWHのように高価な専用ストレージやプロプライエタリ形式に縛られることがありません。このため、ストレージコストを大幅に抑えつつ必要に応じてペタバイト級まで容量を拡張できます。またデータタイプの対応範囲も広く、構造化データだけでなくテキストや画像など非構造データまで単一のプラットフォームに保管し、一貫したセキュリティポリシーの下で扱うことができます。次に性能面では、データレイク上のファイルに対してDWH的なインデックスやデータスキッピングといった最適化を施すことで、大量データに対しても高速なクエリ応答を実現します。加えて前述のトランザクション対応により、同時実行制御や更新時の一貫性保持が可能となり、DWHで提供されていた信頼性をデータレイク上で再現しています。言い換えれば、レイクハウスは**「データレイクにデータを置きながら、DWHで培われた技術でその弱点を補う」**というアプローチで、両者の良いとこ取りをしているのです。
このようなレイクハウス基盤により、企業は単一のデータプラットフォーム上で幅広いデータ活用ニーズに応えられるようになります。従来はデータレイクの原データを分析用途に使うにはDWHへ移し替える必要がありましたが、レイクハウスでは生データに対して直接SQLや分析処理を実行できるため、中間の複製やバッチ処理を省略できます。結果として、BI用ダッシュボードの作成からデータサイエンス・機械学習モデルの訓練まで、全て同じデータストア上で行えるようになりますibm.com。例えばDelta Lake上のテーブルデータは、エンドユーザ向けには従来通りBIツールやSQLクエリで参照可能でありながら、データサイエンティストにとってはPythonやRから直接アクセスして高度な分析を行うこともできますibm.com。レイクハウスはリアルタイム処理にも対応し始めており、ストリーミングデータを取り込みつつ常に最新データで分析・モデル更新を行うようなユースケースにも適した基盤となりつつあります。総じてレイクハウスは、クラウドDWHとデータレイクの長所を高度に統合した現代のモダンデータプラットフォームと言えるでしょう。
データガバナンスの重要性
データ活用基盤が企業全体に広がりその規模・複雑さが増す中で、データガバナンス（データ統制管理）の重要性も飛躍的に高まっています。データガバナンスとは、企業内のデータ品質・セキュリティ・利用ルール・権限・責任範囲などを定め、データの一貫性と信頼性を維持しながら有効活用するための枠組みを指しますcreativehope.co.jp。現代はあらゆる業務領域でデータが生成・活用される「データ時代」となっており、企業が保有するデータ量は爆発的に増大、形式も多様化しています。そのため、データの整合性を保ちつつプライバシーやセキュリティリスクにも対処するデータガバナンスは、企業競争力を支える上で今や不可欠の取り組みといえますcreativehope.co.jp。特に個人情報保護や各種規制（GDPRなど）の遵守が求められる昨今、適切なガバナンスなく膨大なデータを蓄積することは法的・倫理的リスクにつながります。また部門ごとに異なる定義や粒度でデータを管理していては、全社横断のデータ分析で齟齬が生じ意思決定を誤る恐れもあります。こうした背景から、組織横断でデータの定義やライフサイクル管理を統一するマスタデータ管理(MDM)やデータカタログの整備、アクセス権限の厳密なコントロール、データ系システムの変更管理プロセスの導入など、包括的なデータガバナンス体制の構築が求められています。
モダンなデータ基盤においても、ガバナンスは重要な設計要件です。従来型のDWHは厳密なスキーマ管理下で中央集権的に運用されていたためガバナンスを効かせやすい側面がありました。一方、データレイクのようなオープンな基盤ではガバナンスが効きにくいという課題があり、レイクハウスが登場した大きな動機の一つもまさに「データレイクのガバナンス強化」でした。レイクハウスではメタデータ層によりスキーマ遵守を強制し、データ変更を記録・追跡できるため、監査証跡の確保やデータ品質担保に役立ちますibm.com。さらに最新のレイクハウス製品やクラウドDWH製品は、きめ細かなアクセス制御（テーブルだけでなく行レベル・列レベルでの閲覧権限設定）や、データマスキング・機密データ検出機能などガバナンス機能を充実させています。例えばDatabricks社はUnity Catalogというデータカタログ/ガバナンス機能を提供し、テーブルのメタデータ一元管理やアクセス制御を簡素化しています。またApache RangerやApache Atlasといったオープンソースのガバナンステクノロジーも登場し、データプラットフォーム横断でのセキュリティポリシー適用やデータ系資産の管理が可能になってきました。組織としては、単に技術を導入するだけでなくデータガバナンスの体制面の整備も欠かせません。データオーナーやスチュワードの任命、データ品質基準や利用ルールの策定、定期的なモニタリングと教育など、プロセス・人材・文化の側面で支えることで、初めてガバナンスが機能します。データ活用が高度化するほどガバナンスとの両立は難しくなりますが、信頼できるデータなしには高度な分析もAI活用も成り立たないため、今後ますます重要度を増す分野と言えるでしょう。
AI活用時代に向けたデータ基盤
近年のもう一つの大きな潮流は、AI（人工知能）技術の活用です。機械学習や深層学習を用いた高度な分析手法が実務に取り入れられ、データプラットフォームにも新たな要件が求められるようになりました。従来のBI分析が主に過去のデータから「何が起こったか」を可視化・報告するものであったのに対し、AI活用では大量の過去データからパターンを学習し将来を予測・意思決定を自動化するといった予測的・処方的分析が重視されます。このため、データ基盤には大量かつ多様な生データを長期間保持し、高速に読み書きできることが必要不可欠です。前述のデータレイクハウスはまさにそのニーズに応えるもので、画像・テキスト・時系列センサーデータなどを含むあらゆる形式のデータを一元管理し、そこから直接機械学習モデルのトレーニングデータを抽出することが可能ですibm.com。例えば、自動車のIoTセンサーデータやユーザー行動ログをレイクハウスに蓄積しておき、SparkやTensorFlowを使って直接そのデータを読み込みながらモデル開発を行うといったワークフローが実現できます。データが最初から統合環境に揃っているため、特徴量エンジニアリングから学習・評価までのサイクルを迅速に回すことができ、AI開発のスピードと精度向上に寄与します。
またAI時代には、分析のリアルタイム性も重要になっています。ストリーミングデータを即座に分析して需要予測を更新したり、オンライン学習でモデルを逐次改善したりするケースでは、従来のバッチ指向DWHでは対応が難しい場合があります。そこで、KafkaやSpark Structured Streamingなどを用いてデータ基盤にリアルタイムパイプラインを組み込み、常に最新データを取り込みつつ分析・予測するアーキテクチャが普及しつつあります。クラウドDWH各社もストリーミング取り込み機能や低レイテンシーのクエリ実行をサポートするよう進化しています。例えばGoogle BigQueryではストリーミング挿入APIにより秒単位でデータを取り込み、数秒遅れでクエリ可能にする仕組みを持っています。SnowflakeもSnowpipeという継続データロード機能や、近年ではストリーミング処理向けのSnowpark APIを発表し、リアルタイム分析や機械学習ワークロードへの対応を強化しています。レイクハウス系でもDelta Lakeがストリーミング対応のテーブル（テーブルの変更を継続的に取り込むDelta Live Tablesなど）を提供し、バッチとリアルタイムの垣根を無くす方向に進化しています。
さらに、2020年代には生成AI（Generative AI）の登場により、企業のAI活用は新たな段階に入りました。チャットGPTのような大規模言語モデル(LLM)をビジネスに応用するには、これまで以上に巨大で多様なデータセットが必要になります。同時に、モデルへの入力データや生成された出力に対する説明責任（なぜその結果になったかを説明できること）やバイアス排除も重視されるようになり、データ基盤には高度な透明性と品質管理が要求されています。実際、高品質なデータの用意なしに生成AIを活用することは困難であり、AIプロジェクトの成否はデータガバナンスの如何にかかっているとも言われますibm.com。このため、多くの組織が自社のデータ戦略とAI戦略を一体的に見直し、データ基盤の強化（レイクハウスへの移行やメタデータ管理の徹底など）とAI活用のルール策定を並行して進めています。
最後に、AI活用時代におけるデータ基盤人材・組織の変化にも触れておきます。従来はBI専門部署やIT部門の一部が担っていたデータ基盤管理ですが、現在ではデータエンジニアや機械学習エンジニアといった専門職種が登場し、データパイプラインの開発からモデル運用までを支える体制が構築されています。組織によってはデータ分析基盤チームとは別にMLOpsチームを設け、モデルとデータの継続的な管理に取り組むケースもあります。これらのチーム横断でデータガバナンスを維持しつつイノベーションを加速するには、「データ民主化」（社内の必要な人が必要なデータにアクセスできる状態）の推進と、それを安全に行うためのガバナンスとの両立が鍵となります。レイクハウスやクラウドDWHといったモダンな基盤はその技術的土台を提供しますが、最終的にそれらを活かすも殺すも企業文化と人次第です。AIを含むデータ駆動型組織への変革には、最新技術の導入だけでなく、人材育成や組織的なデータリテラシー向上も含めた包括的な取り組みが必要といえるでしょう。
まとめ
黎明期から現在に至るまで、データ活用の基盤技術とアーキテクチャは劇的な進化を遂げてきました。まずは各業務アプリケーションごとに閉じていたデータを統合しビジネス意思決定に役立てるために、データウェアハウスという概念が誕生しました。DWHは企業の単一の真実の源として機能し、組織横断の分析を可能にしましたが、構造化データ中心で柔軟性に欠けるという限界も抱えていました。その後、ウェブやセンサから生まれる非構造データの洪水に対応すべくデータレイクが導入され、安価にビッグデータを蓄積・活用できるようになりました。しかしデータレイク単独では信頼性や効率性の課題が残り、クラウド時代にはDWHと組み合わせたハイブリッド運用が定着しました。こうした二重構造の複雑さを解消するために登場したのがレイクハウスであり、これはオープンフォーマット上にDWH級の機能を実装した次世代型データ基盤として注目されています。現在ではクラウドDWHやレイクハウスを中心に、データガバナンスやAI活用まで見据えた包括的なデータ基盤構築がトレンドとなっています。
本稿で述べたように、各時代の技術的制約やビジネスニーズが次の時代のプラットフォームを生み出してきました。データ量・データ種が限られた時代には統合と高速クエリが価値を生み、データが多様化すると柔軟な格納と分散処理が要求され、さらに現代では統合と柔軟性の両立が図られています。今後もAIのさらなる進化やIoTの拡大により、「すべてのデータをリアルタイムに意思決定に活かす」需要は一層高まっていくでしょう。そうした未来に備えるためにも、エンジニアやデータ基盤担当者は過去から現在への技術の変遷を正しく理解し、自社のデータ戦略に最適なアーキテクチャを選択・組み合わせることが重要です。データ活用基盤の歴史を俯瞰することで得られる知見を武器に、これからのモダンデータスタックをより良いものへと発展させていきましょう。