「ビッグデータや機械学習のために、社内のあらゆるデータを一元的に蓄積したい」「データウェアハウス（DWH）とデータレイク、名前は聞くけれど違いがよく分からない」——データ活用基盤の整備に取り組むなかで、こうした悩みを持つ方が増えています。
AI・機械学習の活用やリアルタイム分析への需要が高まるにつれ、構造化データだけでなく、ログやセンサーデータ、画像・文書といった多様なデータをまとめて扱える基盤が求められるようになりました。その中心的な選択肢のひとつが「データレイク」です。ただ、DWHとの違いや、自社でどう構築すればいいのか、リアルタイムにデータをどう届けるのか、という実践面でつまずくケースは少なくありません。
本記事では、データレイクの基本的な概念から、DWHとの使い分け、クラウド別の構築パターン、そしてCDCを使ったリアルタイムデータ連携の実現方法までを、順を追って整理して解説します。
この記事で分かること
- データレイクとは何か（DWHとの技術的な違い）
- DWHとデータレイクの使い分けと、両者を組み合わせるアーキテクチャ
- クラウド別のデータレイク構築パターンと、CDCによるリアルタイム連携の実現方法
1. データレイクとは
データレイクとは、あらゆる種類のデータを、加工せずに生の形式のまま大量に蓄積できるリポジトリ（保管庫）です。「レイク（湖）」という名前のとおり、さまざまな源流から流れ込んだデータを、そのままの姿で溜めておくイメージです。
データレイクで扱えるデータ形式
データレイクの最大の特徴は、扱えるデータ形式の幅広さです。次の3種類のデータを、いずれもそのまま格納できます。
- 構造化データ：リレーショナルデータベースのテーブルのように、行と列で整理されたデータ。売上明細、顧客マスタなど。
- 半構造化データ：JSON、XML、CSV、ログファイルなど、一定の構造は持つが厳密なスキーマに縛られないデータ。
- 非構造化データ：画像、音声、動画、PDF、メール本文など、決まった構造を持たないデータ。
従来のデータベースでは扱いにくかった半構造化・非構造化データも含めて、いったんすべて蓄積しておける点が、AI・機械学習のデータソースとしてデータレイクが注目される理由です。
スキーマオンリード vs スキーマオンライト
データレイクとDWHの最も本質的な違いは、「いつスキーマ（データの構造定義）を決めるか」にあります。
DWHは「スキーマオンライト」。データを書き込む（蓄積する）時点で、あらかじめ決めたスキーマに沿って整形してから格納します。入り口できれいに整えるぶん、分析時のクエリは速く、データの品質も安定します。一方で、事前にスキーマ設計が必要なため、想定外の使い方には柔軟に対応しにくい面があります。
データレイクは「スキーマオンリード」。データを蓄積する時点ではスキーマを決めず、生のまま格納しておき、読み出して分析する時点で初めて構造を解釈します。あらゆるデータをそのまま蓄積できるため柔軟性が高く、後から新しい分析ニーズが出てきても対応しやすいのが強みです。反面、読み出し時に整形処理が必要になり、データの品質管理を怠ると“沼”になりやすい、という注意点もあります。
この「入り口で整えるDWH」と「出口で解釈するデータレイク」という違いが、両者の使い分けの出発点になります。
2. DWH vs データレイク：使い分けの考え方
DWHとデータレイクは、どちらが優れているという関係ではなく、目的に応じて使い分ける（あるいは組み合わせる）ものです。主な違いを整理します。
| 観点 | DWH（データウェアハウス） | データレイク |
| 主な目的 | 定型的なレポート・BI分析 | データ探索・AI/ML・多様な分析 |
| 対象データ | 構造化データ中心（整形済み） | 構造化・半構造化・非構造化（生データ） |
| スキーマ | スキーマオンライト（書き込み時） | スキーマオンリード（読み出し時） |
| コスト | 比較的高い（専用ストレージ・処理） | 比較的低い（安価なオブジェクトストレージ） |
| クエリ性能 | 高速（整形済みで最適化） | 形式・処理により変動 |
| 向いている用途 | 経営ダッシュボード・定型帳票 | 機械学習・ログ分析・データ探索 |
DWHとデータレイクを組み合わせるアーキテクチャ
実務では、DWHとデータレイクのどちらか一方だけを使うより、両者を組み合わせる構成が一般的です。典型的なのは、まずデータレイクにあらゆる生データを蓄積し、そのうち定型分析・BIに使うデータを整形してDWHに連携する、という二段構えです。生データはデータレイクに保持したまま、機械学習やデータ探索にも活用できます。
クラウドDWHへのデータ連携の考え方については、別記事「DWH構築のためのデータ連携｜Redshift/Snowflake/BigQueryへのリアルタイム連携」で詳しく解説しています。あわせてご覧ください。
データレイクハウスという新しい潮流
ただし、この二段構えには課題もあります。データレイクとDWHの二重管理によるコスト増や、連携処理の分だけデータ反映が遅れることなどです。そこで近年登場したのが、両者を組み合わせるのではなく、ひとつの基盤に統合してしまおうという「データレイクハウス」というアーキテクチャです。安価なオブジェクトストレージ上に生データを置くデータレイクの柔軟性を保ちながら、DWHのようなデータ管理機能（トランザクション、スキーマ管理、高速クエリ）を実現しようというものです。
これを支えているのが、Delta LakeやApache Icebergといったオープンなテーブルフォーマットです。オブジェクトストレージ上のファイルに、テーブルとしての構造・更新履歴・スキーマ進化の仕組みを与えることで、データレイクの上でDWHに近い分析ができるようになります。とりわけApache Icebergは、多くのクエリエンジンから同じデータを扱える標準的なフォーマットとして、急速に採用が広がっています。
3. データレイクの構築パターン（クラウド別）
データレイクは、安価で拡張性の高いクラウドのオブジェクトストレージを中核に構築するのが一般的です。主要3クラウドそれぞれの代表的な構成を見ていきます。
AWS：Amazon S3 + AWS Glue + Athena
AWSでは、オブジェクトストレージのAmazon S3をデータレイクの基盤とし、データカタログ・ETLにAWS Glue、S3上のデータへ直接SQLクエリを実行するAmazon Athenaを組み合わせる構成が定番です。Glueがデータの場所やスキーマをカタログとして管理し、Athenaがサーバーレスで分析クエリを担います。AWSエコシステムとの統合性が高く、Redshiftとの連携もしやすいのが特徴です。
Azure：Azure Data Lake Storage Gen2 + Azure Data Factory
Azureでは、データレイク向けに最適化されたAzure Data Lake Storage Gen2（ADLS Gen2）を基盤に、データ統合・ETLをAzure Data Factoryが担う構成が代表的です。Azure SynapseやMicrosoft Fabricと組み合わせることで、蓄積から分析までをAzure内で完結できます。Microsoft製品群を利用している企業との親和性が高い構成です。
Google Cloud：Google Cloud Storage + Dataflow + BigQuery
Google Cloudでは、オブジェクトストレージのGoogle Cloud Storage（GCS）を基盤に、ストリーム／バッチ処理のDataflow、分析基盤のBigQueryを組み合わせます。BigQueryはGCS上の外部データにも直接クエリでき、データレイクとDWHの境界がなめらかなのが特徴です。大規模データの高速分析に強みがあります。
各クラウドの選定ポイント
どのクラウドを選ぶかは、すでに利用しているクラウド基盤に合わせるのが基本です。AWS中心ならS3ベース、Microsoft製品中心ならADLS Gen2、Google Cloud中心ならGCSと、既存環境との親和性でまず絞り込みます。そのうえで、扱うデータ量、分析ワークロードの特性、既存のスキルセットを踏まえて、周辺サービスの構成を検討します。いずれのクラウドでも、後述するApache Icebergのようなオープンフォーマットを採用しておくと、特定クラウドへのロックインを避けやすくなります。
4. CDCによるリアルタイムデータ連携の実現
データレイクを構築したら、次の課題は「どうやってソースのデータをデータレイクに届け続けるか」です。ここで連携方式が、データの鮮度を大きく左右します。
バッチ処理でのデータレイク更新の限界
従来、データレイクへのデータ投入は夜間バッチで行うのが一般的でした。しかし、AI・リアルタイム分析の需要が高まるなかで、バッチ処理の限界が見えてきています。夜間にまとめて取り込む方式では、日中に発生したデータが分析に反映されるのは翌日以降になり、データの鮮度が保てません。また、大量データの一括抽出は本番DBに負荷をかけ、処理時間も長くなりがちです。「今この瞬間の状況を分析したい」というニーズには、バッチでは応えられないのです。
CDCを使ったリアルタイム連携アーキテクチャ
この課題を解決するのが、CDC（Change Data Capture）です。CDCは、データベースのトランザクションログを読み取り、発生した変更（追加・更新・削除）だけをリアルタイムに検知して連携する技術です。全データを毎回抽出するバッチと違い、変更分のみを継続的に届けるため、本番DBへの負荷を最小限に抑えながら、データレイクを常に最新の状態に保てます。
CDCの仕組みや方式の詳細については、別記事「CDC（Change Data Capture）とは？DB移行・クラウド移行でダウンタイムを最小化する技術」で詳しく解説しています。
出力形式の選択：データレイクに最適なフォーマット
データレイクへ連携する際は、出力するファイル形式の選択も重要です。CSVやJSONは扱いやすく汎用的ですが、大規模分析ではParquetのような列指向（カラムナ）フォーマットが有利です。Parquetは、必要な列だけを効率的に読み出せるため、分析クエリが高速になり、高い圧縮率を実現しストレージコストを抑えられます。SparkやHiveといった分析エンジンとの相性もよく、データレイクの分析用フォーマットとして広く使われています。
5. Qlik Replicateによるデータレイクへのリアルタイム連携
インサイトテクノロジーが日本での導入を支援している「Qlik Replicate」は、CDCによるリアルタイムデータ連携を実現するソリューションです。データレイクへの連携において、次のような強みがあります。
主要クラウドのデータレイクに幅広く対応
Qlik Replicateは、Amazon S3、Azure Data Lake Storage、Google Cloud Storageといった主要クラウドのオブジェクトストレージに対応しています。エージェントレス設計で本番DBへの影響が小さく、Oracle・SQL Server・PostgreSQL・MySQLなど多様なソースから、これらのデータレイクへCDCでリアルタイムに連携できます。
Parquet/ORC形式での出力に対応
前章で触れたとおり、データレイクではファイル形式が分析性能を左右します。Qlik ReplicateはParquetやORCといった列指向フォーマットでの出力に対応しており、SparkやHiveなどの分析エンジンとの連携がスムーズです。連携と同時に分析最適なフォーマットで書き出せるため、後段の変換処理を減らせます。
Qlik Compose for Data Lakesとの組み合わせによるデータレイク運用の自動化
Qlik Replicateがソースからデータレイクへ「データを届ける」役割を担う一方で、届いたデータをデータレイク内で「使える状態に保つ」ための運用課題は残ります。第1章で触れたとおり、データレイクは何でも蓄積できる柔軟性がある反面、取り込んだデータをすべて管理しきれず、どこに何があるか分からない“沼”になりやすいという弱点があるためです。
この課題に対応するのが、同じQlikデータ統合ファミリーの「Qlik Compose for Data Lakes」です。取り込んだ各データのメタデータを自動的に収集してカタログ化し、必要なときに最適なデータを取り出せる状態を維持します。加えて、テーブル作成やソースとターゲットのマッピング、スキーマの同期といった作業を自動化し、SparkやHiveを利用したデータのロードもコーディングなしで実行できます。リアルタイム参照用のODS（オペレーショナルデータストア）と、変更履歴をすべて追跡するHDS（ヒストリカルデータストア）を継続的に自動生成・管理できる点も特徴です。
つまり、Qlik Replicateで「本番DBに負荷をかけずリアルタイムにデータを集め」、Qlik Compose for Data Lakesで「集めたデータを管理された状態に保ちながら分析可能な形に整える」という役割分担になります。この2つを組み合わせることで、データレイクの構築から運用までの一連のプロセスを自動化し、導入から成果を生み出すまでの時間を短縮できます。
Qlikデータ統合の製品ラインナップや各製品の詳細については、Qlikデータ統合の製品ページもあわせてご覧ください。
まとめ
- データレイクは、構造化・半構造化・非構造化データを生の形式のまま蓄積するリポジトリ。AI・機械学習のデータソースとして注目されている
- DWHは「スキーマオンライト（入り口で整形）」、データレイクは「スキーマオンリード（出口で解釈）」という違いがあり、目的で使い分ける
- 両者を組み合わせる構成が一般的。近年はDelta LakeやApache Icebergを使った「データレイクハウス」が新潮流
- 構築はAWS（S3）、Azure（ADLS Gen2）、GCP（GCS）を中核に。既存のクラウド基盤との親和性で選ぶのが基本
- バッチ更新ではデータ鮮度に限界。CDCでリアルタイムに変更を連携し、Parquet等の分析最適フォーマットで蓄積するのが有効
- Qlik Replicateは主要クラウドのデータレイクに幅広く対応し、Parquet/ORC形式での出力も可能。Qlik Compose for Data Lakesと組み合わせれば、データの収集から管理・整備までを自動化できる
データ連携基盤の構築をご検討の方へ
「自社のデータレイクをどう構築すればいいか」「バッチ連携をリアルタイム化したい」「データレイクハウスを検討している」——インサイトテクノロジーでは、Qlik Replicateの提供と技術サポートを通じて、データレイク／データレイクハウスへのリアルタイムデータ連携を一貫してご支援しています。構想・アセスメントの段階からお気軽にご相談ください。
▼ Qlik Replicateの資料をダウンロード
https://www.insight-tec.com/download/document_0006
▼ Qlik Compose for Data Lakesの資料をダウンロード
https://www.insight-tec.com/download/document_0007
▼ Qlikが実現できるデータ連携について詳しく見る
https://www.insight-tec.com/products/qlik-data-integration-platform
▼ データ連携の悩みをまず相談する
https://www.insight-tec.com/products/qlik-data-integration-platform/#f
