最新のデータプラットフォームのためのSQL ETLの再考

SQLは、現代のデータ操作の基盤です。アナリティクスエンジニアが変換を定義し、データウェアハウスエンジニアがパイプラインを管理し、アナリストがデータを探索・洗練する方法です。

しかし、SQL自体は標準化されていますが、SQL ETLを実行するために使用されるシステムはそうではありません。

ほとんどの組織では、SQLパイプラインは複数のツールの組み合わせに分散しています。実行のためにはデータウェアハウス、モデリングのためには変換フレームワーク、スケジューリングのためにはオーケストレーター、そして監視、リネージ、データ品質のためには個別のシステムを使用します。各レイヤーは特定のニーズに対応しますが、全体として、運用が困難で、拡張性もますます低下する断片化された環境を作り出しています。

データチームが拡大するにつれて、この断片化は日常業務に現れ始めます。パイプラインは複数のシステムで失敗し、依存関係の追跡が困難になり、問題の解決には、連携するように設計されていないツール間を移動する必要が生じることがよくあります。同時に、期待値は高まります。チームは、運用オーバーヘッドを増やすことなく、より新鮮なデータを提供し、より多くのユースケースをサポートし、より速く進むことを求められます。

ここで多くのデータプラットフォーム戦略が破綻し始めます。組織が最新のインフラストラクチャに投資しても、SQL ETLはしばしば複数のシステムに分散したままで、同じ複雑さと制約を引き継いでいます。

課題はSQL自体ではなく、SQL ETLの実装方法にあります。

もしSQL ETLが、チームが実際に現在どのように作業しているかに基づいてゼロから設計されていたら、それは非常に異なるものになっていたでしょう。実際には、それは以下を意味します。

• ETLのための単一プラットフォーム
• すべてのSQLプラクティショナーのサポート
• オープンで将来性のあるパイプライン

これらの原則は together、SQL ETLに対するよりシンプルで耐久性のあるアプローチを定義します。それは、今日断片化を減らしながら、時間の経過とともにデータワークロードが進化するのをサポートします。

単一プラットフォームでSQL ETLを実行・運用する

SQL ETLの課題は、変換を記述することではなく、複数のシステムにまたがるパイプラインを運用することです。

実際には、これはデータウェアハウスでの実行、別のシステムでのオーケストレーション、そして後から追加されるオブザーバビリティの調整を意味します。パイプラインを実行し続けるには、これらのピースを連携させる必要があります。つまり、コンテキストを共有しないツール間で、依存関係を追跡し、障害を診断し、リトライを管理する必要があります。

パイプラインの数と重要性が増すにつれて、この調整は大きな運用上の負担となります。

統合プラットフォームは、これらの機能を統合することで、このモデルを簡素化します。実行、オーケストレーション、オブザーバビリティ、ガバナンスが同じシステムの機能である場合、パイプラインは設計上管理しやすくなります。依存関係は自動的に追跡され、関連するコンテキストが1か所で利用できるため、問題をより迅速に特定・解決できます。

Databricksでは、SQL ETLは単一のプラットフォーム内で定義および実行されます。パイプラインは組み込みのオーケストレーションで実行され、リネージとオブザーバビリティは各ステージで自動的にキャプチャされます。データ品質チェックとガバナンス制御は、個別のツールで管理されるのではなく、パイプライン実行に直接統合されています。

このアプローチは、サーバーレスインフラストラクチャとAI駆動の最適化によってさらに強化されます。パフォーマンスチューニング、リソース管理、スケーリングは自動的に処理されるため、チームはシステムの運用ではなく、信頼性の高いデータの提供に集中できます。

Databricksパイプラインをサーバーレスコンピューティングに移行した後、HPはクラウド費用を32%以上削減し、ジョブの合計実行時間を36%短縮しました。サーバーレスが提供する容易なインフラストラクチャ管理は、この決定を明白かつ戦略的な選択にしました。 — Luis Alonso, Head of Data Strategy & Engineering at HP Marketing

