データ統合やデータ パイプラインの世界は、過去 20 年間に私がアプリケーションとサービスの開発で見てきた大きな変化を強烈に思い出させてくれるほど変化しています。この2つの変化は、純粋に技術的でもアーキテクチャ的なものでもありません。業界は、マイクロサービスが、サービス指向アーキテクチャ (SOA) を構築して、サービスを正しく提供するための優れた方法である、ということを学びました。これは、単に API の仕様やプロトコルが大幅に変化したからではなく (これについては書籍を出版済み)、マイクロサービスが新しい開発およびデリバリーの実施手法 (DevOps 思考、反復型でインクリメンタル型開発、あらゆる場所の自動化、継続的デリバリーなど) を採り入れたためです。現在、サービスを使用して組織自身の統合に役立ったのと同じ、統率が取れた開発者指向のプラクティスが、データを使用した統合に役立っています。これは統合の世界では大きな変化であるため、このブログでその理由を説明します。
データのためのあらゆる変更
ビジネスがソフトウェアそのものになるにつれて、データは成功にはますます不可欠なものになっています。かつては主にバックオフィス (いわゆる舞台裏) の問題であったデータが、今では企業が顧客に提供する製品やサービスに組み込まれています。イノベーションとワールドクラスの実践は、データ資産の検出、解放、適用を行う組織の能力にかかっています。
データ パイプラインは、データ集約型アプリケーションで差別化されていない手間のかかる処理の大半を実行し、データ統合、分析、機械学習の目的でデータを移動および変換します。そのパイプラインは、1 つ以上のソースから 1 つ以上のターゲットへのデータの移動と変換を調整し、プロトコル、フォーマット、スキーマを適合させ、ターゲット システムでの適用に備えて、データのクレンジング、正規化、エンリッチ化を行います。パイプラインは通常、複数のソースからのデータを統合して、ビジネスに有意なエンティティの単一ビューを作成したり (たとえば、CRM データと購入履歴を組み合わせて、顧客の単一ビューを作成)、後続の分析のためにデータの変換と準備を行たり(たとえば、自社開発の取引システムや Salesforce などの SaaS ソースからデータを抽出して Tableauで分析)、機械学習モデルをトレーニングする前に、生データの特徴抽出を実行したり (たとえば、既知の不正事例が含まれるクレジット カード取引データを、不正検出モデルの開発に使用できる数値特徴量にまで減じるなど)、事前に学習したモデルを使用してデータセットを評価します (以前にトレーニングを受けた不正検出モデルを使用して、新たなトランザクションを評価します)。それ自体は価値の源泉ではありませんが、それでも、組織がデータから価値を生み出すアプリケーションに代わって、必要不可欠なサービスを提供します。
しかし、パイプラインはデータ バリュー ストリームには不可欠なものでありながら、必ずしもうまく機能しているとは言えません。パイプラインは思いのほか脆弱で、特定のニーズを満たすためにアドホックで構築されており、再利用やコンポーザビリティについてはほとんど考慮されていません。また、同じ組織内の異なるパイプラインには、冗長な計算やその派生値にはさまざまな解釈が含まれていることが多く、それ故にアウトプットに対する信頼性は損なわれています。多くの組織では、どのパイプラインが使用されているか、どれが放棄されたのか、または誰がそれを所有しているかさえ明確ではありません。多くの企業にとっては、誤ったアウトプットを積極的に特定したり、エラーやデータ損失の原因を元からたどろうとすることは、不可能ではないとしても、困難です。
データ パイプラインの主なトレンド
ここ数年で、企業がデータについて考え、それを整理して、データを解放する (自由に使えるようになる) ソリューションを構築する方法に大きな変化が見られます。データの大部分をクラウドに移行する企業が増えている中で、膨大な数のクラウドベースのデータ プラットフォーム製品やサービス (総称してモダン データ スタック) が市場に出回り、企業のデータ管理能力を高速化し向上させています。
このブログでは、「パイプラインの問題」に焦点を当てています。最近のさまざまなイノベーションや実験から、業界がパイプライン エクスペリエンスをどのように改善しようとしているかが分かるトレンドを選んでみました。これらのトレンドで対処しようとしている問題やニーズを探り、その分析結果から、優れたパイプラインを構築するための 5 つの原則を導き出しました。これを「モダン データ フロー」と呼びます。
プロダクトとしてのデータ
最初のトレンドは、組織およびアーキテクチャに最も広範な影響を与えるもので、データをプロダクトとして使用する (プロダクトとしてのデータ) ことです。データ メッシュの 4 つの基本原則の 1 つである｢プロダクトとしてのデータプロダクトとしてのデータ｣は、システム間でのデータの共有は、各システムの内部的な特異性と運用上の優先事項に常に対応する必要があるという一般的な考えを大きく覆し、代わりに、外部化されたデータは、そのデータの消費者のニーズで優先付けを行った方法で、共有および適用されるように意図的に設計するべきだというものです。データをプロダクトとして扱うには、組織とそのデータとの関係を根本的に見直す必要があります。
ここでは、｢プロダクトとしてのデータ｣という考え方で分散化と連携に移行し、共有と再利用が促進されるという点に注目しています。作業主体と責任は、ドメインに依存しない中央データ処理機能から、データを最もよく理解しているチームに戻ります。データ所有者の視点から見ると、データ交換とは、もはや 1 つ以上の外部エージェントがソース システムから生データをアドホックに抽出するというものではなく、エンド ユーザーやその他のシステムといった、消費者の期待とニーズを満たす方法で、意図的にデータを共有することです。データ所有者の責任は、基盤となるデータへのアクセスを許可することだけではなく、データ ライフサイクルを通じて、健全でアクセスしやすく、使いやすい製品を維持することにまでおよびます。
しかし、この変化は、パイプラインを構築する方法に、より低レベルの変更が加わって初めて成功するものです。パイプラインの開発は、これまで長い間、純粋に技術的な問題となっており、中央集約的なデータ チームによる統合への過剰な取り組みがボトルネックとなっていましたが、現在では、ソフトウェア業界の一部でモダン化を推進したのと同じ統制の取れた手法をパイプライン ビルダーが採用し始めています。顧客に素早く繰り返し価値を提供するには、顧客との深いエンゲージメント、迅速なフィードバック ループ、継続的な進化を可能にする開発形態が必要となります。ソフトウェア開発分野では、アジャイル開発と DevOps 開発の一連のプラクティスが過去20年間で登場し、ソフトウェアをより迅速かつ高品質で提供できるようになりました。これらのプラクティスは、単体テストやテスト駆動開発から、継続的インテグレーションや継続的デリバリー、継続的可観測性（オブザーバビリティ）、そしてコードとしてのインフラストラクチャの自動化に至るまで多岐にわたります。今日では、これらの同じ手法がデータマネジメント分野にも取り入れられています。まず、表現力豊かで十分に考慮され、テスト可能で、テスト済みのシステム ユニットを作成するための低レベルなソフトウェア開発手法から始めました。
そこで気になるのが 2 つめのトレンドです。
宣言型変換モデル
宣言型変換モデルを使用すると、データ変換ロジックを個別の単位、表現力豊かで、テスト可能かつ、コンポーザブルの単位でパッケージ化できます。とても長い間、パイプラインの変換ロジックは、コントールフローのロジックに絡んで、統合ツールとそのランタイム環境に関連付けられて、UI の背後に隠れてきました。UI プレゼンテーション ロジック (テストとバージョン管理はもちろんのこと) を含む命令型コード アーティファクトとワークフローの定義から、意味のある変換情報を抽出するという不可能なタスクに直面して、データ チームはワークロードごとに新しいパイプラインを作成するという策に頼ってきました。もちろん、これはパイプライン資産の脆弱性とデータ品質の低下を招くことになります。アップストリーム データ ソースを変更すると、複数のパイプラインが分断され、共通のメトリックやビジネス ロジックの実施結果が異なってしまい、結果がバラバラで信頼できないものになってしまいます。わずかな変更でもデータ破損が運用環境全体に波及するリスクもあるため、エンジニアは既存のパイプラインを変更することを恐れて、その代わりとして、新しいワークロードごとに「もう 1 つだけ」追加することを好んでいます。
dbt は、宣言型変換モデル ワークフレームで、データ チームはSQL SELECT ステートメントを使用してモデルを作成できます。これらのモデルは、何を変換すべきかを記述します。そして、データ ウェアハウスなどのターゲット内で実行され、テーブルを作成してデータを入力します。各モデルは、単一の SELECT ステートメントをカプセル化しますが、参照関数を用いると、他のモデルからモデルを作成できます。これにより、開発者は依存する SQL ステートメントを繰り返しインライン化したり、コピーアンドペーストすることなく、単純なビルディング ブロックから複雑なモデルを構築できます。たとえば、広告収入集計モデルは、Google 広告と Facebook 広告の異なるモデルから作成することができます。アップストリーム データ ソースが変更されたなどの理由でモデルが変更された場合、その変更はモデル依存関係グラフ全体に伝播し、誤ってパイプライン ロジックが分岐されることはありません。
一見すると、これは革命的なことではないように見えます。何しろ、データ チームは、何十年もの間パイプライン内で SQL を使用してきたからです。しかし、これがデータ エンジニアリングにおいては、大きな変化であるということが分かる点がいくつかあります。
まず、dbt のようなツールは、モデル構築の中心に SELECT ステートメントを据えています。SELECT FROM は、欲しいデータがどのように表示され、どこから取得されるかを極めて簡潔に記述する表現方法です。宣言的な性質を持っているため、データのニーズの記述に集中することができ、ニーズを満たすためにデータのアセンブルに必要な一連の操作を行う (さらに最適化する) 必要がありません。
2 つめは、モデル フレームワークはモジュール型の性質を持っているため、複雑な変換をより小さく、シンプルなパーツに分割し、同じ構成要素を異なるコンテキストで再利用できます。これは、一般的なソフトウェア開発の手法です。このようなモジュール方式には、従来のパイプラインに典型的な、モノリシック SQL やコントール フロー ロジックのコピーアンドペースト ブロックがありません。このようなブロックでは、変換ロジックが繰り返し使用され、場合によっては、パイプライン間でアドホックに変化し、さらにロジック自体が、適用されるターゲット スキーマから非常に簡単に分岐する可能性があります。
3 つめは、優れた宣言型モデル フレームワークを利用すると、各モデルに対して制約とテストを記述し、開発時と実行時の両方でアサートを実行できます。これは、データのユニット テストと同じです。データ チームが、モデルやパイプラインに自信を持って制御された変更を加えることができるように、アサートされた動作の基盤を提供するだけでなく、プロダクトの観点からも興味深い可能性を広げられます。プロダクトの開発は、消費者の期待とニーズが原動力です。テストは、消費者がデータ製品のプロバイダーにこれらの要件を伝えるための、簡潔で表現力に富み、実行可能な手段を提供するものです。
dbt は、ここ数年で登場した唯一の宣言型データ モデル フレームワークというわけではありませんが、極めて汎用的なクエリ言語である SQL をそのまま使用しており、開発者指向のソフトウェア開発ライフサイクルが認知されたことから、幅広く導入されています。その他に、Looker の Malloy は、｢データの関係性と変換を記述する実験的言語｣で、RelationalAI の Rel は、｢ドメイン知識のモデリングのために設計された、表現、宣言型、リレーショナル言語｣と表現されています。2 つのうち、Rel はより成熟しており、各分野の専門家やデータ実務者が、データ内で複雑な関係を表現する実行可能な仕様を作成できる、厳密な構文を備えています。
開発者フレンドリーなツール
データ パイプライン ツールとモダン ソフトウェア デリバリー プラクティスを連携させる動きは、開発者フレンドリーな新たなビジュアル パイプ ラインビルダーの出現がそれを明白に示しています。従来のデータ プラットフォームは非常に閉鎖的な環境で、他のソフトウェア開発ツールチェーンとはまったく異なっています。大半が UI ベースで、API をほとんど、またはまったくサポートしていないため、このようなプラットフォームでは、わかりやすいコード アーティファクトが生成されることはほとんどありません。せいぜい、UI の操作に密接に結び付いたバイナリ、または独自のファイル形式のいずれかを出力する程度です。
この状態がすべて変わりました。Prophecy、Upsolver、Quix などのプラットフォーム開発ツールは、わかりやすいコード アーティファクトを生成するブラウザベースの開発環境を備えています。これらのツールは、ドラッグアンドドロップのキャンバス ビルダーとインライン コードおよびクエリ エディターを組み合わせて、非技術系および技術系ユーザーが共同作業できるようになっています。開発エクスペリエンスは依然として主に UI ベースですが、ここでの大きな違いは出力にあります。たとえば、変換ロジックには、Python や SQL、パイプライン トポロジの記述には YAML などのオープン フォーマットが使用されます。
これらの新しいツールはオープンで、しばしば宣言型のパイプラインの表現形式をサポートするだけでなく、バージョン管理や継続的インテグレーション、継続的デリバリーシステムとの統合によって、他のモダン ソフトウェア開発ツールチェーンとうまく連携します。パイプライン ビルダーは、データ ソースと再利用可能なパイプライン資産のカタログを参照し、案、レビュー、バージョン変更を行い、パイプライン コンポーネントを反復的かつインクリメンタルにテストおよびデバッグし、承認されたパイプラインをテスト環境から本番環境へとプロモートできます。これは、開発者のみにアピールするのではなく、パイプラインの構築に関わるあらゆる人に、モダンなソフトウェア開発ツールチェーンとそれにかかわるプラクティスのメリットをもたらすことから、当社では開発者フレンドリーまたは開発者指向のツールと呼んでいます。
ELT
これまで見てきたトレンドは、分散化が際立つ傾向がありましたプロダクト、モデル、またはメトリックの所有権を、データ処理機能がはたすべきジョブを理解するチームに最適に配置し、機能を共有して、複数のコンテキストで再利用できるようにするものでした。それとは対照的に、次のトレンドである ELT(抽出、読み込み、変換) は、中央集約化を促し、特に、データ ウェアハウスやデータ レイクであらゆる変換ロジックを実行するものです。
モダン データ スタックは、従来のデータ プラットフォームのアンバンドリングと表現されることがあります。つまり、変換、オーケストレーション、検出、ガバナンスなど個別の機能に分解し、その後再構築して、従来のモノリシックな データ プラットフォームよりも優れた包括的なデータ エクスペリエンスを提供できるのです。逆説的ですが、このように機能を別々のツールに分割したことで、データ ウェアハウスとデータ レイクという 2 つのデータ環境基盤の重要性がより高まりました。組織で使用されているツールの特定の組み合わせには関係なく、運用システムから抽出されたすべてのデータは、必ずこれらのいずれかに転送されます。ELT は、データ ウェアハウスやデータ レイクに依存してデータ変換機能を実現しているため、これら 2 つのテクノロジーの中心的な重要性をさらに強固なものにしています。
ELT は、データが送信先（データ レイクまたはデータ ウェアハウス) にロードされるまでパイプライン プロセスの変換ステージを延期し、モダンなクラウドベースのデータ ウェアハウスおよびデータ レイク テクノロジーのスケーラビリティとパフォーマンスの向上を活用して、その場でデータ変換します。そのため、データ チームがユース ケースやワークロードの適用を考慮することなく、ソース システムからデータを推測で抽出して、そのままの形でターゲットに読み込ませることが可能になります。この点で、ELT はよりアジャイルなデータ パイプライン プロセスをサポートしているため、チームは、ダウンストリームの消費者のニーズを深く理解した時点で、生データの上に整形式のモデルを構築し、進化させることができます。これは、急速に変化し、レスポンシブでデータドリブンな組織を構築するための望むべき第一歩となります。
しかし、このアプローチには欠点もあります。データ収集の動機となるビジネス上意義のある目標がないと、当事者意識と責任感が薄まってしまうという点です。目的やデータ系統があいまいな複数の生データのテーブルが、整形されて意図的にモデル化されたスキーマと隣り合わせに並んでいるということは、この場合、スキーマ間の境界があいまいになり、定義が不十分なテーブル間の依存関係が偶発的に発生し、明確なドキュメントやガバナンスがなければ、データの品質と生産性が損なわれます。
さらに、もう 1 つ欠点があります。ELT は、データへのアクセス方法を事前に把握していなくても、ソース システムからデータを抽出できるという利点がありますが、通常はバッチ指向のプロセスです。生の抽出データから洗練されたデータ製品を導き出す複雑なパイプラインは、大きな依存関係グラフを形成する可能性があります。このように多数のプロセスが連鎖している場合、変更内容がソース システムから消耗品に反映するまでに時間がかかることがあります。どの段階でも遅延が発生すると、パイプラインの残りの部分が停止します。長い待ち時間、古いデータ、不透明なデータ系列は、組織が派生したデータ製品から実際に価値を引き出すのを阻害します。
リバース ETL
ELT が、データ ウェアハウスまたはデータ レイクの役割を、すべてのエンタープライズ データの最終的な送信先として集約するのであれば、リバース ETL もまた、最近のトレンドの 1 つで、この集中化の兆しとして考えられます。リバース ETL を使用すると、データ レイクやデータ ウェアハウスに統合されたデータ、およびそのデータのその後の分析結果を、運用システムと再び共有できます。リバース ETL が存在するのは、データ ウェアハウスがすべてのデータ統合の唯一の場所であるためです。適度に複雑な環境にある運用システムでは、アプリケーションの目標を達成するために、必ず他のシステムに属するデータを使用する必要があります。そのため、この共有データをデータ ウェアハウスに接続されたプロセスから取得するか、そのプロセスでデータを提供させる必要があります。リバース ETL は、運用システムとデータや分析を共有するという、純粋に重要なニーズを表面化させたものですが、このニーズを満たす、よりシンプルな方法は本当にあるのでしょうか ? この疑問については、すぐに触れることにします。
優れたパイプラインに向けて
いかがでしょうか ? 新しいツールや手法は、過去 20 年間のソフトウェア開発やデリバリー手法の改革に触発されて、データマネジメントで潮流の変化を起こしています。しかし、古い習慣を頑なに守ったり、新しいアプローチの成功を台無しにするような逆流も存在します。
一方、分散型アーキテクチャへの移行も進んでいます。このアーキテクチャは、消費者のニーズに対応するチームに、データ処理機能の明確なオーナーシップを最適に割り当てるものです。これらのアーキテクチャでは、データに最も近いチームに責任を分担して委譲することで、信頼できるデータの共有と再利用を可能にし、重複して不適切、そしてアドホックなデータセットの拡散を低減します。当社では、懸念事項を分類し、最新の開発者ツールチェーンを用いて変換ロジックの作成、テスト、およびバージョン管理をサポートするツールを提供しています。これらのツールを使用することで、データ チームは、エンジニアが組織内の他の場所でソフトウェアを正常にデリバリーするために使用するのと同様にアジャイルかつDevOps 開発プラクティスを採用できます。また、SQL などの宣言型言語を使用して、データがどこから来て、どこに行き、変換でどのようになるかを記述できます。宣言型言語を使用すると、データ チームは、データの移動や変換を調整するために脆弱な命令文を記述するよりも、優れたデータ結果を実現するために、より多くの時間を生産的に費やすことができます。
しかしその一方で、ビジネス上の価値を認識できないデータの推測的なエクスポートによってデータ ウェアハウスやデータ レイクが過負荷になったり、データ ウェアハウスやデータ レイクだけがデータ統合とデータ共有を担うものとして扱う傾向があります。そのため、誰が何を所有しているのか、どのデータが信頼できるのかを把握することが困難になり、多くの余分な連携作業が必要となって運用システムの統合を複雑にしています。
ただし、ここには何か足りないものがあります。
ストリーム処理
それがストリーム処理です。ストリーミング データを収集して顧客と積極的に関わり、リスクや市場の状況の変化をリアルタイムで管理する企業が増えている中、ストリーミング データ プラットフォームとストリーム処理機能に対するニーズは高まっています。既存のバッチ指向データ処理プラットフォームに、ストリームからの消費機能やストリームへの公開機能を追加して、AWS Glue のストリーミング ETL ジョブのようなマイクロバッチベースのツールを使用してストリーミング イベントを処理するか、Meroxa、Decodable、DataCater などの新規参入企業 (ストリーミング データを扱うためにゼロから構築したデータ処理プラットフォーム) のいずれにしても、モダン データ スタックは、リアルタイム データ パイプラインに対する需要の高まりに対応して急速に拡大しつつあります。
ストリーム処理は、モダンデータ処理の基本機能です。これは、上記の優れたプラクティスとうまく連携し、ELT やリバース ETL によって対処されるニーズに対する代替手段も備えています。つまり、新しい要件の出現に応じてデータを徐々に適応させて調整し、データと分析結果を運用システムと共有します。
ストリームは、ビジネス ファクト (組織内で行われたあらゆる作業) の、永続的で忠実性の高いリポジトリを提供します。このストリームは、低レイテンシーパブリッシュ / サブスクライブ コンジットとして機能するため、システムは実環境で発生したイベントに対応できます。つまり、定期的なスナップショットから派生したデータのないデータセットを基に構築された、古い結果や作業はもうありません。重要なことは、ストリームはデフォルトで時間バージョン化したデータを作成するため、消費者は過去の任意の期間の状態を再構築でき、タイムトラベルしてデータを再処理し、新たな計算値や修正した計算値を、以前の履歴に適用できるようになります。この点で、ストリームの忠実度の高い側面は重要です。データ ウェアハウスとデータ レイクのデータセットには、タイムスタンプ付きのファクトや、過去の履歴変更を反映し徐々に変化するディメンションが含まれていることがよくありますが、レコードの忠実度 (データセット外で発生したすべての変更をキャプチャしデータセットに格納する度合) は、アプリケーション固有の設計と実装の選択に依存します。これに対してストリームは、ワークロードやユース ケースに関係なく、すべてのイベントを保持することができます。
プロダクトとしてのデータのコンテキストという点では、ストリームは、データ所有者がデータ ウェアハウスやデータ レイクにデータを事前に送信することなく、適切にモデル化されたデータをクライアントや消費者と共有するための強力なメカニズムを提供します。プロデューサーは、担当するシステムで意味のある変更が発生するたびに、イベントを発行します。データは 1 度公開されますが、運用目的と分析目的の両方で、さまざまなサブスクライバーが何度も使用できます。このアプローチでは、分散化と再利用の両方がサポートされているため、ソース システムの所有者は、データを複数のコンテキストで再利用できるようなアフォーダンスを作成する必要があります。
サブスクライブするアプリケーションは、受信したイベントに基づいて内部ステートを更新したり、追加の動作をトリガーしたりします。最も単純なシナリオでは、ストリームは、直接的なデータ統合を行います。ソース システムは変更データ取得 (CDC) メカニズムを用いて変更を公開し、それを使用してMySQL や PostgreSQL などの運用データベースや、検索、およびElasticsearch など可観測性（オブザーバビリティ）アプリケーション、データ ウェアハウスやデータ レイクなどの分析対象を更新できます。
さらに複雑なソリューションでは、ストリーム処理を使用して 1 つ以上のソース ストリームからデータを取得し、移動中のデータで計算と変換を継続的に行い、結果が発生したときにターゲット ストリームに発行します。川が堰を越えて流れる場所に現れる定常パターンのように、ストリーム処理では、データの流れの関数として、常に変化する最新の結果を提供します。ここでのトレンドは、以前に説明した宣言型変換モデルと同様に、SQL を使用することです。ksqlDB, Materialize および Snowflake のストリーム処理はすべて SQL を使用して、データがどこから来て、どこに行き、その過程でどのように見えるべきかを記述します。これらのツールを使用することで、チームはデータの処理中にデータをエンリッチ化して変換し、メトリック、複数のソースに対する非正規化ビュー、集計などの新製品向けの派生ストリームを作成できます。
データ フロー ネットワーク
こうして現れたのが、リアルタイム データのネットワークです。現在のデータ処理機能のパフォーマンスが低いと感じている場合、また一元化されたデータ ウェアハウスやデータ レイクに向けて複数のサイロ化されたパイプラインで作業することに不満がある場合は、その代わりに、ストリーミング、分散型、そして宣言型のデータ フロー ネットワークを想像してみてください。これで、適切な人々が、適切な作業を、適切なタイミングでできるようになり、共有、コラボレーション、進化、再利用が促進されます。
このネットワークは、変換ロジックを連鎖させて、システム内を流れるストリーミング データをすぐに処理します。このようなデータ フローでは、1 つの処理が終了するのを待ってから次の処理を開始する必要はありません。つまり、消費者は最初のレコードがネットワークに入るとすぐに、関心のあるストリーム製品から結果が取得できるようになります。新しいユース ケースでは、既存のストリームを利用して新しいストリームを導入することで、ネットワークを拡張します。
これは、データ ウェアハウスやデータ レイクを排除するものではありません。むしろ従来のパイプラインの責任を、上記のプラクティスに沿って再割り当てし、タイムリーで再生可能、そしてコンポーザブルで再利用可能なパイプラインの機能を明確に所有することで、運用システムの低レイテンシー統合、分析または機械学習ワークロードなど、データ フローに応じて価値を生み出すものです。
モダン データ フロー
もちろん、これは勝手にできあがるものではありません。マイクロサービス アーキテクチャが、DevOps の考え方、反復型かつインクリメンタル型開発、あらゆるところでの自動化、継続的デリバリーなど、新しい開発とデリバリーのプラクティスを採用して初めて成功するように、データ フロー ネットワークの進化には、ガバナンスを最重要概念として、統制のとれた開発者指向のアプローチである必要があります。分散化によってデータ フロー ネットワークのストリームの再利用性が高まれば、ガバナンスによって、分散化に起因する複雑な分散環境の管理リスクと運用オーバーヘッドを低減させることができます。プラットフォームレベルのガバナンスにより、ネットワークが確実に保護され、分散型ドメイン指向チームによる効果的な運用や、組織全体のコラボレーションと信頼の促進が実現できます。
当社では、優れたパイプラインの構築のためのこの全体的なアプローチを、モダン データ フローと呼んでいます。このモダンデータ フローは、過去数年間に見られたトレンドから導き出された、次の 5 つの原則に要約できます。
- ストリーミング :
ストリームとストリーミング プラットフォームを使用して、データ忠実度の低い定期的なスナップショットを外部リポジトリにプッシュするのではなく、リアルタイムで忠実度の高いイベントレベルの再利用可能なデータを、データ フロー ネットワークに保存して維持します。 - 分散化 :
共有と再利用を促進するために、懸念事項を分類し、その時点でデータに最も近いチームにパイプラインの責任を割り当てます。集中管理されたデータ ウェアハウスやデータ レイクにデータを統合するのではなく、複数のコンテキストで共有して適用できる、再利用可能なデータをカプセル化するストリームのネットワークを維持します。ドメインにとらわれない一元化されたデータ チームに作業を集中させるのではなく、ビジネス分野の専門家とデータ処理担当者のチームをネットワークのストリームに配置し、その時点でデータに最も近いチーム間でデータを交換します。 - 宣言型 :
SQL などの宣言型言語を使用して、目的と実装を結びつける命令型イディオムを使用するのではなく、データ フローの実施内容 (データがどこから来て、どこに行き、その過程でどのように見えるべきなのか) を表現力豊かに、簡単に表現を進化させます。意図と実装を結びつける命令型イディオムを使うのとは対照的です。 - 開発者指向 :
データ フローを個別のコンポーネントに分解できるツールとフレームワークを使用します。デプロイ後にのみテストできる独自のパイプライン アーティファクトを提供するモノリシックなクローズド プラットフォームではなく、独自に開発、テスト、およびバージョン管理できるオープン フォーマットで構成されます。テストを使用して、個別のデータ フロー コンポーネントの開発を進め、ドキュメントを生成して、実行時にデータの不変条件をアサートします。 - 管理型 :
プラットフォーム全体で自動化されたポリシー、継続的なオブザーバビリティ機能、直感的な検索、検出、およびデータ系列機能を提供して、プラットフォームの安全性、効率性、およびユーザビリティを向上させます。そのため、手動で帯域外ガバナンス ストラクチャを使用したり、複数のパイプライン コンポーネント間でサイロ化したセキュリティや可視化機能を統合したりする必要はありません。
まとめ
パイプラインは、データドリブンな組織が機能するために不可欠な連携部分です。モダン データ フローは、より優れたパイプラインの構築に役立つ 5 つの原則の名称です。これらの原則は、パイプライン開発者がソリューションを評価する際の最終目標を要約したもので、重要なものです。モダン データ フローを構築することは、組織全体のデータ要件だけでなく、データ エコシステム全体のコミュニケーション、アクセシビリティ、デリバリー、および運用ニーズにも対応できるような拡張手法を用いて、パイプラインを構築することを意味しています。このメリットとユースケースの詳細については、『ストリーミング データ パイプライン』をご覧ください。
原文：Modern Data Flow: A Better Way of Building Data Pipelines
JUL 28, 2022
