コンテンツに移動
データ分析

第一原則に基づいてデータ エンジニアリング ドリブン組織を構築する

2021年10月6日
Google Cloud Japan Team

※この投稿は米国時間 2021 年 9 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

論文『What type of data processing organisation』(データ処理組織のタイプ)では、組織の主な構成員がデータ アナリスト、データ エンジニア、データ サイエンティストのいずれであってもデータ文化の構築は可能であることについて考察しました。しかし、データドリブンなイノベーターになるための道のりと技術は異なります。成功するには、企業文化に即した方法で適切な技術を実装する必要があります。このブログでは、データ エンジニアリング ドリブン組織について詳しく見ていき、第一原則に基づいたその構築方法を説明します。

1 つとして同じ組織はありません。セールス、エンジニアリング、マーケティングなど、どの企業にも似たような職務はありますが、ビジネス上の全般的な意思決定に及ぼす影響は職務によって異なります。エンジニアリング ドリブン寄りの企業もあれば、セールス ドリブンな企業やマーケティング ドリブンな企業もあります。実際には、すべての企業でこれらのすべての職務が混在しています。同様に、データ戦略についても、データ アナリスト重視型やデータ エンジニアリング重視型があり得ます。文化とは、ビジネス要件、組織文化、組織内のスキルといった複数の要素の組み合わせです。

従来のエンジニアリング重視型組織が生じた背景には、主にテクノロジー ドリブンなデジタル化がありました。こうした組織は、独自のフレームワークを構築するかプログラミング フレームワークを使用して、再現性のあるデータ パイプラインを構築しました。その一部は、データ受信方法、データ受信の形、データ到着速度に基づいています。データのタイプによっては、データ分析をより重視し、データ エンジニアリングはさほど重視しないということもあり得ます。従来の抽出、変換、読み込み(ETL)ではなく抽出、読み込み、変換(ELT)のアプローチを適用できれば、データ分析を重視でき、広範なデータ エンジニアリング能力が不要となる可能性があります。たとえば、データをデータ ウェアハウスに直接読み込むことができれば、データ アナリストがデータ エンジニアリング作業やデータへの変換の適用も行えるようになります。

しかし、これは頻繁に見られる事例ではありません。たとえば、乱雑なデータ、一貫性のないデータ、大量のデータ、旧式のファイル形式でエンコードされたデータ、旧式のデータベースまたはシステムの一部としてエンコードされたデータは、データ アナリストにとって実用的であるとはあまり考えられません。

あるいは、データをストリーミングで処理し、複雑なイベント処理を適用して有益な知見をほぼリアルタイムで取得する必要が生じる場合もあるでしょう。データの価値は、時間の経過とともに指数関数的に低下していきます。バッチモードでデータを翌日までに処理することは、ほとんどの企業において可能です。しかし、そのような知識をデータ生成後 1 秒で取得している企業は、おそらくそれほど多くありません。

このような状況では、乱雑性と急速な変化のいずれか(またはその両方)を有する混合データから隠れた知見を掘り起こす能力が必要です。また、ほぼ同じぐらい重要なものとして、その能力を発揮するための適切なツールとシステムも必要です。

では、適切なツールとは何でしょうか。クラウドには、そのような複雑な状況で必要とされるデータ ワークロードに適したスケーラビリティと柔軟性があります。データチームがビジネスにインパクトを与えるために必要なリソースを懇願しなくてはならなかった時代は、はるか昔のことになりました。データ処理システムはもはや希少ではなくなり、そのような希少性を人為的に生成するデータ戦略も必要ありません。

この記事では、Google Cloud を活用して、データチームによるバッチまたはストリーミングでの複雑なデータ処理を可能にする方法について説明します。それにより、データ エンジニアリングおよびサイエンス チームは、入力データ生成後に(数秒で)インパクトを与えることができます。

データ エンジニアリング ドリブン組織

データ変換ニーズが非常に複雑である場合、企業のデータ戦略の中心的役割はデータ エンジニアが担います。この場合、その企業はデータ エンジニアリング ドリブン組織になります。このタイプの組織では、ビジネスデータ オーナー、データ エンジニア、データ利用者という 3 つの層でデータ アーキテクチャが編成されます。

