Announcing Delta Lake 3.0 with New Universal Format and Liquid Clustering | Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Delta Lakeはあなたのデータに対する分析とAIを統合するユニバーサルストレージフォーマットです
現在はプレビューで利用できるLinux FoundationのオープンソースのDelta Lakeプロジェクトの次のメジャーリリースであるDelta Lake 3.0を発表できることを嬉しく思っています。このリリースに非常に大きな貢献をしたDelta Lakeコミュニティに感謝の意を表します。Delta Lake 3.0では以下のパワフルな機能を導入します:
- Deltaユニバーサルフォーマット(UniForm) によって、アプリケーションが必要とするフォーマットでDeltaを読み込み、互換性を改善し、エコシステムを拡張することができます。DeltaはApache IcebergやApache Hudiで必要とされるメタデータを自動で生成するので、ユーザーはフォーマットを選択したり、フォーマット間の手動での変換を行う必要はありません。UniFormによって、Deltaはエコシステム横断で動作するユニバーサルフォーマットとなります。
- Delta Kernelは、Deltaプロトコル仕様の複雑な詳細のすべてを隠蔽するシンプルで限定的なプログラムAPIを提供することで、Deltaコネクターの構築をシンプルにします。
- リキッドクラスタリング(まもなく提供) は、データの成長に合わせたコスト効率の高いクラスタリングによって、ベストなクエリーパフォーマンスの実現をシンプルにします。
この記事では、Delta Lake 3.0の機能の詳細を、それらが解決する顧客の課題のレンズを通じてディープダイブします。
課題 #1: データレイクハウスのアイデアは好きだけど、どのストレージフォーマットを選んだらいいの？
企業は、自分たちのデータウェアハウスとデータレイクを組み合わせて、オープンデータレイクハウスに統合することに興味を持っています。この動きは、データをプロプライエタリなフォーマットにロックされることを回避し、データの単一コピーに対して適切なジョブのための適切なツールを活用することを可能とします。しかし、彼らは単一のオープンレイクハウスフォーマットに標準化すべきか、その際にどれを使うべきかの意思決定に苦慮しています。彼らの様々なチームによって多数の既存データウェアハウスやデータレイクが活用されており、それぞれに適したデータコネクターを使っているかもしれません。お客様は、単一のストレージフォーマットを選択することで、自分たちをある種のロックインされた状態にしてしまい、一方通行のドアを潜ることになってしまわないかと心配しています。マイグレーションは高コストで困難なものなので、適切な意思決定を事前に行い、それを一度限りのものにしたいと考えています。彼らは究極的には、ETL、BI、AIを含むすべてのデータワークロードを最安価でかつベストなパフォーマンスを得て、そのデータをどこからでも利用できる柔軟性を持ちたいと考えています。
ソリューション: Delta UniFormはDelta Lakeを自動かつ即座にIcebergやHudiに変換します
Deltaユニバーサルフォーマット(UniForm)は、追加のデータコピーやさらなるデータサイロを作り出すことなしに、テーブルフォーマットを自動で統合します。IcebergやHudiデータと動作するように設計されたクエリーエンジンを使用しているチームは、データコピーやデータ変換を行うことなしに、シームレスにDeltaテーブルを読み込むことができるようになります。Deltaで書かれたテーブルはどこでもIcebergやHudiリーダーから読み込むことができるので、お客様は単一のフォーマットを選択する必要がありません。
UniFormは、3つすべてのオープンレイクハウスフォーマットが、Parquetデータファイルの上に存在する薄いメタデータレイヤーであるという事実を活用しています。書き込みが行われると、UniFormはHudi、Iceberg、Deltaの仕様に応じたこのメタデータレイヤーをインクリメンタルに生成します。
ベンチマークでは、UniForm導入によるパフォーマンスやリソースのオーバーヘッドは無視できるものであることを確認しました。また、Z-orderのようにDeltaの改善されたデータレイアウト機能によって、ネイティブのIcebergよりもUniForm有効化テーブルで読み込み性能の改善を確認しました。
UniFormによって、お客様はDeltaを選択することで、レイクハウスフォーマットをサポートするすべてのツールからの幅広いサポートを得られることを知ることとなり、自信を持ってDeltaを選択することができます。
「金融サービス業界におけるコラボレーションとイノベーションは、オープンソースコミュニティやFINOSとのパートナーシップによって維持しているGoldman SachsのオープンソースデータプラットフォームであるLegendのようなプロジェクトによって推進されます。」Goldman SachsのChief Data Officer and Head of Data EngineeringであるNeema Raphaelはこう述べます。「テクノロジーの未来に対するオープンソースの重要性を長い間信じ続けており、Data bricksがDelta Lakeに投資をつづていることを知って興奮しています。組織は、オープンなテーブルフォーマットの選択によって制限を受けるべきではなく、Delta Lakeのユニバーサルフォーマットは、コミュニティ全体を前進させ続けることでしょう。」
課題 #2: 最適なパフォーマンスに適したパーティショニングキーを見つけ出すことは普遍的な問題となっています
データレイクハウスを構築する際、現在のデータクエリーパターンにのみフィットするだけでなく、今後の新たなワークロードにも適応する全てに当てはまるパーティショニング戦略を思いつくことは困難です。固定されたデータレイアウトのため、適切なパーティショニング戦略を選択することは、チームがパーティショニング戦略に対して注意深い検討と事前の計画に労力を費やさなくてはならないことを意味します。そして、ベストな努力にも関わらず、クエリーパターンは変化し、初期のパーティショニング戦略は非効率的で高価なものとなってしまいます。パーティション進化のような機能は、Hiveスタイルのパーティショニングをさらに柔軟なものにするので何かしら有用ですが、テーブルオーナーは継続的にテーブルを監視し、パーティショニングカラムを「進化」させなくてはなりません。これらステップのすべては、エンジニアリング作業を追加し、データから洞察を得たいだけの大規模なユーザーセグメントでこれを行うことは簡単なことではありません。ベストな努力にも関わらず、パーティションにまたがるデータの分布は、時間が経つ御tに非均衡なものとなり、読み/書き性能に直接のインパクトを与えます。
ソリューション: リキッドの柔軟なデータレイアウト技術は、現状のデータとその成長に合わせて自己チューニングを行います
リキッドクラスタリングはDeltaテーブルのスマートなデータ管理テクニックです。これは柔軟で、クラスタリングキーに基づいてデータレイアウトを自動で調整します。リキッドクラスタリングは、データパターンに基づいてデータを動的にクラスタリングし、Hiveパーティショニングでは起こり得る過度のあるいは十分でないパーティショニング問題を回避します。
- リキッドはシンプルです: 最も頻繁にクエリーされるカラムにリキッドクラスタリングキーを設定します。カラムのカーディナリティ、パーティションの順序、完全なパーティショニングキーとして動作する人工カラムの作成のような従来の検討事項に悩むことはありません。
- リキッドは効率的です: インクリメンタルに新規データをクラスタリングするので、パフォーマンス改善とコストの削減、書き込みの増加のトレードオフを気にする必要はありません。
- リキッドは柔軟です: 既存データを再書き込みすることなしに、リキッドによってクラスタリングされるカラムをクイックに変更することができます。
リキッドのパフォーマンスをテストするために、典型的な1TBのデータウェアハウスのワークロードをでベンチマークを実行しました。リキッドクラスタリングによって、Z-orderよりも2.5倍高速なクラスタリングとなりました。同じ試験では、従来型のHiveスタイルのパーティショニングは、大量のパーティションを書き出すために必要な高コストのシャッフルにおyって、桁違いに遅い結果となりました。また、リキッドは新規データが取り込まれるたびにインクリメンタルにクラスタリングを行うので、定常的に高速な読み込みパフォーマンスへの道を拓きます。
課題 #3: インテグレーションにおいては、どのコネクターの優先づけを行うのかがトリッキーです
Deltaのコネクターエコシステムは大きなものであり、フォーマットの迅速な導入に応えるために成長しています。エンジンのインテグレータや開発者は、オープンソースストレージフォーマットのコネクターを開発するので、どのフォーマットの優先度を第一にするのかに関する意思決定を行います。すべての新たなプロトコル仕様は新たなコードを必要とするので、メンテナンスの時間とエンジニアリングリソースのコストのバランスを取らなくてはなりません。
ソリューション: Kernelはコネクターエコシステムを統合します
Delta Kernelは、Deltaプロトコル仕様の複雑な詳細のすべてを隠蔽するシンプルで限定的なプログラムAPIを提供する新たな取り組みです。カーネルによって、コネクターの開発者は一行のコードではなくカーネルバージョン自身のバージョンを更新することで、すべてのDeltaの新機能にアクセスできるようになります。エンドユーザーにとって、これはエコシステムで最新のDeltaのイノベーションにより迅速にアクセスできるようになることを意味します。
UniFormと組み合わせることで、Deltaは自動でIcebergやHudiのメタデータを書き出すことになるので、Kernelはコネクターエコシステムをさらに統合します。エンジンのインテグレータにとっては、これはDelta向けに開発したら、すべての人向けに開発したことになることを意味します。
今時点でも、Delta Lake 3.0のプレビューリリース候補は利用できます。また、Databricksのお客様はDBR 13.2や、まもなく提供される次のDBSQLのプレビューチャネルでこれらの機能をプレビューすることができます。
オープンソースDelta Lakeコミュニティへの参加に興味がありますか？
詳細に関してはDelta Lakeニアk洲エスしてください。SlackやGoogle Group経由でDelta Lakeコミュニティに参加することができます。プロジェクトへの貢献に興味があるのであれば、こちらでオープンイシューの一覧をご覧ください。
これらのリリースをコミュニティで利用できるようにしてくれた以下の貢献者に大きな感謝の意を表します:
Ahir Reddy, Ala Luszczak, Alex, Allen Reese, Allison Portis, Antoine Amend, Bart Samwel, Boyang Jerry Peng, CabbageCollector, Carmen Kwan, Christos Stavrakakis, Denny Lee, Desmond Cheong, Eric Ogren, Felipe Pessoto, Fred Liu, Fredrik Klauss, Gerhard Brueckl, Gopi Krishna Madabhushi, Grzegorz Kołakowski, Herivelton Andreassa, Jackie Zhang, Jiaheng Tang, Johan Lasperas, Junyong Lee, K.I. (Dennis) Jung, Kam Cheung Ting, Krzysztof Chmielewski, Lars Kroll, Lin Ma, Luca Menichetti, Lukas Rupprecht, Ming DAI, Mohamed Zait, Ole Sasse, Olivier Nouguier, Pablo Flores, Paddy Xu, Patrick Pichler, Paweł Kubit, Prakhar Jain, Ryan Johnson, Sabir Akhadov, Satya Valluri, Scott Sandre, Shixiong Zhu, Siying Dong, Son, Tathagata Das, Terry Kim, Tom van Bussel, Venki Korukanti, Wenchen Fan, Yann Byron, Yaohua Zhao, Yuhong Chen, Yuming Wang, Yuya Ebihara, aokolnychyi, gurunath, jintao shen, maryannxue, noelo, panbingkun, windpiger, wwang-talend