その結果、SQL ETLのための、より合理化され信頼性の高い基盤が得られます。これは、パフォーマンスと信頼性をスケールで向上させながら、運用オーバーヘッドを削減します。

チームが実際にSQLパイプラインを構築する方法をサポートする

SQL ETLが断片化されているのは、ツールのためだけでなく、チームがパイプラインを構築する方法がすべて同じではないためです。

SQLでビジネスロジックを定義することに重点を置くアナリティクスエンジニアは、基盤となるインフラストラクチャを管理することなくパイプラインを構築する方法を求めており、テスト、バージョン管理、依存関係は自動的に処理されます。データウェアハウスエンジニアは、SQLスクリプトとストアドプロシージャに依存する傾向があり、多くの場合、厳密に管理された実行環境内で作業します。アナリストは、ノーコードツールや軽量SQLインターフェース内で直接変換を作成する場合があります。

多くのプラットフォームは、これらのアプローチのいずれかを暗黙的に優先します。組織が成長するにつれて、他のペルソナをサポートするために追加のシステムを導入することが多く、標準化と維持が困難な並列環境が生じます。

より効果的なアプローチは、インターフェースではなくプラットフォームを標準化することです。

Databricksは、同じ環境内でさまざまなSQL ETLワークフローをサポートします。チームは、プラットフォーム上で直接既存のdbtワークフローを実行したり、ウェアハウススタイルのSQLをスクリプトやストアドプロシージャにリフト＆シフトしたり、Databricks SQLのMaterialized ViewsでBIワークロードを加速したり、本番ワークフローを簡素化する宣言型パイプラインを定義したり、同じプラットフォーム上に構築されたビジネスアナリスト向けのノーコードツールを使用したりできます。これらのアプローチはパイプラインの作成方法が異なりますが、同じ実行エンジン、ガバナンスモデル、オブザーバビリティフレームワークを共有しています。

この一貫性により、組織は断片化を導入することなく、複数の開発スタイルをサポートできます。チームは、リネージ、監視、運用管理を共有しながら、ニーズに合った抽象化レベルで作業できます。

また、既存のウェアハウススタイルのSQLスクリプトと新しいアプローチが、同じ基盤上で共存できることも保証します。チームは、既存のものを維持することと新しいパターンを採用することの間で選択する必要はありません。単一のシステム内で両方を行うことができます。

これらのワークフローはそれぞれ、専用の作成エクスペリエンスに反映されています。

1. SQLスクリプトとストアドプロシージャを実行するデータウェアハウスエンジニア向け：

ストアドプロシージャとマテリアライズドビュー用のSQLエディタ

">

2. SQLで本番パイプラインを構築するアナリティクスエンジニア向け：

Spark Declarative Pipelines Editor

3. コードなしでデータを準備するアナリストとビジネスユーザー向け：

Lakeflow Designer

その結果、SQL ETLのための、よりまとまった環境が得られ、コラボレーションが向上し、運用上の複雑さがスケールとともに増加しないようになります。

ワークロードに合わせて進化するSQLパイプラインを構築する

新しいデータソース、リアルタイムユースケース、AIワークロードが登場するにつれて、チームは追加のシステムを導入したり、既存のパイプラインを書き直したりすることを余儀なくされることが多く、時間の経過とともに複雑さとコストが増加します。

多くのSQL ETLソリューションは、プロプライエタリなフォーマット、密結合した実行モデル、またはデータ処理方法に関する仮定を通じて、これらの制約を導入します。これらの制約はすぐに明らかにならないかもしれませんが、組織が新しいワークロードに拡大したり、より新鮮なデータを必要としたり、より広範なユースケースをサポートしたりするにつれて表面化する傾向があります。

将来性のあるSQL ETLアプローチは、最初からオープンさと柔軟性を優先します。

Databricksは、オープンテーブルフォーマットとANSI SQL上にSQL ETLを構築しており、パイプラインがシステム間でポータブルで相互運用可能であることを保証するのに役立ちます。これにより、ロックインのリスクが軽減され、アーキテクチャが進化しても、組織はデータとロジックを制御し続けることができます。

