Upgrade to Pro — share decks privately, control downloads, hide ads and more …

レイクハウスとはなんだったのか?

 レイクハウスとはなんだったのか?

赤煉瓦倉庫勉強会第2回「レイクハウスって結局何なのっていいました?じゃあ真のレイクハウスをみせてやりますよ!」
での発表資料です!

Akihiro Kuwano

January 27, 2025
Tweet

More Decks by Akihiro Kuwano

Other Decks in Technology

Transcript

  1. ©2024 Databricks Inc. — All rights reserved レイクハウス とはなんだったの か?

    クラウドストレージとデータ分析基盤 の良い関係 Akihiro Kuwano
  2. ©2024 Databricks Inc. — All rights reserved 今日のアジェンダ ▪ 結局レイクハウスってなんなの?

    ▪ なぜ ”みんなが” レイクハウスっていい出したんだろう? ▪ レイクハウスって全部同じ? ▪ そしてOTF 〜クラウドストレージとデータ基盤の良い関係〜 ▪ レイクハウスの実現すること ▪ まとめ
  3. ©2024 Databricks Inc. — All rights reserved 結局レイクハウスってなんなの? レイクハウス最 近聞くけどよく

    わからん Delta Lake? Iceberg?Hudi? 何が違うの? どれがいいの? 各社レイクハウ スっていってるけ ど違いはあるの? 真のレイクハウ スってなにw レイクハウスは 何がいいの?
  4. ©2024 Databricks Inc. — All rights reserved 結局レイクハウスってなんなの? レイクハウス最 近聞くけどよく

    わからん Delta Lake? Iceberg?Hudi? 何が違うの? どれがいいの? 各社レイクハウ スっていってるけ ど違いはあるの? 真のレイクハウ スってなにw レイクハウスは 何がいいの? 今日はこれらに (ゆるく) お答えしていきましょう
  5. ©2024 Databricks Inc. — All rights reserved レイクハウスの基本概念 レイクハウスとは端的に言うと以下の様なものであると言える ▪

    データウェアハウスとデータレイクの利点を組み合わせたデータ管理アーキ テクチャ ▪ Apache Parquetなどのオープンなファイル形式を基盤とし、ACIDトランザク ション、バージョニング、インデックスなどを提供 ▪ BI分析からAI/MLまで、複数ワークロードを単一のプラットフォームで効率的 に処理可能 ▪ 複雑なETLは不要、データの鮮度を保ちコストを削減可能 ▪ 直接アクセス可能、オープンな形式を採用し、ベンダーロックインを極小化、 柔軟なデータ活用を実現
  6. ©2024 Databricks Inc. — All rights reserved レイクハウスの基本概念 レイクハウスとは端的に言うと以下の様なものであると言える ▪

    データウェアハウスとデータレイクの利点を組み合わせたデータ管理アーキ テクチャ ▪ Apache Parquetなどのオープンなファイル形式を基盤とし、ACIDトランザク ション、バージョニング、インデックスなどを提供 ▪ BI分析からAI/MLまで、複数ワークロードを単一のプラットフォームで効率的 に処理可能 ▪ 複雑なETLは不要、データの鮮度を保ちコストを削減可能 ▪ 直接アクセス可能、オープンな形式を採用し、ベンダーロックインを極小化、 柔軟なデータ活用を実現 なるほどわからん?
  7. ©2024 Databricks Inc. — All rights reserved レイクハウスの基本概念 レイクハウスとは端的に言うと以下の様なものであると言える ▪

    データウェアハウスとデータレイクの利点を組み合わせたデータ管理アーキ テクチャ ▪ Apache Parquetなどのオープンなファイル形式を基盤とし、ACIDトランザク ション、バージョニング、インデックスなどを提供 ▪ BI分析からAI/MLまで、複数ワークロードを単一のプラットフォームで効率的 に処理可能 ▪ 複雑なETLは不要、データの鮮度を保ちコストを削減可能 ▪ 直接アクセス可能、オープンな形式を採用し、ベンダーロックインを極小化、 柔軟なデータ活用を実現 じゃあ詳しく 説明していきます
  8. ©2024 Databricks Inc. — All rights reserved データ基盤アーキテクチャの変遷 データ基盤のアーキテクチャは以下のような流れで今に至っています: ▪

    データウェアハウス ▪ データウェアハウス+データレイク ▪ レイクハウス 何故この様な流れを組むことになったのでしょうか?
  9. ©2024 Databricks Inc. — All rights reserved データウェアハウス 大量の分析データを扱うために生まれたのがデータ ウェアハウス

    ▪ データウェアハウスはデータベース等の構造化 データを取得してそこから分析を行うために生まれ た ▪ 通常のデータベースでは返せない量のデータを扱 えるような特別な構成のデータベースをデータウェ アハウスとして定義 ▪ 書き込み時にスキーマを決定するスキーマ・オン・ ライトが基本 ETL 構造化 データ データウェア ハウス BI/User
  10. ©2024 Databricks Inc. — All rights reserved データウェアハウスの利点 ▪ 大量データを扱うデータウェアハウスでは一例だが

    MPP (Massive Parallel Processing)や、列指向スト レージ等を採用 ▪ MPP ▪ 複数のノードで分散処理を行い、複数ノードで分散処理した 結果をPrimaryノードで集計することで大量のデータの処理 を実現 ▪ 列指向ストレージ ▪ ストレージを行ではなく、列で持つことで特定列に対して大 量のアクセスを行うDWHワークロードに最適化 ▪ オンプレミス、クラウドの各ストレージに連携 ▪ これらにより大量データのアクセスを高速に返すこ とが可能 ▪ BIなどからクエリを集計分析することができる Worker Worker Worker MPP Cluster Primary 行指向 列指向
  11. ©2024 Databricks Inc. — All rights reserved データウェアハウスの課題 ▪ コンピュートとストレージの非分離

    ▪ コンピュートとストレージが分離できておらず適切なス ケールがしづらい ▪ スケールがどちらかによってしまうために、不要なコスト が掛かってしまう ▪ 非構造化データの管理 ▪ 音声、画像、動画など非構造化データを扱う手段が限 られており、スキーマ定義が綺麗にできるものしか扱え なかった ▪ 機械学習などのワークロードは限定的、もしくは別シス テムとの連携 ▪ コスト ▪ 前述のコスト最適化の難しさ ▪ プロプライエタリなストレージ、コンピュートはコストが高 い、そもそもデータ量も多い用途なのでストレージ、コン ピュートのコストは高価 ETL 構造化 データ BI/User DWH ストレージ、コンピュー ト多い方でスケール する必要がある $$$ コスト 最適化の 難しさ 非構造化 データ
  12. ©2024 Databricks Inc. — All rights reserved データレイクの登場 これらの問題を解決するためにデータレイクが誕生: ▪

    低コストの統一されたストレージに構造化、非構造化 データ全てのデータを格納 ▪ ParquetやORCなどのオープンフォーマットでデータを保 持 ▪ 当初はHDFS等のストレージも使われていたが、以下の ようなメリットから段々とS3などのクラウドストレージへ ▪ 優れた耐久性(イレブン9) ▪ 低いコスト ▪ 各システムとの連携のしやすさ ▪ 様々な機能(リージョナルレプリケーション、様々なストレージティ アなどなど) Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ ETL DWH BI/User Data Science
  13. ©2024 Databricks Inc. — All rights reserved データレイクの利点 ▪ ストレージとコンピュートの分離

    ▪ 構造化、非構造化データどちらも扱う事が可能 ▪ 大量のデータでも問題なくスケーラブル ▪ クラウドサービスではサービス間連携が可能でDWHと もデータコピーし連携できる ▪ コストも従量課金で最適化可能 Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ ETL DWH BI/User Data Science ストレージと、コン ピュートが独自にス ケール可能 データをコピーして 必要なサービスを活 用 $
  14. ©2024 Databricks Inc. — All rights reserved データレイクの課題 ▪ データスワンプ問題

    ▪ ファイル管理が煩雑、ACIDトランザクションがなくデータ品質を正 しく保つのが難しい、データに重複や矛盾が発生しやすい ▪ パフォーマンスの問題 ▪ ブロックデバイスと比べるとオブジェクトストレージは APIアクセス であり、インデックス、キャッシュの不足などから大規模になるほ どオーバーヘッドがあった ▪ ガバナンスの課題 ▪ メタデータ管理や、バージョン管理を行う事ができず適切なデー タ管理ができない ▪ アクセス制御の粒度が粗い Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ ETL DWH BI/User Data Science データの管理に 課題 メタデータ管理やバージョ ン管理は限定的 速度面の課題
  15. ©2024 Databricks Inc. — All rights reserved データウェアハウス+データレイクの課題 DLとDWHを連携させた場合の問題点: ▪

    データの信頼性 ▪ データレイクとウェアハウスの一貫性 ▪ データの鮮度 ▪ データウェアハウスのデータはデータレイクから生成する必要が あり古くなりがち ▪ ワークロードの分離 ▪ MLやDSのワークロードはDWHでは限定的、つまりDLとDWHで データがサイロ化 ▪ ETL処理の複雑化(ソース>DL>DWH>DL>ML>...) ▪ コスト最適化 ▪ ETL時、そしてウェアハウスへコピーされた二重、三重のストレー ジコスト Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ ETL DWH BI/User Data Science DWHとDL 間のデータ 一貫性 DWHとDL間の データ一貫性 & データの鮮度 & データのサイロ化 DWHとDL間の データ一貫性 & データの鮮度 & データのサイロ化 DWHとDL間の データ一貫性 & データの鮮度 & データのサイロ化 DWHとDL間の データ一貫性 & データの鮮度 & データのサイロ化
  16. ©2024 Databricks Inc. — All rights reserved ブレイクスルーとしてのレイクハウス ▪ Databricksはこれらデータウェアハウスとデータ

    レイクについてこれまで出てきた課題を解決する ためにレイクハウスアーキテクチャというものを 定義した ▪ そしてDatabricksというプラットフォームはレイク ハウスアーキテクチャを実装したデータ分析基盤 として進化してきた
  17. ©2024 Databricks Inc. — All rights reserved そしてレイクハウスへ Machine Learning

    データレイク  (S3、ADLS、GCS) 構造化 データ ETL DWH BI/User Data Science Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ BI/User Data Science メタデータ & ガバナンスレイヤ コンピュートレイヤ ETL
  18. ©2024 Databricks Inc. — All rights reserved レイクハウスの利点 レイクハウスはデータレイクとデータウェアハウスの利点の組み合わせ: ▪

    DL上で従来の分析DBMSの管理機能、パフォーマンスを提供 ▪ ACIDトランザクション ▪ データのバージョニング ▪ 監査機能 ▪ インデックス作成 ▪ キャッシング ▪ クエリ最適化 ▪ 低コストで直接アクセス可能なストレージをベースにする ▪ Databricksではクラウドストレージをベースとしている
  19. ©2024 Databricks Inc. — All rights reserved レイクハウスの技術的要素 レイクハウスの設計についての主な3つの技術的要素: ▪

    メタデータレイヤー ▪ SQLパフォーマンスの最適化 ▪ 高度な分析のためのアクセス方法の提供
  20. ©2024 Databricks Inc. — All rights reserved メタデータレイヤー ▪ 低コストのオブジェクトストアに

    Parquetなどの標準フォーマットで データを保存 ▪ オブジェクトストア上にトランザクショ ナルなメタデータレイヤーを実装 ▪ Delta Lake、Apache Icebergなどのア プリケーション(Open Table Format)が そのために実装される Machine Learning データレイク  (S3、ADLS、GCS) BI/User Data Science メタデータ & ガバナンスレイヤ データレイク上の Parquetファイルに対 してトランザクションを 行うためのメタデータを 付与する コンピュートレイヤ ETL
  21. ©2024 Databricks Inc. — All rights reserved          コンピュートレイヤ SQLパフォーマンスの最適化 レイクハウスでは、SQLクエリのパフォーマンスの最適

    化が必要、データセットに対して高速なクエリ処理を行 う機構を持つ ▪ インデックス作成 ▪ データの検索速度を向上のため適切なインデックスを作 成、クエリ実行時間を短縮 ▪ パーティショニング ▪ データを論理的なパーティションに分割し、クエリの対象 範囲を限定、処理速度を向上させる ▪ 例えば、日付や地域に基づいてデータをパーティション化 など ▪ キャッシング ▪ 頻繁にアクセスされるデータをキャッシュし、 I/Oを減らす ことで、クエリの応答時間を短縮 データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ=OTF ETL キャッシュ インデックスで 必要なデータだけを 取得 パーティショニング でデータの取得量を 減らす 2023-02-05 2023-02-06 Customer A Customer B Customer C Machine Learning BI/User Data Science
  22. ©2024 Databricks Inc. — All rights reserved 高度な分析のためのアクセス方法の提供 レイクハウスは、高度な分析を行うためのプラット フォームとして利用を想定

    ▪ 機械学習などで直接アクセスするためのインター フェースとしてのDataframeAPIの用意 ▪ MLライブラリからParquetなどの読み取りサポー ト ▪ データの一貫性、品質等の管理機能の提供 ソースデータ (Parquetファイル) DataFrame Machine Learning Data Science Dataframeで必要 な処理を行いMLや DS、ETLの実行を行 う
  23. ©2024 Databricks Inc. — All rights reserved 要するにレイクハウスとは ▪ クラウドストレージを活用したデータレイク層を持

    つ ▪ データレイク層の上にメタデータとデータガバナ ンスを管理するアプリケーション層を持つ(これが OTF) ▪ データウェアハウスの機能、データサイエンスの 機能、機械学習の機能を同一インターフェースか ら利用可能 ▪ このストレージレイヤへアクセスするためのオー プンな方法を提供している Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ BI/User Data Science メタデータ & ガバナンスレイヤ=OTF コンピュートレイヤ ETL
  24. ©2024 Databricks Inc. — All rights reserved レイクハウスあるあるクイズその1 レイクハウスアーキテクチャは大容量データにフィットするアーキテクチャであ る?

    1. Yes 2. No 3. 場合による レイクハウスは大容量のデータに対して正しくスケールできるアーキテクチャに なっています! ただしデータ量が少ないから使えないというわけではないですよ!
  25. ©2024 Databricks Inc. — All rights reserved レイクハウスというアーキテクチャの妥当性 前の話を踏まえてざっとまとめてみるとこんなところ? ▪

    様々なワークロードへの対応 ▪ BI、AI、MLなど様々なワークロードに対応する必要がでてきた ▪ クラウドストレージの有効活用というアプローチが認められた ▪ ストレージとコンピュートの分離(パフォーマンス、コスト) ▪ スタートアップから大企業まで使いやすい ▪ エコシステムの充実
  26. ©2024 Databricks Inc. — All rights reserved コンピュートレイヤ 様々なワークロードへの対応 ▪

    DWHだけじゃなく、AI/機械学習ワーク ロードへの広範な対応 ▪ 扱うデータが増え、構造化データだけでな く、非構造化データや半構造化データも重 要に ▪ レイクハウスは、データレイクとデータウェ アハウスの両方の利点を活かし、多様な データを統合的に管理・分析できるため、 ニーズに適していた Machine Learning データレイク  (S3、ADLS、GCS) 構造化 データ BI/User Data Science メタデータ & ガバナンスレイヤ ETL BI/AI/ML等、 様々なユースケースを 実行可能
  27. ©2024 Databricks Inc. — All rights reserved コンピュートレイヤ ストレージとコンピュートの分離 ▪

    ストレージとコンピュートを分離することで個 別のスケールが可能になった ▪ これによりコストの最適化、スケールの最適 化が実現された ▪ 前述したが正確に言うとこれはデータレイク の特性となるが、それを更に汎化させている データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ=OTF ETL Machine Learning BI/User Data Science コンピュートレイヤ は必要な処理の数だけ スケール ストレージレイヤ は必要な容量や、I/Oだ けスケール
  28. ©2024 Databricks Inc. — All rights reserved スタートアップから大企業まで使いやすい ▪ 先程のクイズでもあったが、小規模のスタートアップ

    から、大規模のエンタープライズまで構成を変えずに スモールスタートが可能な点 ▪ レイクハウスアーキテクチャは必ずしも大規模じゃな いと使えないとかではなく、むしろ最初に選択するこ とで長くその構成を維持できる データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ データレイク メタデータ & ガバナンスレイヤ スケール
  29. ©2024 Databricks Inc. — All rights reserved エコシステムの充実 ▪ Delta

    Lake、IcebergといったOTFの充実 ▪ 各OTFに対応したプロダクトも順調に増えて おり、各クラウドベンダもそれに協調している ▪ Delta Lakeのエコシステムだけでも右の様な 数多くのプロダクトが存在している ▪ これらのエコシステムを必要に応じて使い分 けることができるのもレイクハウスアーキテク チャの良い点 データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ
  30. ©2024 Databricks Inc. — All rights reserved レイクハウスあるあるクイズその2 OTFとクラウドストレージを使っていれば全てレイクハウスアーキテクチャといえ る?

    1. Yes 2. No 3. 場合による OTFを使っていれば全てレイクハウスアーキテクチャではない 実際にはSSOTが保たれている、オープンなアクセスが実現できている、などレイ クハウスであるためには色々な考え方があります
  31. ©2024 Databricks Inc. — All rights reserved レイクハウスって全部同じ? レイクハウスってどうなってたらレイクハウスでしょうか? 大事なポイントを列挙

    ▪ オープンでロックインを避ける構成である事 ▪ 統一されたプラットフォームである事 ▪ 複数サービスの組み合わせではなく統一されたガバナンスが実現されている事 ▪ 複数プラットフォーム間でデータのコピーが発生しない事
  32. ©2024 Databricks Inc. — All rights reserved ロックイン? ▪ Delta

    LakeなどOTFへのアクセスは非常に オープンに管理されている ▪ オープンでなければそれは結局そのプロダク トにロックインされることになる ▪ 例えば、ストレージとコンピュートの分離はで きていて、SSOTも保たれているが、ストレー ジがそのプロダクト独自のプロプライエタリな ものであったりすればそこからの変更は難し くなる データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ 自社プロダクトA 他社プロダクトB これでは出ていくことが できないし、適材適所 なプロダクト選択もでき ない クローズド/プ ロプライエタリ なAPI クローズドな エンジン ガバナンス 認証機構
  33. ©2024 Databricks Inc. — All rights reserved ロックイン? ▪ Delta

    LakeなどOTFへのアクセスは非常に オープンに管理されている ▪ オープンでなければそれは結局そのプロダク トにロックインされることになる ▪ 例えば、ストレージとコンピュートの分離はで きていて、SSOTも保たれているが、ストレー ジがそのプロダクト独自のプロプライエタリな ものであったりすればそこからの変更は難し くなる データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ 自社プロダクトA 他社プロダクトB 必要なプロダクトも使 え、切り替えや併用す る事が可能 オープンなAPI オープンな エンジン オープンな 認証機構、 ガバナンス
  34. ©2024 Databricks Inc. — All rights reserved 統一されたプラットフォーム? ▪ 実際には複数のサービスを組み合わせて実現

    されているサービスもある ▪ それは実際には少しずつ運用負荷を生んだり、 ガバナンスの問題を生む ▪ レイクハウスで統一されたプラットフォームであ ることが大事 データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ DWH IAMなどの 認証・認可 プロダクト間や、OTFの ガバナンスレイヤで個 別のガバナンスが存在 する プロダクト間や、OTFの ガバナンスレイヤで個 別のガバナンスが存在 する プロダクト間や、OTFの ガバナンスレイヤで個 別のガバナンスが存在 する
  35. ©2024 Databricks Inc. — All rights reserved 統一されたプラットフォーム? ▪ 実際には複数のサービスを組み合わせて実現

    されているサービスもある ▪ それは実際には少しずつ運用負荷を生んだり、 ガバナンスの問題を生む ▪ レイクハウスで統一されたプラットフォームであ ることが大事 ▪ Databricksの場合はUnity Catalogがその役割 を果たしている データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ プロダクトA プロダクトB 統一された ガバナンスを提供
  36. ©2024 Databricks Inc. — All rights reserved サービス間のデータコピー? ▪ 先程の話にちょっと関わるが、この場合に複数

    サービスのデータコピーが発生する場合がある ▪ データウェアハウスにデータが有る、BIツール側 にデータがある、ETLサービス側にデータがあ る、など ▪ 前述した通り、データのコピーが存在することは データの信頼性や鮮度に関わる ▪ データがOTFにあればいいわけではなく、クラウ ドストレージに統一してデータを持つことでSSOT を実現することが重要 BI DWH ETL データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ データ データ データ 各プロダクトに コピーが存在する 各プロダクトに コピーが存在する 各プロダクトに コピーが存在
  37. ©2024 Databricks Inc. — All rights reserved サービス間のデータコピー? ▪ 先程の話にちょっと関わるが、この場合に複数

    サービスのデータコピーが発生する場合がある ▪ データウェアハウスにデータが有る、BIツール側 にデータがある、ETLサービス側にデータがあ る、など ▪ 前述した通り、データのコピーが存在することは データの信頼性や鮮度に関わる ▪ データがOTFにあればいいわけではなく、クラウ ドストレージに統一してデータを持つことでSSOT を実現することが重要 BI DWH ETL データレイク  (S3、ADLS、GCS) 構造化 データ メタデータ & ガバナンスレイヤ 各プロダクトに コピーは存在せず データレイク側に 統一して管理する
  38. ©2024 Databricks Inc. — All rights reserved OTF!OTF!OTF! OTF(Open Table

    Format)は、先程までのお話 でいうと、データレイク層の上にあるメタデータ やガバナンスを司るレイヤーを実現するための ソフトウェア シンプルに言うとクラウドストレージに付加価値 をつけるもので、メタデータ管理やバージョン管 理などを行う 3つのOTFで基本的に実現したい事に変わりは ありませんが、今回はDelta Lakeをベースに説 明
  39. ©2024 Databricks Inc. — All rights reserved OTFが実現するもの Delta Lakeで実現される機能群

    ▪ メタデータ管理 ▪ パフォーマンス最適化 ▪ トランザクション管理 ▪ オープンなインターフェース データレイク  (S3、ADLS、GCS) メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science OTFはこ こ
  40. ©2024 Databricks Inc. — All rights reserved メタデータ管理 ▪ Delta

    Lakeは、Delta Logというメタデータと データファイルを一緒にデータレイク上に 格納、スケーラブルなメタデータ管理を可 能としている ▪ Delta Logとはユーザーがテーブルに加え たすべての変更を順序付きで自動で記録 したログ ▪ これにより以下の事を実現する ▪ ACIDトランザクションの担保 ▪ テーブルのバージョン管理(スナップショット、タイ ムトラベル含) ▪ 同時実行制御 トランザクショ ンログ(Delta Log) (OPTION) パーティション ディレクトリ データファイル
  41. ©2024 Databricks Inc. — All rights reserved パフォーマンス最適化 ▪ Delta

    Lakeはクラウドストレージ内の データレイアウトを最適化しクエリパ フォーマンスを向上させる ▪ データサイズの偏り、サイズが適切で はないファイルが多く存在するとパ フォーマンスが低下 ▪ 様々なパフォーマンス改善機能 ▪ パーティション ▪ Z-Order ▪ リキッドクラスタリング ▪ Delta キャッシュ ▪ この辺見ていきましょう
  42. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F パーティショニング(Hive Style)
  43. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F パーティショニング(Hive Style) 小規模ファイルがで きる データサイズの偏り (Skew)の発生
  44. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F パーティショニング+Z-Order ファイルサイズは均 一となりデータサイ ズの偏りはなくなる 新規ファイルがすぐ適用 されず、新しく取り込ま れたデータはクラスタ化 されていない 動的にファイルをマージ できない
  45. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1: date Col 2: customer_id Liquid Clustering
  46. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Col 1: date Col 2: customer_id Liquid Clustering
  47. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Col 1: date Col 2: customer_id Liquid Clustering
  48. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Col 1 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 1: date Col 2: customer_id Liquid Clustering
  49. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Col 1 Col 2 Col 2 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering
  50. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering
  51. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering
  52. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F ターゲットファイルサイズに応 じて最適化します。 Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering
  53. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C ターゲットファイルサイズ Col 1: date Col 2: customer_id Liquid Clustering
  54. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering
  55. 2023-02-05 2023-02-06 2023-02-07 Customer A Customer B Customer C Customer

    D Customer E Customer F Col 1 Col 1 > 2023-02-06 Col 1 <= 2023-02-06 Leaf1 Col 1 Col 2 Col 2 Leaf6 Leaf7 Col 2 Col 2 Col 2 > C Col 2 <= C Col 2 > B Col 2 <= B Leaf2 Leaf3 Leaf4 Leaf5 Col 1 > 2023-02-05 Col 1 <= 2023-02-05 Col 2 > D Col 2 <= D Col 2 > C Col 2 <= C Col 1: date Col 2: customer_id Liquid Clustering ファイルサイズは均 一となりデータサイ ズの偏りはなくなる データファイルも木構 造により動的に分散さ れる(=運用負荷の軽 減)
  56. ©2024 Databricks Inc. — All rights reserved オープンなインターフェース ▪ 様々なユースケースに対応するためにオープ

    ンなインターフェースを用意する必要がある ▪ ベンダーが対応するまで使えない、ではロッ クインに ▪ 前述した通りDelta Lake等のOTFはオープン な規格になっているため各サービスの相互運 用性が高い ▪ Delta ProtocolやDelta Kernelは、各プロダク トからDelta Tableを読むためのオープンなラ イブラリセット
  57. ©2024 Databricks Inc. — All rights reserved OTFの意義をまとめていくと ▪ オープンなデータエコシステムの促進

    ▪ データレイクとデータウェアハウスの統合 ▪ ACIDトランザクションのサポート ▪ スキーマ管理と進化 ▪ データのバージョン管理とタイムトラベル ▪ パフォーマンス最適化 ▪ コスト効率の向上 ▪ コミュニティとイノベーションの推進
  58. ©2024 Databricks Inc. — All rights reserved OTFの意義をまとめていくと ▪ オープンなデータエコシステムの促進

    ▪ データレイクとデータウェアハウスの統合 ▪ ACIDトランザクションのサポート ▪ スキーマ管理と進化 ▪ データのバージョン管理とタイムトラベル ▪ パフォーマンス最適化 ▪ コスト効率の向上 ▪ コミュニティとイノベーションの推進 まさに、いい関係!
  59. ©2024 Databricks Inc. — All rights reserved (再掲)レイクハウスの基本概念 レイクハウスとは端的に言うと以下の様なものであると言える ▪

    データウェアハウスとデータレイクの利点を組み合わせたデータ管理アーキ テクチャ ▪ Apache Parquetなどのオープンなファイル形式を基盤とし、ACIDトランザク ション、バージョニング、インデックスなどを提供 ▪ BI分析からAI/MLまで、複数ワークロードを単一のプラットフォームで効率的 に処理可能 ▪ 複雑なETLは不要、データの鮮度を保ちコストを削減可能 ▪ 直接アクセス可能、オープンな形式を採用し、ベンダーロックインを極小化、 柔軟なデータ活用を実現
  60. ©2024 Databricks Inc. — All rights reserved (再掲)レイクハウスの基本概念 レイクハウスとは端的に言うと以下の様なものであると言える ▪

    データウェアハウスとデータレイクの利点を組み合わせたデータ管理アーキ テクチャ ▪ Apache Parquetなどのオープンなファイル形式を基盤とし、ACIDトランザク ション、バージョニング、インデックスなどを提供 ▪ BI分析からAI/MLまで、複数ワークロードを単一のプラットフォームで効率的 に処理可能 ▪ 複雑なETLは不要、データの鮮度を保ちコストを削減可能 ▪ 直接アクセス可能、オープンな形式を採用し、ベンダーロックインを極小化、 柔軟なデータ活用を実現 わかってきましたよね?
  61. ©2024 Databricks Inc. — All rights reserved コンピュートレイヤ データの一元管理 データレイク

     (S3、ADLS、GCS) メタデータ & ガバナンスレイヤ ETL Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用
  62. ©2024 Databricks Inc. — All rights reserved コストパフォーマンス最適化 データレイク  (S3、ADLS、GCS)

    メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用 コンピュートとスト レージの 分離 安価なクラウドス トレージの 活用 ETL
  63. ©2024 Databricks Inc. — All rights reserved BI〜AIまで、高度な分析/機械学習のサポート データレイク  (S3、ADLS、GCS)

    メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用 コンピュートとスト レージの 分離 安価なクラウドス トレージの 活用 BI〜AIまで 必要な処理を 実行可能 ETL
  64. ©2024 Databricks Inc. — All rights reserved データガバナンスの強化 データレイク  (S3、ADLS、GCS)

    メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用 コンピュートとスト レージの 分離 安価なクラウドス トレージの 活用 BI〜AIまで 必要な処理を 実行可能 統一された データ ガバナンス ETL
  65. ©2024 Databricks Inc. — All rights reserved スケーラビリティ データレイク  (S3、ADLS、GCS)

    メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用 コンピュートとスト レージの 分離 安価なクラウドス トレージの 活用 BI〜AIまで 必要な処理を 実行可能 統一された データ ガバナンス 必要な処理分 スケール可能 必要な処理分 スケール可能 パフォーマン スの最適化 ETL
  66. ©2024 Databricks Inc. — All rights reserved 柔軟性 データレイク  (S3、ADLS、GCS)

    メタデータ & ガバナンスレイヤ コンピュートレイヤ Machine Learning BI/User Data Science すべてのデータ をデータレイクへ と保存 サイロの排 除 構造化、非構造 化ファイルの同 一I/Fでの扱い クラウドスト レージの有 効活用 コンピュートとスト レージの 分離 安価なクラウドス トレージの 活用 BI〜AIまで 必要な処理を 実行可能 統一された データ ガバナンス 必要な処理分 スケール可能 必要な処理分 スケール可能 パフォーマン スの最適化 ETL
  67. ©2024 Databricks Inc. — All rights reserved まとめ ▪ レイクハウスは、データウェアハウスとデータレイクが実現できなかった事を

    実現するためDatabricksが考案 ▪ レイクハウスを構成する要素はいくつかあるが、柔軟なスケール、コストパ フォーマンス、オープンなアクセスが実現される ▪ OTFはクラウドストレージ上でメタデータ管理や、パフォーマンス管理、オー プンアクセスレイヤなどの重要な役割を果たしている ▪ レイクハウスを選定する場合、実際にそのプロダクトがレイクハウスで実現 したいことができているかを確認して選定するのが大事 ▪ うまくレイクハウスと付き合うことでデータ基盤を上手く、そして長く使えるも のにできる