(翻訳) データエンジニアリングの未来
訳者まえがき
原著者の Chris Riccomini の許可を得て以下の記事を翻訳・公開しました。
下記より記事翻訳本文です。
データエンジニアリングの未来
私は最近、近頃のデータエンジニアリングがこれまで来た道について、また、この分野の仕事の将来について考えてきました。考えのほとんどは、私たちのチームが WePay で実践していることを背景にしています。その一方、以下に述べる考えは普遍的で、共有する価値があるものと思っています。
データエンジニアリングの仕事は、組織におけるデータの移動と処理を支援することです。これには、一般的に、データパイプラインとデータウェアハウスという2つの異なるシステムが必要です。データパイプラインはデータの移動を担当し、データウェアハウスはデータの処理を担当します。これは、やや過度に単純化しています。バッチ処理とストリーム処理では、抽出（extraction）とロード（loading）の間で変換（transformation）を行うことにより、パイプライン自体で処理を行うことはできます。近年の データウェアハウスには、多くのストレージおよび処理システム（Flink、Spark、Presto、Hive、BigQuery、Redshiftなど）と、データカタログ、ジョブスケジューラなどの補助システムが含まれています。しかし、それでもこのパラダイムは意味のあるものと思います。
業界では、これらのシステムの構築および管理方法の変革が進んでいます。特に、今後数年間で変化が予期される、4つの分野があります。
- 適時性（Timeliness）: バッチからリアルタイムへ
- 接続性（Connectivity）: one:one、特注のインテグレーションから many:many へ
- 集中化（Centralization）: 集中管理からセルフサービスツールへ
- 自動化（Automation）: 手動管理から自動化ツールへ
バッチからリアルタイムへ
データパイプラインとデータ処理の両方は、これまではバッチベースでした。データはバッチETLスナップショットでシステム間転送が行われ、ジョブスケジューラ（Airflow、Oozie、Azkaban、Luigi）によって定期的に処理されていました。
最近は、リアルタイムデータパイプラインとリアルタイムデータ処理システムへ移行しつつあります。 Debezium などの変更データキャプチャシステムと、Kafkaの堅牢なコネクタエコシステムにより、リアルタイムのデータパイプラインが可能になりました。ストリーム処理は、過去5年間でルネッサンスを迎え、リアルタイムのデータ処理システムは現在追いきれないほど多くなっています。これら要因により、つまり、入力（抽出）、処理（変換）、および出力（読み込み）がすべてリアルタイムで行われることを意味します。
現在のトレードオフは、コストと複雑さのようです。企業がデータウェアハウスを立ち上げており、4〜6週間ですぐに効果が必要な場合、リアルタイムパイプラインをセットアップするのは大きな負担になります。バッチの作成と実行は依然として簡単です。リアルタイム領域のツールが成熟し続け、クラウドホスティングが成長するにつれて、これは今後数年間で変わると私は予想しています。
接続性
上流のデータソースをデータウェアハウスに接続することは、システム間の1to1接続ごとにまったく新しい特注のインテグレーションを追加することを意味していました。Jay Krepsの重要な投稿、The Log: What every software engineer should know about real-time data’s unifying abstraction は、これをよく説明しています。
複雑なデータパイプライン
この投稿は、データ統合の将来についても詳しく説明しています。これは2013年に書かれたもので、そこで予想され提案されているものの多くが現在に実を結び始めています。 Confluent、Kafka Connect、およびコネクタエコシステムが作られたことで、既存の Kafka データパイプラインに接続できる実行可能なコネクタが数多く生まれました。
このアーキテクチャのアプローチは定着していくでしょう。入力を出力から、またそれらを変換から切り離することは、データパイプラインにメトカーフの法則を効き始めることを意味します。そこでは、新しいシステムをパイプラインに追加することは、以前よりも安価でより価値があります。
上記のパラグラフはかなり Kafka 中心主義的であるとは思いますが、このアプローチにおいてはリアルタイムは必ずしも必要ありません（そうなっていくとは思いますが）。たとえば Airflow では、現在 GoogleCloudStorageHook、BigQueryHook、1to1のオペレーターであるGoogleCloudStorageToBigQueryOperator があります。出力から入力を完全に解きほぐし、一般的な形式のステージング領域が存在すると、バッチベースのETLの改善にも大いに役立ちます。
このパターンにより、よりきめ細かいデータシステムを採用することもできます。パイプラインに新しいシステムを接続するのが安価になると、エコシステムに新しい特殊なシステムを追加する価値がそのコストを上回ります。その結果、グラフデータベース、リアルタイムOLAPシステム、検索インデックスなど、ニッチなデータ処理システムの使用が増えることが期待されます。また、新しいシステムをパイプラインに接続し、それがニーズに合わないことを確認することが以前よりもはるかに安価になるため、このパターンはより多くの実験を可能にします（これは今年の初めの記事ですでに取り上げたテーマです, Kafka is your escape hatch）。
クラウドもまた、接続性の一連の作業に興味深い妙案を加えてくれています。データ統合の作業を、AWSコンソールのチェックボックスにするという夢はまだ実現していません。各クラウドプロバイダーで、すべてのシステムはすぐに完全に統合されることはないでしょう。ポイントアンドクリックUIでのクラウドプロバイダー間を完全統合するというアイディアは、さらに遠そうです。最後に、クラウドおよび非クラウド（またはサードパーティがホストする）システムを統合するには、依然として作業が必要です。
これらの理由から、Stitchなどのクラウドベースのサードパーティソリューションは引き続き価値があると思います。また、これは、上記で説明したリアルタイムのKafkaアーキテクチャが、構築して運用する余裕があるとすれば、最も成熟したソリューションになることを意味します。
自動化と非中央集権化
リストの最後の2つの項目、自動化と集中化は、かなり密接に関連しています。ほとんどの組織には、データパイプラインとデータウェアハウスを管理する単一のデータエンジニアリングチームやデータウェアハウジングチームがいます。これらのチームにリクエストが届くと、次の2つの基準でリクエストを評価する必要があります。
- 技術的に可能か: What can we do (technical)
- ポリシー的に可能か: What may we do (policy)
私の経験では、中央集権化されたチームは通常、ある程度の自動化を行いますが、技術的な自動化に主に焦点を合わせます。これは、エンジニアリングチームの操舵室にあるため、当然です。この種の作業は、通常、運用上のトイルを自動化することを意味します。新しいコネクタの追加、監視またはデータ品質チェックの設定、新しいデータベースまたはテーブルの作成、許可の付与などの作業です。
ただし、データエンジニアリングがまだ自動化していないもうひとつのタイプのトイルがあります。ポリシーのトイルです。この種の面倒な作業には、誰がどのデータにアクセスできるか、どのくらいの期間データを保持するか、どのデータシステムにどのような機密データを格納することを許すか、どの地域のデータが存在するかについての決定が含まれます。通常、データエンジニアリングは、これらの質問に対する回答を最終的に決定するチームではありませんが、回答を見つける際に連絡役またはドライバーとして行動しなければならないことがよくあります。これは通常、セキュリティ、コンプライアンス、法律など、組織の他のチームを介して要望をナビゲートすることを意味します。
GDPRやCCPAなどの規制により、すでにこの種の作業は重要です。従来のソフトウェア企業の枠を超え、ヘルスや金融などの分野において技術の継続的な拡大に対する政府の規制を追加する場合（Why Software Is Eating the World 参照）、ポリシーのトイルを自動化することの重要性が増すことは避けられないでしょう。
ポリシーの自動化には、成熟度の低いデータエコシステムでは通常無視されている分野に焦点を当てる必要があります。 LyftのAmundsen、Apache Ranger、Googleのデータカタログなどのツールを採用する必要があるでしょう。監査、DLP、機密データの検出、保持期間の強制、アクセス制御管理などのポリシーの実施は、すべて完全に自動化する必要があります。
自動化が技術分野とポリシー分野の両方で成熟するにつれて、必然的に次のような質問が生まれます。なぜ、単一のチームで管理する必要があるのでしょう？ ツールがポリシーガイドラインを実行し、データパイプラインを自動化するならば、組織のそれぞれのチームがデータパイプラインとデータウェアハウスを直接管理できるようにするのはどうでしょうか？
データパイプラインにおいては非中央集権化とは、技術的およびポリシーガイドラインに（自動的に実施される）準拠している場合、チームが既存のデータパイプラインに接続することを決定できることを意味します。データウェアハウスにおいては、チームは必要に応じてデータベース、データセット、データマート、およびデータレイクを作成できます（一部は既に存在しています）。これにより、多くの複雑性、混乱、および重複が発生します。そのため、ツール（上記に挙げたツールなど）が非中央集権化にとって非常に重要な前提条件となります。
非中央集権化のトピックは、Zhamak Dehghaniの投稿 How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh で詳細に説明されています。ぜひお読みください。より複雑なデータエコシステムを管理するために認知的負荷が生まれてしまうため、唯一のスケーラブルで効率的な方法は、自動化と非中央集権化だと思います。これは、ある意味では、アプリケーション層で過去10年間に見られたCI / CDおよびモノリスからマイクロサービスへの移行のように見えます。
結び
これらを踏まえて、私は楽観的です。まだやるべきことがあり、たくさんの機会があります。これらの要求を満たすために、組織内でデータエンジニアリングが拡大することを期待しています。オープンソースコミュニティは拡大を続け、新しいプロジェクトとスタートアップが生まれます。これらのすべてが、組織全体の大幅な効率向上につながり、より厳密なデータ管理の実践につながるはずです。