同時に、Databricksは、バッチとリアルタイム分析の両方のユースケースをサポートする統合SQLモデルを提供します。さまざまなワークロードに個別のシステムを必要とするのではなく、同じSQLベースのアプローチを幅広いユースケースに適用できます。

この柔軟性により、組織の進化に合わせてパイプラインを拡張できます。チームは、必要に応じて増分処理や宣言型パイプラインなどの高度なパターンを採用しながら、既存のSQLワークフローを実行し続けることができます。

マテリアライズドビューへの変換により、クエリパフォーマンスが劇的に向上し、実行時間が8分からわずか3秒に短縮されました。これにより、チームはより効率的に作業し、データから得られたインサイトに基づいて迅速な意思決定を行うことができます。さらに、コスト削減も実現しました。 — Karthik Venkatesan, Security Software Engineering Sr. Manager, Adobe

厳格なアーキテクチャ上の制約を回避することで、このアプローチは、破壊的な変更を必要とせずに、現在の要件と将来の要求の両方をサポートできる安定した基盤を提供します。

SQL ETLがデータプラットフォーム戦略を形成する理由

データプラットフォームに関する議論では、データの保存場所やクエリの実行方法に焦点が当てられることがよくあります。しかし実際には、プラットフォームの有効性は、データパイプラインの構築と保守の方法、および長期的なロックインを回避するオープンで相互運用可能な方法で定義されているかどうかに大きく依存します。

SQL ETLが複数のシステムに断片化されたままだと、組織は新しいプラットフォームを採用した後でも、同じ運用上の複雑さと非効率性を引き継ぐ可能性が高くなります。時間の経過とともに、これはプラットフォームの価値を制限し、データ操作のスケーリングをより困難にします。

より効果的なアプローチは、プラットフォームが開発、実行、監視、ガバナンスに至るまで、SQL ETLのライフサイクル全体をどの程度サポートしているかを評価することです。これには、さまざまな作業スタイルをサポートし、運用オーバーヘッドを削減し、追加のシステムを導入することなく進化する要件に適応する能力が含まれます。

Databricksは、SQL実行、パイプライン管理、ガバナンス、最適化を単一のプラットフォームで統合することにより、これらのニーズに対応します。この統合アプローチにより、チームは、幅広いワークロードをサポートする柔軟性を維持しながら、SQLパイプラインをより効率的に構築および運用できます。

結論

SQLは、組織がデータと連携する方法において中心的な役割を果たし続けます。

その結果、SQL ETLの実装方法は、データプラットフォーム全体の有効性に直接影響します。断片化されたアプローチは複雑さを増し、チームの足を引っ張りますが、統合されたアプローチは運用を簡素化し、スケーラビリティを向上させます。

データプラットフォームの進化方法を評価している組織にとって、SQL ETLは中心的な考慮事項です。Databricksは、実行、パイプライン管理、ガバナンスを単一のプラットフォームに統合する、統合された将来性のあるSQL ETLのモデルを提供し、要件が進化してもオープンで適応可能であり続けます。

実際、ほとんどの組織はゼロから始めていません。本番パイプラインの書き換えにはコストとリスクが高すぎるため、SQL ETLのモダナイゼーションはしばしば停滞します。破壊的な再構築を強制するのではなく、より効果的なアプローチは、段階的に進化することです。まず既存のパイプラインを実行し、時間の経過とともにシステムを統合し、段階的にモダナイズします。

このようにして、チームは今日、断片化を減らしながら、時間の経過とともに、より統合された将来性のあるデータプラットフォームを構築できます。このアプローチについては、今後の投稿で詳しく説明します。それまでの間、ebook「SQLを使用したETLパイプライン構築ガイド」で、統合されたレイクハウスプラットフォームでSQLパイプラインを構築、実行、スケーリングする方法について詳しく読むことができます。

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