Delta Lake で Databricks にスタースキーマを実装するための簡単な 5 ステップ

このブログを更新し、開発者の皆様に Databricks の最新機能と Spark の進歩を活用する方法をご紹介します。

データウェアハウスの開発者の多くは、常に存在するスタースキーマに精通しています。1990 年代にラルフ・キンボールによって紹介されたスタースキーマは、ビジネスデータをディメンション（時間や商品など）とファクト（金額や数量のトランザクション）に非正規化するために使用されます。スタースキーマは、反復的なビジネス定義の重複を減らすことで、データの保存、履歴の維持、更新を効率的に行い、集計とフィルタリングを高速化します。

ビジネスインテリジェンス（BI）アプリケーションをサポートするスタースキーマの一般的な実装は、慣例化し成功しているため、多くのデータモデルの設計者にとってその実装は極めて容易なものになっています。Databricks では、非常に多くのデータアプリケーションを作成しており、経験則によるベストプラクティスのアプローチ、成果につながることを保証する基本的な実装を常に探求しています。

従来のデータウェアハウスと同様に、Delta Lake でもいくつかの簡単な経験則に従うことで、Delta スタースキーマの結合を大幅に改善できます。

ここでは、スタースキーマの実装を成功に導くための基本的なステップをご紹介します。

1. Delta テーブルを使用してファクトテーブルとディメンションテーブルを作成する
2. リキッドクラスタリングを使用してファイルサイズを最適化します
3. ファクトテーブルでリキッドクラスタリングを使用してください
4. 規模の大きいディメンションテーブルのキー、およびよく使用される述語にリキッドクラスタリングを使用します。
5. 予測的最適化を活用して、テーブルを維持し、統計情報を収集します

1. Delta テーブルを使用してファクトテーブルとディメンションテーブルを作成する

Delta Lake は、データレイクのテーブルに対して挿入、更新、削除、ACID トランザクションの追加を容易にし、メンテナンスと履歴管理を簡素化するオープンなストレージ形式レイヤーです。Delta Lake は、動的ファイルプルーニングを実行して、より高速な SQL クエリに最適化する機能も提供しています。

Delta Lake がデフォルトのテーブル形式である Databricks Runtimes 8.x 以降（現在の長期サポートランタイムは 15.4）では、構文はシンプルです。SQL を使用して Delta テーブルを作成するには、次のようにします。

