Delta Live Tables A to Z: Best Practices for Modern Data Pipelinesの自分的ポイント

DATA+AI SUMMIT 2023の配信動画を見ていますが、キーノートではあまり語られなかったData Engineering系トピックのうち、以下の内容の自分的まとめとなります。

なお、Data Engineering関連は以下の公式blogに記載があります。

Delta Live Tablesとは

宣言的プログラムによるETL処理フレームワーク。
詳細は以下参照：

Materialized ViewとStreaming Tables

Unity Catalog下で使えるようになった新しいデータベースオブジェクト。
DLTのUnity Catalog Public previewを試験したことがあるので存在は知っていましたし、Documentにもバッチリ記載があるのですが、かなり理解が進みました。

よくある用途としては以下のように紹介されています。

• Streaming Tables(STs)

  • 主にIngestion処理で選択
  • 少ないレイテンシの変換
  • 複雑な変換処理は避ける

• Materialized Views(MVs)

  • 主にデータの変換処理で選択
  • 集計処理後のテーブルとして
  • BIやレポートの高速化に貢献

DBSQLでMVsとSTsが作成可能(Preview)

DLTを使わなくても、DBSQLからMVs/STsが作成可能に。
従来のDLTによるLIVE TABLEとは異なる新たなシンタックスが用意されている。
（DLTでは旧来のシンタックスも利用可能）

MVs/STsのSQLについては公式Docを読もう。

そして、驚くべきは、dbtにもちゃんと対応している。
(materializedをstreaming_tableに設定するとStreaming Tableとして、materialized_viewに設定するとMaterialized Viewとして作成できる。

Deepdive into Streaming

DBSQLでのFULL REFRESH実行など、DLT使わなくてもSQLだけで(dbtだけで)いけそうやんという感じ。
stream-stream joinsについて、丁寧な説明があってよかった。以前ハマったことがあるので。その時に知りたかった。。。

Streaming Tables and Flows(COMING SOON)

テーブルの作成と、そのテーブルへのストリームデータのINSERT処理を分離して記述。
これによって、複数ソースから、同一テーブルへのINSERTが柔軟に書けるようになった。
DLTの弱点の一つだと思っていたので、これができるのは良い。

Streaming Update

ストリームテーブルを上流側で何らか更新した場合（例えば、機密データの削除など）、
下流で読み込む場合はskipChangeCommitsを指定してね、という話。
docにも書いてあるんだけど、忘れがちなのでメモ。

Deepdive into Materialized View

Streaming tablesと比較して、データの追加や更新削除、集計やWindows関数など通常のテーブル同様に操作できるよ、という話。

MV Incremental refresh with Enzyme(だいたいPREVIEW)

MVは変更箇所のみ更新される。また、適切にpartitionで切り分けられていれば、その範囲だけ再計算される。
他、MERGEによる特定行の更新など。
こういった複数種類の更新手段がMVにはあるが、それぞれ更新にかかるコストが違う。
EnzymeはOptimizerの一種？として、もっとも良い更新処理を自動選択してくれるらしい。

DLT Serverless(PREVIEW)

以前から情報は出ていた気がするけど、DLTのクラスタがServerlessで提供。
DLTの起動時間は前から気になっていたので、これはありがたい。
そして、DLT Serverlessだと、Enzymeが自動的に有効化される。(対象となる増分更新範囲はまだ限定的ぽい）

動画ではDLT Serverlessのデモを行っていたが、20分かかる処理が46秒になった。
MVとEnzymeをうまく使えば、非ストリームでテーブルを再作成していたような処理をかなり高速化できると思う。

日本リージョンでの提供早く！

REFERENCE ARCHITECTURE

STとMVは一緒に使おうという話。
STs for ingestion、MVs for transformationが基本ユースケース。

ELTパイプラインの設計の考え方がシンプルになるので、かなりありがたいなと思った。
処理効率性を考えてStreamテーブルでの変換を頑張っていた部分をMVに任せる形で実装できる。

Pipeline: Software development best practices

この説明を聞きながら、以下の公式blogを思い出していた。blogの一部内容を丁寧に解説してもらっていました。

Custom Schema(PREVIEW)

Unity Catalog対応になることもあって、スキーマ（カタログの次の層の意味で）の指定をカスタムできるようになる模様。
例えば、テーブルをmarketingというスキーマに作りたいとする。
これをDLTでは実行するパイプライン環境に応じて、実際のスキーマ名はmarketing_prodとかmarketing_devという名前で保存できる。プログラム中ではmarketingという指定でよくて、実行する環境に応じてどちらを使うかは切り替えられるという理解。

Choosing pipeline boundaries

パイプラインを分ける境界をどう考えるか、という話。

パイプラインをどのように分割するべきかは、いつも悩んでいたのでベストプラクティスが示されてありがたかった。これを指針としていきたい。

Lifecycle management(UC ONLY)

DLTのパイプライン設定に応じて、UC側のテーブル削除などが同期的に行われるという話。
パイプライン内のテーブル記述削除が実際のテーブル削除になるので、管理上非常にわかりやすい。
（一定期間内は復旧可能）

Unity Catalogが今後の主流になるのは間違いないとして、どのようにデータが管理されるのかとかはちゃんと理解しておかないといけないなと思いました（ただの感想）。

The power of python+DLT

SQLと比べてDLTでPythonを使う場合のメリットや機能アップデートについて。

Installing libraries with pip

内容の話ではないのですが、Unity CatalogのDLTパイプラインを組むと、現状pipでサードパーティライブラリをインストールできないという認識。このLimitationは早く無くなってほしいなあ。。。

Configurable data volumes(BEST PRACTICE)

パラメータで日付の範囲を指定させることで、テスト時のデータボリュームをコントロールできるよ、という話。
なるほど、デバッグ等にこのやり方はよいなと思いました。
なんで今までやってなかったんだろう。

Automate CI/CD: Databricks Asset Bundles

jobやパイプライン、コードのバンドル設定をyml形式の設定ファイルで記述・反映できる機能。

別セッションで紹介されています。これ、かなり大事な機能だと思います。勉強しよう。。。

おわり

Unity Catalogへの移行については考えないといけないことが多いのですが、引き続き頑張りたいと思います。
あと、アクセスモード=シングルユーザのクラスタだと現状MVが扱えないとかまだ制約があるので、このあたりの早期対応が待たれますね。