Delta v. Lambda: Why Simplicity Trumps Complexity for Data Pipelines - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
ラムダアーキテクチャからデルタアーキテクチャに切り替えることで、ETLパイプラインのパフォーマンスを劇的に改善
「ものごとはできるかぎりシンプルにすべきだ。しかし、シンプルすぎてもいけない。」 - Albert Einstein
一般的には、シンプルなデータアーキテクチャは複雑なアーキテクチャよりも好ましいとされます。コードの複雑性は障害発生地点を増加させ、ジョブの実行に必要な計算資源が多くなり、レーテンシーを増加させ、サポートの要望が増えてしまいます。結果として、データパイプラインの性能は時を経るごとに劣化し、データエンジニアがトラブルシュートに要する時間が増加し、後段にいるユーザーはデータが更新されるのをより長い時間待つことになり、コストが増加します。
バッチデータとストリーミングデータを取り扱うためにはラムダアーキテクチャが必要となるため、複雑性はビジネスレポート、SQLアナリティクス、データサイエンスにデータを提供する自動化データパイプラインの必要悪として受け取られています。ラムダアーキテクチャは、大量のバッチ、ストリーミングデータを取り扱うことができますが、バッチとストリーミングに異なるコードベースが必要となり、データの損失、破壊を引き起こす傾向があるため、複雑性が増加します。これらのデータ信頼性問題に対応するために、従来のデータパイプラインアーキテクチャは、検証、ジョブ失敗時の再処理、手動のアップデート&マージを追加することで更なる複雑性をもたらしていました。
個々のサービスのコストパフォーマンスをファインチューニングすることは可能ですが、このアーキテクチャではトータルのコストパフォーマンスを劇的に改善することはできません。
検証、ジョブ失敗時の再処理、アップデート&マージのような追加の処理を必要とし、レーテンシー、コスト、障害発生点を追加する典型的なデータパイプラインアーキテクチャ
しかし、Databricksのデルタアーキテクチャはシンプルさにフォーカスしており、データの取り込み、処理、格納、管理に対して全く異なるアプローチとなっています。ブロンズ(生データ)、シルバー(フィルター済みデータ)からゴールド(分析、レポート、データサイエンスに利用できるデータ)に至る全ての処理と補強はDelta Lakeで行われデータのホップが少なくて済みます。
ラムダは複雑でありセットアップと維持の手間がかかりますが、デルタテーブルはすぐにでもバッチとストリーミングが稼働します。皆様の生データに対するブロンズテーブルを作成し、既存のテーブルをDelta Lakeフォーマットに変化すれば、すでにデータエンジニアが抱える最初のジレンマであるバッチデータとストリーミングデータの統合を解決したことになります。ここから、データは(例えば、スキーマ強制を通じて)クレンジング、フィルタリングされシルバーテーブルに流れ込みます。ゴールドテーブルに到達するまでには、レポートの作成、ビジネス分析、MLアルゴリズムで利用できるように、最終的な浄化と厳密なテスト受けることになります。バーチャルセッションBeyond Lambda: Introducing Delta Architectureでラムダアーキテクチャをどのようにシンプルにするのかを学ぶことができます。
データ取り込みから下流での使用に至るDatabricksにおけるデルタアーキテクチャのシンプル性。シンプルさとは、データパイプラインの自動化により信頼性を高めつつもコストを引き下げることです。
これら自動化されたデータパイプラインに対して、シンプルなデルタアーキテクチャは以下のようなメリットをもたらします。
- ジョブ実行コストの削減、信頼性の向上: 1) データのホップ数、 2) ジョブ完了に至る時間、3) 失敗するジョブの数、4) クラスター起動時間を削減することで、デルタアーキテクチャはETLデータパイプラインのトータルコストを削減します。我々は自身でベンチマークを行なっていますが、あなたにとっての最適なベンチマークは、あなたご自身のデータに対してクエリーを実行することで得られます。自動化データパイプラインのベンチマークの評価方法を理解するには、ドイツナンバー1のポータルであるwetter.comがどのように異なるパイプラインアーキテクチャを評価新たのかに関するケーススタディをご覧いただくか、ご自身の環境での分析に関してsales@databricks.comにご連絡ください。
- 後段の全ユーザーに対して信頼できる唯一の情報源(single source of truth)を提供: データをレポートや分析に使える状態にするために、企業は後段での利用のために、データレイクから生データを取り出し、小規模のサブセットをっデータウェアハウスにコピーして処理するということをよく行います。これら複数のデータコピーは、データの真正性、鮮度に対する信頼が困難となるバージョン管理、一貫性の問題を引き起こします。しかし、Databricksは後段のユーザーに直接、あるいは、データウェアハウスサービスに対して唯一のデータフローを提供する統合データサービスとして動作します。データに対する新たなユースケースはテストされロールアウトされるので、新たな固有のETLパイプラインを構築する必要はなく、シンプルに同じシルバーテーブルやゴールドテーブルにクエリーを行うことができます。
- 維持管理のコードを削減: データが適切に取り込まれ処理されていることを保証するためには、従来型のデータパイプラインアーキテクチャアプローチは、追加のデータ検証処理や再処理機能を必要としました。ラムダアーキテクチャはトランザクショナルではないので、途中でデータパイプラインが失敗すると、何が起きたのかの特定、修正、部分的に書き込まれたデータ、破損したデータのハンドリングを手動で行わなくてはなりません。しかし、DatabricksのDelta LakeはACIDトランザクションでデータの信頼性の担保し、データの品質を保証します。結果として、より安定したアーキテクチャを手に入れることができ、トラブルシュートをより容易にし自動化を推し進めることができます。Guostoが自身のETLパイプラインをDatabricksで再構築した際、彼らは「良い副作用は、我々のコードベースの複雑性を減らせたことでした。Pythonコードは565行から317行になりました。YML設定は252行だったのがたった23行になりました。クラスターの作成やジョブのサブミットにおいてAirflowに依存する必要がなくなり、管理が容易になりました。」と述べています。
- 容易に新規データソースを追加: 別のデータソース(例えば、IoTや位置空間情報)の増加を目の当たりにしていますが、従来のパイプライン構築方法では、これらを追加するには固定化されすぎていました。例えば、新たなデジタルメディア広告がブリックアンドモルタル店舗への人流にどのような影響を与えるのかをより理解するために新規データソースを追加するためには、通常はエンジニアリングに数週間、数ヶ月を要することを意味します。Delta Lakeのスキーマ進化は、新規データソースの統合(あるいは、既存データソースのフォーマットの変更への対応)をシンプルにします。
最後になりますが、開発者に対してデルタアーキテクチャのシンプルさが意味することは、テクノロジーを繋ぎ合わせるのに要する時間を削減し、それらを活用することにより多くの時間を割けるということです。
皆様のデータエンジニアリングをシンプルにするのに、Delta Lakeがどのように役立つのかに関して知りたいのであれば、sales@databricks.comまでご連絡ください。