データ エンジニアは、データオーナーとデータ利用者の間の交点に存在し、次に示す明確な責務を負います。

  • データを転送し、拡充しながら分析システムと運用システムを統合する(リアルタイム ユースケースの場合と同様)

  • ビジネス ユニットからの乱雑なデータを解析して、文書化されたメタデータを伴う有意義かつクリーンなデータに変換する

  • DataOps(ビジネスの職務上の知識と、データ ライフサイクルに適用されるソフトウェア エンジニアリング手法)を適用する

  • データを分析または利用するモデルおよびその他アーティファクトのデプロイを行う

https://storage.googleapis.com/gweb-cloudblog-publish/images/Data_Engineering_2.max-1700x1700.jpg

ビジネスデータ オーナーは、複数の職能にまたがるドメイン指向チームです。これらのチームは、ビジネスを詳細に把握しており、データ アーキテクチャにフィードするデータのソースとなります。このようなビジネス ユニットが、データに特化した役割(データ アナリスト、データ エンジニア、データ サイエンティストなど)も担い、その他の層とのインターフェースとして機能する場合もあります。たとえば、これらのチームがビジネスデータ オーナーを策定することがあります。これは、ユニット生成データ関連のあらゆることに関するビジネス ユニットの連絡窓口になります。

アーキテクチャのもう一方の端にいるのが、データ利用者です。こちらも複数の職能にまたがっていますが、その重点は、アーキテクチャ内で得られる各種データから知見を抽出することに置かれています。その典型として挙げられるのが、データ サイエンス チーム、データ アナリスト、ビジネス インテリジェンス チームなどです。これらのグループが異なるビジネス ユニットからのデータを組み合わせてアーティファクト(機械学習モデル、インタラクティブなダッシュボード、レポートなど)を生成することもあります。デプロイに関しては、データの整合性と信頼性を確保するためにデータ エンジニアリング チームの支援が必要です。

これらの交差点の中心にいるのがデータ エンジニアリング チームです。データ エンジニアは、さまざまなビジネス ユニットにより生成され必要とされるデータを確実にアーキテクチャに取り込む責任を負っています。この仕事における 2 つの必須要素は、職務上の知識と、データ エンジニアリング / ソフトウェア開発スキルです。これはしばしば DataOps という造語(過去数十年の間に開発された DevOps 手法をなぞってデータ エンジニアリング業務に当てはめた言葉)で表されます。

データ エンジニアには別の責務もあります。データ利用者によって生成されるアーティファクトのデプロイを支援することです。データ利用者は一般に、アーティファクトのデプロイを単独で担うための深い技術スキルや知識を備えていません。これは、非常に洗練されたデータ サイエンス チームにも当てはまります。そのため、データ エンジニアはさらに、機械学習とビジネス インテリジェンス プラットフォームの知識も身に付ける必要があります。誤解を防ぐために補足すると、データ エンジニアには機械学習エンジニアになることが期待される、というわけではありません。データ エンジニアは、モデルの第 1 層に送られるデータ(入力)が正しいことを確認するために、ML を理解する必要があるのです。また彼らは、その第 1 層データを推論パスに送る際にも鍵となります。スケーリングや HA などにまつわるデータ エンジニアリング スキルの発揮が真に必要とされるためです。

各種ビジネス ユニットからの乱雑なデータを解析して変換する責務あるいはリアルタイムで取り込む責務をデータ エンジニアが担うことによって、データ利用者は価値創出に集中できるようになります。データ サイエンスおよびその他のタイプのデータ利用者は、データ エンコーディング、大規模ファイル、旧式システム、ストリーミング用の複雑なメッセージ キュー構成とは関わりません。スキルの高いデータ エンジニアリング チームにそのような知識を集中させるメリットは明白ですが、それにもかかわらず、それ以外のチーム(ビジネス ユニットおよび利用者)がデータ エンジニアを擁して他チームとのインターフェースとして機能させる場合もあります。最近では、ビジネス ユニット(データ プロダクト オーナー)、データ エンジニア、データ サイエンティストなどの職務のメンバーで構成されたチームも見受けられます。受信データから、ビジネスに影響するデータドリブンの意思決定まで、データ ストリーム全般に対する自律性と全面的責任を持った完全なチームが、効果的に構築されます。

リファレンス アーキテクチャ - サーバーレス

データ エンジニアリング チームには、多種多様なスキルが求められます。データ パイプラインを実行するインフラストラクチャのメンテナンスまで期待するのは、チームの負担増大につながるため避けるべきです。データ エンジニアリング チームは、ソリューションに必要なメモリ量やコア数といったことよりも、データのクレンジング、変換、拡充、準備の方法に集中する必要があります。

