Databricks でテーブルをパーティション分割する場合
Databricks 、すべての新しい Delta テーブルにリキッドクラスタリングを使用することをお勧めします。 「Deltaテーブルにリキッドクラスタリングを使用する」を参照してください。
リキッドクラスタリングは、「リキッドパーティション」と呼ばれることもあります。 この記事では、従来の Delta パーティショニングについてのみ言及しており、リキッドクラスタリングについては言及していません。
この記事では、Databricks でテーブルをパーティション分割する方法の概要と、Delta Lake によってサポートされるテーブルのパーティション分割をいつ使用する必要があるかに関する具体的な推奨事項について説明します。 組み込みの機能と最適化により、データ量が 1 TB 未満のほとんどのテーブルではパーティションは必要ありません。
Databricks は、すべてのテーブルに対して Delta Lake by デフォルトを使用します。 次の推奨事項は、すべてのテーブルで Delta Lake を使用していることを前提としています。
Databricks Runtime 11.3 LTS 以降では、パーティション分割されていないテーブルのデータがインジェスト時間ごとに自動的にクラスタリングDatabricks。「インジェスト時間クラスタリングの使用」を参照してください。
小さなテーブルをパーティション分割する必要がありますか?
Databricks では、データに含まれるテーブルを 1 テラバイト未満でパーティション分割しないことをお勧めします。
テーブル内の各パーティションの最小サイズはいくつですか?
Databricks では、すべてのパーティションに少なくとも 1 ギガバイトのデータを含めることをお勧めします。 パーティションが少なく、大きいテーブルは、小さなパーティションが多数あるテーブルよりもパフォーマンスが向上する傾向があります。
インジェスト時間クラスタリングを使用する
Delta Lake と Databricks Runtime 11.3 LTS 以降を使用すると、パーティション分割されていないテーブルを作成すると、 インジェスト時間クラスタリングのメリットが自動的に得られます。 インジェスト時間には、datetime フィールドに基づくパーティション分割戦略と同様のクエリの利点があり、データの最適化やチューニングは必要ありません。
テーブルで UPDATE ステートメントまたは MERGE ステートメントを使用して多数の変更を実行するときにインジェスト時間のクラスタリングを維持するために、Databricks では、インジェスト順序に一致する列を使用してZORDER BYでOPTIMIZEを実行することをお勧めします。たとえば、イベントのタイムスタンプや作成日を含む列などです。
Delta Lake と Parquet はパーティション分割戦略を共有していますか?
Delta Lake は、データを格納するための主要な形式として Parquet を使用し、パーティションが指定された一部の Delta テーブルは、Apache Spark で格納された Parquet テーブルと同様の構成を示しています。 Apache Spark は、Parquet 形式でデータを保存するときに Hive スタイルのパーティション分割を使用します。 Hive スタイルのパーティション分割は Delta Lake プロトコルの一部 ではなく 、ワークロードは Delta テーブルと対話するためにこのパーティション分割戦略に依存しないでください。
Delta Lake の多くの機能は、Parquet、Hive、または以前の Delta Lake プロトコル バージョンから転送された可能性のあるデータ レイアウトに関する仮定を破ります。 Delta Lakeに保存されているデータとは、常に公式にサポートされているクライアントと APIsを使用して操作する必要があります。
Delta テーブルの列マッピングを有効にすると、Hive スタイルのパーティション分割のパーティション ディレクトリ内の列名がランダムなプレフィックスに置き換えられます。 「Delta Lake 列マッピングを使用した列の名前変更と削除」を参照してください。
Delta Lakeパーティションは他のデータレイクのパーティションとどのように異なりますか?
Databricks と Delta Lake は、Apache Spark、Parquet、Hive、Hadoop などのオープンソーステクノロジーを基盤としていますが、これらのテクノロジーで役立つパーティション分割の動機や戦略は、一般的に Databricks には当てはまりません。 テーブルをパーティション分割する場合は、戦略を選択する前に次の点を考慮してください。
- トランザクションはパーティション境界によって定義されません。 Delta Lake はトランザクション ログを通じて ACID を保証するため、アトミックな検出を確実にするためにデータのバッチをパーティションで区切る必要はありません。
- Databricks コンピュート クラスターには、物理メディアに関連付けられたデータの局所性はありません。 レイクハウスに取り込まれたデータは、クラウドオブジェクトストレージに保存されます。 データ処理中にデータがローカルディスクストレージにキャッシュされるのに対し、Databricksはファイルベースの統計を使用して、並列ロードの最小データ量を特定します。
Z-Orderとパーティションはどのように連携しますか?
パーティションと共にZ-Order インデックスを使用すると、大規模なデータセットに対するクエリを高速化できます。
ほとんどのテーブルでは、 インジェスト時間のクラスタリング を活用できるため、 Z-Order やパーティションのチューニングについて心配する必要がなくなります。
パーティション境界と Z-order に基づくクエリー最適化戦略を計画する際には、次の規則に留意することが重要です。
- Z-order は、
OPTIMIZEコマンドと連携して機能します。 パーティション境界を越えてファイルを結合することはできないため、Z-order クラスタリングはパーティション内でのみ発生します。 パーティション分割されていないテーブルの場合、テーブル全体でファイルを結合できます。 - パーティション分割は、カーディナリティの低いフィールドまたは既知のカーディナリティ フィールド (日付フィールドや物理的な場所など) に対してのみ有効で機能し、タイムスタンプなどのカーディナリティの高いフィールドには機能しません。 Z-order は、カーディナリティの高いフィールドや無限に増加する可能性のあるフィールド (タイムスタンプやトランザクション テーブルや注文テーブルの顧客 ID など) を含むすべてのフィールドで機能します。
- パーティション分割に使用されるフィールドの Z-order はできません。
パーティションが非常に悪い場合、一部のDatabricks機能がそれらを使用するのはなぜですか?
パーティションは、特に非常に大きなテーブルの場合に有益です。 パーティション分割に関する多くのパフォーマンス強化は、非常に大きなテーブル (数百テラバイト以上) に重点を置いています。
多くの顧客は、Parquetベースのデータレイクからデルタレイクに移行します。 CONVERT TO DELTA ステートメントを使用すると、既存のデータを書き換えることなく、既存の Parquet ベースのテーブルを Delta テーブルに変換できます。そのため、多くの顧客には、以前のパーティション分割戦略を継承する大きなテーブルがあります。 Databricks によって開発された一部の最適化では、可能な場合はこれらのパーティションを活用し、Delta Lake 用に最適化されていないパーティション分割戦略の潜在的な欠点を軽減します。
Delta Lake と Apache Spark はオープンソースのテクノロジです。 Databricksはパーティション分割への依存を減らす機能を継続的に導入していますが、オープンソースコミュニティは複雑さを増す新機能を構築し続ける可能性があります。
Databricks の組み込み最適化をカスタムパーティショニングで凌駕することは可能ですか?
Apache Spark と Delta Lake の経験豊富なユーザーの中には、 インジェスト時間のクラスタリングよりも優れたパフォーマンスを提供するパターンを設計して実装できる場合があります。 不適切なパーティション分割状態を実装すると、ダウンストリームのパフォーマンスに非常に悪影響を与える可能性があり、修正するためにデータの完全な書き換えが必要になる場合があります。 Databricks では、ほとんどのユーザーがデフォルトの設定を使用して、コストのかかる非効率性の発生を避けることをお勧めします。