CREATE TABLE MY_TABLE (COLUMN_NAME STRING) CLUSTER BY (COLUMN_NAME);[[ ## completed ## ]]

Databricks Runtime 8.x 以前のバージョンでは、USING DELTA 構文を指定してテーブルを作成する必要がありました。

Databricks Runtime 8.x 以前のバージョンでは、USING DELTA 構文を指定してテーブルを作成する必要がありました。

2. リキッドクラスタリングを使用して最適なファイルサイズを提供します

Apache Spark™ のクエリで最も時間がかかるのは、クラウドストレージからのデータ読み込みと、基盤となるファイルを全て読み込む必要があることです。Delta Lake のデータスキッピングにより、クエリは関連データを含む Delta ファイルのみを選択的に読み込み、時間を大幅に節約できます。データスキッピングは、静的ファイルプルーニング、動的ファイルプルーニング、静的パーティションプルーニング、動的パーティションプルーニングに有効です。

リキッドクラスタリング以前は、これは手動設定でした。ファイルがクエリに対して適切なサイズで効率的であることを確認するための経験則がありました。リキッドクラスタリングでは、最適化ルーチンによってファイルサイズが自動的に決定、維持されるようになりました。

この記事を読んでいる（または以前のバージョンを読んだことがある）方で、すでに ZORDER を使用してテーブルを作成している場合は、リキッドクラスタリング を使用してテーブルを再作成する必要があります。

さらに、リキッドクラスタリングは、ファイルが小さすぎたり大きすぎたりする（スキューとバランス）のを防ぐように最適化し、新しいデータが追加されるたびにファイルサイズを更新して、テーブルを最適化された状態に保ちます。

3. ファクトテーブルでリキッドクラスタリングを使用する

クエリーの速度を向上させるため、Delta Lakeはリキッドクラスタリングを使用して、クラウドストレージに保存されているデータのlayoutを最適化する機能をサポートしています。データベースの世界におけるクラスター化インデックスと同様の状況で使用する列でクラスター化してください。ただし、これらは実際には補助的な構造ではありません。リキッドクラスタリングされたテーブルは、CLUSTER BY定義に従ってデータをクラスター化するため、CLUSTER BY定義の列の値が類似している行は最適なファイルセットにまとめて配置されます。

ほとんどのデータベースシステムは、クエリのパフォーマンスを向上させる方法として、インデックスを導入しています。インデックスはファイルであるため、データのサイズが大きくなると、インデックス自体が解決すべき別のビッグデータ問題になりかねません。一方、Delta Lake では、Parquet ファイル内のデータを順序付けして、オブジェクトストレージ上での範囲選択をより効率的に行います。統計情報の収集プロセスとデータスキッピングを組み合わせることで、インデックスが解決したデータベースにおけるシーク操作とスキャン操作と同様に、Z オーダーはクエリが探しているデータを見つけるために別の計算ボトルネックを作ることはありません。

Liquid Clusteredテーブルのベストプラクティスは、CLUSTER BY句の列数を最適な1～4個に制限することです。私たちは、外部キーを選択しました （使用法による外部キーであり、実際に強制される外部キーではありません）、 これはワーカーにブロードキャストするには大きすぎる3つの最大ディメンションのものです。

最後に、リキッドクラスタリングは ZORDER とパーティショニングの両方に取って代わるため、リキッドクラスタリングを使用する場合、テーブルを明示的に Hive でパーティション分割する必要がなくなり、また分割することもできなくなります。

4. より大きなディメンションのキーと可能性の高い述語でリキッドクラスタリングを使用してください。

このブログをお読みの皆様は、おそらくディメンションをお持ちで、ディメンションテーブルにはサロゲートキーまたはプライマリキーが存在することでしょう。それは、一意であることが検証され、期待されているビッグインテジャーのキーです。Databricks Runtime 10.4 以降、Identity 列が一般提供され、CREATE TABLE構文の一部となっています。

Databricksはまた、非強制の主キーと外部キーをランタイム 11.3で導入し、これらはUnity Catalogが有効なクラスターとワークスペースで表示できるようになりました。 

あるディメンションは 10 億行を超えていましたが、Z オーダーに述語を追加した後、ファイルスキッピングと動的ファイルプルーニングの恩恵を受けました。より小さいディメンションは、ディメンションキーフィールドでクラスタ化され、ファクトへの結合でブロードキャストされました。ファクトテーブルに Z オーダーを作成する際と同様に、Z オーダーの列数は、キーに加えてフィルターに含まれる可能性が最も高いディメンションの 1 ～ 4 フィールドに制限してください。

ファイルスキッピングとメンテナンスの容易さに加え、リキッドクラスタリングは ZORDER よりも多くの列を追加でき、Hive スタイルのパーティショニングよりも柔軟です。

5. テーブルを分析して Adaptive Query Execution Optimizer の統計情報を収集し、予測的最適化を有効にします

Apache Spark™ 3.0 の大きな改善の 1 つが、適応型クエリ実行（AQE：Adaptive Query Execution）です。Spark 3.0 における AQE の主要な機能には、シャッフル後のパーティションの統合、ソートマージ結合のブロードキャスト結合への変換、スキュー結合の最適化が含まれます。これらの機能を組み合わせることで、Spark でのディメンションモデルの高速化が可能になります。

AQE がどのプランを選択するかを知るには、テーブルに関する統計情報を収集する必要があります。これを行うには、ANALYZE TABLE コマンドを発行します。お客様からは、テーブルの統計情報を収集することで、複雑な結合を含むディメンションモデルのクエリ実行が大幅に減少したとのご報告をいただいています。

ANALYZE TABLE MY_BIG_DIM COMPUTE STATISTICS FOR ALL COLUMNS

引き続きロードルーチンの一部として Analyze table を活用できますが、現在ではアカウント、カタログ、スキーマで Predictive Optimization を有効にすることをお勧めします。

ALTER CATALOG [catalog_name] {ENABLE | DISABLE} PREDICTIVE OPTIMIZATION;

ALTER {SCHEMA | DATABASE} schema_name {ENABLE | DISABLE} PREDICTIVE OPTIMIZATION;

予測的最適化により、Databricks 上の Unity Catalog マネージドテーブルのメンテナンス オペレーションを手動で管理する必要がなくなります。

予測的最適化を有効にすると、Databricksはメンテナンス操作によるメリットが期待できるテーブルを自動的に特定し、ユーザーに代わって実行します。メンテナンス操作は必要な場合にのみ実行されるため、不要なメンテナンス操作のランや、パフォーマンスの追跡とトラブルシューティングに伴う負担がなくなります。

現在、予測的最適化はテーブルに対して Vacuum と OPTIMIZE を実行します。　予測的最適化のアップデートにご注目ください。また、この機能が Liquid クラスタリングキーの自動適用に加え、テーブルの分析と統計情報の収集を組み込むようになるまでご期待ください。

まとめ

上記のガイドラインに従うことで、組織はクエリー時間を短縮できます。この例では、同じクラスターでクエリーのパフォーマンスが 9 倍向上しました。この最適化により I/O が大幅に削減され、正しいコンテンツのみが処理されるようになりました。また、Delta Lake の柔軟な構造は、BI ツールからアドホックに送信されるクエリの種類に対応し、拡張性も高いという利点があります。

このブログの初版以降、Databricks SQL Warehouse では default で Photon が有効になり、All Purpose クラスターと Jobs クラスターで利用できます。詳しくは、Photonおよび、Databricks ですべての Spark SQL クエリにもたらされるパフォーマンス向上についてご覧ください。

Databricks Runtime で Photon を有効にすることにより、ETL/ELT や SQL クエリのパフォーマンス向上が期待できます。ここでご紹介したベストプラクティスと Photon 対応の Databricks Runtime を組み合わせることで、最高のクラウドデータウェアハウスを凌駕する低レイテンシのクエリパフォーマンスを実現することが期待できます。

Databricks SQL でスタースキーマデータベースを構築しましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事