レイクハウスとはなんだったのか？

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

©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間のデータ一貫性＆データの鮮度＆データのサイロ化

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

©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

Slide 20

Slide 20 text

©2024 Databricks Inc. — All rights reserved レイクハウスの利点レイクハウスはデータレイクとデータウェアハウスの利点の組み合わせ： ▪ DL上で従来の分析DBMSの管理機能、パフォーマンスを提供 ▪ ACIDトランザクション ▪ データのバージョニング ▪ 監査機能 ▪ インデックス作成 ▪ キャッシング ▪ クエリ最適化 ▪ 低コストで直接アクセス可能なストレージをベースにする ▪ Databricksではクラウドストレージをベースとしている

Slide 21

Slide 21 text

Slide 22

Slide 22 text

©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

Slide 23

Slide 23 text

©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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

©2024 Databricks Inc. — All rights reserved レイクハウスというアーキテクチャの妥当性前の話を踏まえてざっとまとめてみるとこんなところ？ ▪ 様々なワークロードへの対応 ▪ BI、AI、MLなど様々なワークロードに対応する必要がでてきた ▪ クラウドストレージの有効活用というアプローチが認められた ▪ ストレージとコンピュートの分離（パフォーマンス、コスト） ▪ スタートアップから大企業まで使いやすい ▪ エコシステムの充実

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

©2024 Databricks Inc. — All rights reserved レイクハウスあるあるクイズその2 OTFとクラウドストレージを使っていれば全てレイクハウスアーキテクチャといえる？ 1. Yes 2. No 3. 場合による OTFを使っていれば全てレイクハウスアーキテクチャではない実際にはSSOTが保たれている、オープンなアクセスが実現できている、などレイクハウスであるためには色々な考え方があります

Slide 50

Slide 50 text

Slide 51

Slide 51 text

©2024 Databricks Inc. — All rights reserved レイクハウスって全部同じ？レイクハウスってどうなってたらレイクハウスでしょうか？大事なポイントを列挙 ▪ オープンでロックインを避ける構成である事 ▪ 統一されたプラットフォームである事 ▪ 複数サービスの組み合わせではなく統一されたガバナンスが実現されている事 ▪ 複数プラットフォーム間でデータのコピーが発生しない事

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

©2024 Databricks Inc. — All rights reserved OTFが実現するもの Delta Lakeで実現される機能群 ▪ メタデータ管理 ▪ パフォーマンス最適化 ▪ トランザクション管理 ▪ オープンなインターフェースデータレイク　（S3、ADLS、GCS）メタデータ & ガバナンスレイヤコンピュートレイヤ Machine Learning BI/User Data Science OTFはここ

Slide 62

Slide 62 text

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

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 ファイルサイズは均一となりデータサイズの偏りはなくなるデータファイルも木構造により動的に分散される（＝運用負荷の軽減）

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

Slide 96

Slide 96 text

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