ここで紹介するリファレンス アーキテクチャは、次の原則に基づいています。

  • サーバーレス NoOps テクノロジー

  • ストリーミング対応により知見取得時間を短縮

Google Cloud で利用可能な各種プロダクトをベースとするオプションをいくつか紹介します。

  • Dataflow。Google Cloud での組み込みストリーミング分析プラットフォーム。

  • Dataproc。Google Cloud における Hadoop および Spark 用マネージド プラットフォーム。

  • Data Fusion。データ パイプラインを作成し実行するためのコードレス環境。

これらの原則を掘り下げてみましょう。

サーバーレス テクノロジーを使用することで、データ エンジニアリング チームのメンテナンスの負担がなくなり、複雑なジョブや大規模なジョブを実行するために必要な柔軟性とスケーラビリティが提供されます。たとえば、小売店が金曜特売開催中のトラフィック急増に向けた計画を立てる際には、スケーラビリティが不可欠な要素となります。小売店は、サーバーレス ソリューションを使用することで、特売日のパフォーマンスについて考察できます。当日生成される大量のデータの処理に必要なリソースを心配する必要は、もうありません。

チームが開発するパイプラインのタイプの関係上、チームはデータ パイプラインを完全に制御し、独自コードを記述する必要があります。これは、バッチ パイプラインとストリーミング パイプラインのどちらにも当てはまります。バッチでは、解析要件が複雑になることがあり、既製のソリューションでは役に立ちません。ストリーミングでは、プラットフォームの機能をフル活用したい場合、レイテンシ改善と引き換えに複雑さを人為的に簡略化することなく、必要とされる複雑なビジネス ロジックをすべて実装する必要があります。非常に複雑なビジネス ロジックで低レイテンシを実現するパイプラインを開発することは可能です。この場合も、第一原則に基づいてコードの記述を開始する必要があります。

ただし、コードを書く必要があるからといって、既存のコードを書き直す必要性を示唆しているわけではありません。パターン、スニペット、類似例からのコードを、おそらく多くの入力 / 出力システム向けに再利用できます。さらに、データ エンジニアリング チームによって開発された論理パイプラインは、物理パイプラインへのマッピングを必ずしも必要としません。論理の一部は、Dataflow テンプレートなどのテクノロジーを使用して簡単に再利用できます。また、これらのテンプレートを他のカスタム開発パイプラインとのオーケストレーションで使用することが可能です。これにより、両者(再利用と書き直し)の長所を生かしながら、貴重な時間を節約し、空いた時間は一般的な I/O タスクではなく重要性の高いコードに費やすことができます。紹介したリファレンス アーキテクチャには、重要な機能がもう 1 つあります。既存のバッチ パイプラインをストリーミングに変換できる機能です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Data_Engineering_1.max-1300x1300.jpg

取り込みレイヤはリアルタイム用の Pub/Sub とバッチ用の Cloud Storage で構成されており、インフラストラクチャの事前割り当ては必要ありません。入力ワークロードに応じて自動的にスケールアップできるので、幅広い事例に Pub/Sub と Cloud Storage の両方を使用できます。

ここで提案するアーキテクチャは、データが取り込まれた後、従来の抽出、変換、読み込み(ETL)という 3 段階を踏みます。一部のファイルタイプでは、(ELT アプローチによる)BigQuery への直接取り込みも可能です。

変換レイヤでは、データ処理コンポーネントとして Dataflow を第一に推奨します。Dataflow では、SDK として Apache Beam が使用されます。Apache Beam の主な利点は、バッチ処理とストリーミング処理の統合モデルにあります。前述のように、入出力を適応させることにより、同じコードをバッチまたはストリーミングで実行するよう適応させることができます。たとえば、Cloud Storage のファイルからの入力を、Pub/Sub のトピックで公開されるメッセージに切り替えます。

このアーキテクチャでの Dataflow の代替手段の一つに、Dataproc があります。これは、Google Cloud におけるマネージド Hadoop および Spark クラスタ向けソリューションです。これらは主に、継承すべき Spark コードまたは Hadoop コードを大量に有するチームが Google Cloud に移行する場合などに使用されます。Dataproc では、クラウドへの直接パスが可能です。その際、すべてのパイプラインを確認する必要はありません。

