データパイプラインの進化

以前は、データを更新する必要がある場合、オペレーターが手作業でデータテーブルに入力していた。そのため、手作業による入力ミスやタイムラグが発生していた。これは主にバッチで行われ、ほとんどが毎日の作業であったため、イベントが発生してから報告されるまでにかなりのリードタイムがあった。意思決定者はこのタイムラグに耐えなければならず、多くの場合、古いデータに基づいて意思決定を行っていた。

現在では、リアルタイムの更新と洞察が一般的な要件となっている。データ・パイプラインの構築は、基本的にデータをあるレイヤー（トランザクション・ソースやイベント・ソース）からデータウェアハウスやデータレイクに移動させ、そこで洞察を得ることを目的としていた。

問題は、リアルタイムの洞察やその他の品質要件をサポートするために、従来のアーキテクチャや一般的に使用されているETLアプローチを使用して効率的であるかということです。それを探ってみよう！

データパイプラインは、あらゆる製品デジタル化プログラムにとって重要である。この10年の後半、私たちはデジタル・アーキテクチャとテクノロジーに大きな注目が集まっていることを目の当たりにした。マイクロサービスとコンテナ化の採用は、強力な成長軌道を描いており、この事実を立証しています。また、技術の進歩が適用されているが、それは従来の「OLTP」やコア・サービス／ビジネス・ロジックに限られている。

しかし、データ・パイプラインや "OLAP "側のパターンを調べると、話は少し違ってくる。コア・サービスの分野で見られるような技術進化への適応は限られている。一般的なデータパイプラインのほとんどは、従来のETLかELTLアーキテクチャを使って構築されている。これらは、業界で一般的なデファクト・アプローチである。これらは、目の前の大きな問題、つまり実用的な洞察を導き出すという問題を解決してくれるが、一定の限界も伴う。これらの課題をいくつか探ってみよう：

サイロ化したチーム：ETLプロセスには、データ抽出やデータ移行に関する専門知識やスキルが必要である。これは、技術チームが階層化されていたり、プロセスの技術的なニュアンスに対応できる構造になっていることを意味する。例ETLエンジニアは、多くの場合、導き出される洞察や、それがエンドユーザーによってどのように消費されるかに気づかない。

限られたマニフェスト： 実装チームは現在、設定された構造やパターンに、希望するあらゆるユースケースを当てはめようとしている。これは常に問題でも間違ったことでもないが、より非効率的な場合もある。例えば構造化されていないソースからどのように抽出し、中間永続スキーマのモデリングに対処するか？

待ち時間： データの抽出、変換、ロードの処理にかかる時間には、多くの場合ラグが発生する。この遅延は、データがバッチ処理されることや、中間結果を永続化するために必要な中間ロードステップに起因している可能性がある。ビジネス・シナリオによっては、このようなことは許されません。 例えばIoTサービスから発信されたデータストリームは保存され、後でスケジュールされた時間にバッチ処理される。これにより、データ生成からダッシュボード上の洞察が更新されるまでにタイムラグが生じる。

マイクロサービスやサービス・メッシュなど、一般的なソフトウェア・アーキテクチャの進歩を見るにつけ、同様の近代化が必要とされている。一つの重要なアプローチは、データ・メッシュの結果として複数のそのようなオブジェクトを構築するために貢献する中央集中型のデータ・パイプラインの代わりに、ドメインのためのデータ・パイプラインを分散させることである。データ・メッシュは、異なるアプローチを採用することで、これらの課題に対処することを目指している：

• 機能的特徴の提供で連携するチームまたはポッド
• データを製品として扱う（発見可能、自己完結、セキュア）
• メッシュを介したポリグロット・ストレージとコミュニケーションの促進

データ・メッシュに関する初読本はこちら。

データ・メッシュは様々な方法で実装できる。一つの効果的なパターンは、イベント駆動型アプローチとイベント・ストーミングを使用してデータ・プロダクトを形成することである。ドメインは1つ以上のデータ・プロダクトから構成される。これはまた、データを冗長化し、1つ以上のストアに永続化できることを意味する。これはポリグロット・ストレージ（Polyglot storage）と呼ばれる。最後に、これらのデータ製品は、各ドメインの要件に沿って設計されたメッシュAPIを介して消費される。

その他のアーキテクチャ・スタイルには、データレイク、データハブ、データ仮想化などがある。これらに関する簡単な比較はこちらを参照されたい。

その他に評価すべき点をいくつか挙げる：

• SQLのような標準的なインターフェースを使用して、いつでも簡単にデータにアクセスできるようにする。Snowflake、DBT、Materializeのような技術は、このようなリアルタイムの結合を可能にし、BIを可能にするだけでなく、パイプラインの低レベルの配管にも役立つ。
• データパイプラインを堅牢かつフォールトトレラントに設計する。
• 分散型の疎結合処理ユニットを活用し、SparkジョブやPythonモデルなどのポリグロット・テクノロジーをスケーラブルに使用する。
• データ仮想化を使用してボトルネックを軽減する。
• データパイプラインのパフォーマンスを追跡・評価するためのDataOpsの効果的な利用

最後に、免責事項で締めくくりたいと思います。この記事は、ETLに関連する現在のアーキテクチャを否定するものではない。実際、バッチジョブのような特定のユースケースでは、ETLは依然として採用すべき非常に良い選択肢です。ここでの意図は、様々な要件に基づいて、必要性を認識し、その必要性に適したアーキテクチャをさらに検討することです。この記事では、Data Meshのようないくつかのアーキテクチャと、それに関連する考慮すべき領域について見てきた。

この記事に関するコメント、フィードバック、質問などがありましたら、遠慮なくお寄せください。