メインコンテンツまでスキップ

Databricks でのデータ変換とは

データ変換とは、データを使用可能な形式に変換、クレンジング、構造化するプロセスです。 データ変換は通常、Databricksの メダリオンアーキテクチャ に従って、生のデータをビジネスで利用可能な形式に段階的に絞り込みます。

次の図は、この例で顧客名のない顧客データを削除することで、 raw_customers データセットを clean_customers データセットに変換する一連のデータ変換を含むデータパイプラインを示しています。 raw_transactionsデータは、ゼロのドル値でトランザクションを削除することでclean_transactionsに変換されます。sales_report と呼ばれる結果のデータセットは、clean_customers と clean_transactionsの結合です。アナリストは、 sales_report をアナリティクスとビジネスインテリジェンスに使用できます。

データ変換の例

この記事では、ETLまたはELTの T に関連する トランスフォーメーション の定義に焦点を当てています。 Apache Spark 処理モデルでは、 変換 という単語も関連する方法で使用されます。「Databricks が Apache Spark 用に最適化される方法」を参照してください。

データ変換の種類​

Databricks では、 宣言型 と 手続き型の 2 種類のデータ変換が考慮されます。 前の例のデータパイプラインは、どちらのパラダイムを使用しても表現できます。

宣言型変換は、目的の結果をどのように達成するかではなく、望ましい結果に焦点を当てます。 変換のロジックは上位レベルの抽象化を使用して指定し、DLT はそれを最も効率的に実行する方法を決定します。

手続き型データ変換は、明示的な命令による計算の実行に重点を置いています。 これらの計算は、データを操作するための操作の正確なシーケンスを定義します。 手続き型アプローチでは、実行をより詳細に制御できますが、複雑さが増し、メンテナンスが難しくなります。

宣言型データ変換と手続き型データ変換のどちらを選択するか​

DLT を使用した宣言型データ変換は、次の場合に最適です。

  • 迅速な開発とデプロイが必要です。
  • データパイプラインには、実行を低レベルで制御する必要のない標準パターンがあります。
  • 組み込みのデータ品質チェックが必要です。
  • メンテナンスと可読性は最優先事項です。

Apache Spark コードを使用した手続き型データ変換は、次の場合に最適です。

  • 既存の Apache Spark コードベースを Databricks に移行しています。
  • 実行をきめ細かく制御する必要があります。
  • MERGE や foreachBatch などの低レベルの APIs にアクセスする必要があります。
  • Kafka または外部の Delta テーブルにデータを書き込む必要があります。

ストリーミングとバッチ処理の違いは何ですか?​

ストリーミング処理とバッチ処理は Databricks でほぼ同じ構文を使用しますが、それぞれに固有のセマンティクスがあります。

バッチ処理では、一定量の静的で変更されないデータを 1 つの操作として処理する明示的な命令を定義できます。

ストリーム処理を使用すると、無制限で継続的に増加するデータセットに対するクエリを定義し、データを小さな増分バッチで処理できます。

Databricksのバッチ操作では Spark SQL または データフレームが使用されますが、ストリーム処理では構造化ストリーミングが活用されます。

バッチ Apache Spark コマンドと構造化ストリーミングを区別するには、次の表に示すように、読み取り操作と書き込み操作を確認します。

Apache Spark

構造化ストリーミング

読み取り

spark.read.load()

spark.readStream.load()

書き込み

spark.write.save()

spark.writeStream.start()

マテリアライズドビューは、通常、バッチ処理の保証に従いますが、可能な場合はDLTを使用して結果を増分的に計算します。マテリアライズドビューによって返される結果は、常にロジックのバッチ評価と同じですが、 Databricks 可能な場合はこれらの結果をインクリメンタルに処理しようとします。

ストリーミング テーブルは常に結果を増分的に計算します。 多くのストリーミングデータソースはレコードを数時間または数日間のみ保持するため、ストリーミング テーブルで使用される処理モデルでは、データソースからのレコードの各バッチが 1 回だけ処理されると想定されています。

Databricks では、次のユース ケースで SQL を使用してストリーミング クエリを記述することがサポートされています。

  • を使用して でストリーミングテーブルを定義するUnity CatalogDatabricks SQL
  • DLT パイプラインのソース コードの定義。

構造化ストリーミング コードを使用して、DLT でストリーミングテーブル Python 宣言することもできます。

バッチ変換​

バッチ変換は、特定の時点で明確に定義されたデータ資産のセットに対して動作します。バッチ変換は 1 回限りの操作ですが、多くの場合、本番運用システムを最新の状態に保つために定期的に実行されるスケジュールされたジョブまたはパイプラインの一部です。

インクリメンタル変換​

インクリメンタルパターンは、通常、データソースが追加専用であり、安定したスキーマを持つことを前提としています。 次の記事では、更新、削除、またはスキーマの変更が発生するテーブルの増分変換のニュアンスについて詳しく説明します。

ほぼリアルタイムの変換​

Delta Lake は、レイクハウスをクエリするすべてのユーザーとアプリケーションに対して、大量のデータへのほぼリアルタイムのアクセスを提供することに優れています。クラウドオブジェクトストレージへのファイルやメタデータの書き込みにはオーバーヘッドがあるため、Delta Lakeシンクに書き込む多くのワークロードでは、真のリアルタイムレイテンシに到達できません。

低レイテンシのストリーミングアプリケーションの場合、Databricks では、Kafka などのリアルタイムワークロード用に設計されたソースシステムとシンクシステムを選択することをお勧めします。Databricks to エンリッチデータ (集計、ストリーム間の結合、レイクハウスに格納されている緩やかに変化するディメンション データとのストリーミング データの結合など) を使用できます。

に最終更新