最後に、Data Fusion というオプションを紹介します。これは、ドラッグ&ドロップ インターフェースを使用してデータ パイプラインを作成するためのコードレス環境です。Data Fusion では実際に Dataproc が Compute Engine として使用されます。そのため、Data Fusion の事例には、これまで述べてきたすべてのことも当てはまります。コードを書かずにデータ パイプラインを作成したい場合は Data Fusion が適しています。

要約すると、変換レイヤ向けに推奨されるコンポーネントは 3 つあります。

  • Dataflow。バッチ処理およびストリーミング処理向けの統合モデルを備えた、強力な多目的コンポーネント。バッチ処理からストリーミングに簡単に移行できる方法。

  • Dataproc。Hadoop または Spark 環境からの既存のコードを再利用したいチーム向け。

  • Data Fusion。コードを書きたくないチーム向け。

課題と機会

データ プラットフォームは複雑です。データだけでなくインフラストラクチャ維持にも責任を負わせると、貴重なスキルと才能を浪費することになります。データチームがインフラストラクチャの管理に終始し、データ分析に専念できないという話も、よく聞かれます。この記事で紹介したアーキテクチャでは、データ エンジニアリング チームはインフラストラクチャ割り当てやクラスタ調整の仕事から解放され、代わりにデータ処理パイプラインを介した価値実現に集中できるようになります。

データ エンジニアを得意分野に集中させるには、クラウドのフル活用が必要です。オンプレミス インストールからのリフト&シフト方式では、そのような柔軟性と解放は実現されません。サーバーレス テクノロジーを活用する必要があります。そのうえ、サーバーレスではデータ処理機能をニーズに合わせてスケーリングでき、どれほど大きなアクティビティ ピークにも対応できるというメリットもあります。

「サーバーレスをフルに活用するとプロバイダの選択肢が狭まるのだろうか」と、サーバーレス テクノロジーに対して疑念を抱く実務担当者もいます。実はこれは、アーキテクチャをプロバイダの上にセットアップすべきか決断する際に問うべき疑問なのです。

ここでデータ処理向けに紹介しているコンポーネントは、オープンソース テクノロジーをベースにしており、他のオープンソース同等コンポーネントと完全に相互運用可能です。Dataflow は Apache Beam を使用し、バッチとストリーミングを統合するだけでなく、幅広い互換性を持つランナーを提供します。場所を問わず他のどのランナーにもコードを適用できます。たとえば Apache Flink または Apache Spark などです。Dataproc は、フルマネージド Hadoop および Spark であり、このエコシステムの標準オープンソース コンポーネントをベースとしています。Data Fusion は、実際には、オープンソース プロジェクトである CDAP の Google Cloud バージョンです。

一方、サービスレイヤについては、BigQuery は標準 Ansi SQL をベースにしています。また、Bigtable および Google Kubernetes Enginee に関して言うと、Bigtable は API レベルで HBase との互換性があり、Kubernetes はオープンソース コンポーネントです。

要約すると、このアーキテクチャのようにオープンソースをベースとするコンポーネントの場合、サーバーレスによって選択肢が狭まることはありません。データ処理パイプラインの形でビジネス ロジックをエンコードするのに必要なスキルは、時間を超えて安定性を維持するエンジニアリングの原則に基づいています。Hadoop、Spark、または Dataflow もしくは UI ドリブンな ETL ツールを使用する場合も、同じ原則が当てはまります。加えて、今では、以前にはなかった低レイテンシ ストリーミングなどの新しい機能があります。データ エンジニアリングの基本原則を学んでいるデータ エンジニア チームであれば、これらの追加機能をすぐに活用できるでしょう。

Google が推奨するアーキテクチャでは、論理レベル(アプリケーションのコード)と実行場所であるインフラストラクチャとが分離されています。これにより、データ エンジニアは、最も得意な作業や最高の付加価値を提供できる分野に集中できます。Dataflow で、エンジニアを解放しビジネス価値の向上に専念できるようにして、ビジネスにインパクトを与えましょう。統合データ分析プラットフォームの構築に関する詳細については、最近公開された論文『Unified Data Analytics Platform』(統合データ分析プラットフォーム)と論文『Converging Architectures』(アーキテクチャの集約)をご覧ください。

-          データ アナリティクス実践リード Firat Tekiner 博士

-          戦略的クラウド エンジニア Israel Herraiz
投稿先