データ分析

Google Cloud のデータ取り込みの基本方針

2021年11月4日

Google Cloud Japan Team

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

世界中の企業が、旧来のデータサイロをクラウドベースのエンタープライズデータウェアハウスに置き換えることで、事業部門間の共同作業が容易になり、データから以前は得られなかった知見が得られるようになるなどのメリットを享受しています。しかしながら、多様なデータソースから単一のデータウェアハウスにデータを取り込むには、そのためのパイプラインを開発する必要があります。従来は、このために組織内のデータエンジニアリングチームがさまざまなツールを調達し、導入してきました。しかし、これではすべてのパイプラインの管理とメンテナンスが非常に複雑になり、組織全体にこの作業を効果的に展開することがかなり難しくなります。データウェアハウスにデータを取り込むために、エンタープライズグレードのクラウドネイティブなパイプラインを開発すれば、こうした課題の多くを改善できます。ただし、間違った方法でパイプラインを開発すると、新たな課題が発生し、チームが時間とエネルギーを費やして対処しなければならなくなります。

さまざまなソースからクラウドデータウェアハウスにデータを複製するクラウドベースのデータ取り込みパイプラインの開発は、スタッフのリソースを大幅に投入する必要のある大規模な仕事となる場合があります。このような大規模なプロジェクトは、大変困難な印象を与え、どこからプロジェクトの計画に手を付ければよいのかを見極めるのは難しいといえます。そこで Google は、データパイプラインの計画を開始するための以下の基本方針を定めました。これらの基本方針は、お客様の取り組みに関するビジネス上の重要な質問に答え、ビジネス上および技術上のニーズに対応するデータパイプラインの構築を開始するのに役立てるためのものです。以下の各セクションでは、データパイプラインの基本方針と、パイプラインの開発を始めるにあたりチームが考慮すべき特定の要因について詳しく説明します。

基本方針 1: 目的を明確に定める

パイプライン開発のために考慮すべき最初の基本方針は、目的を明確に定めることです。これは大まかに言うと、技術チーム、規制要件またはポリシー上の要件、望まれる成果、事業目標、重要なスケジュール、稼働可能なチームとそのスキルセット、下流のデータユーザーなど、複数の視点から想定される要件に応えるパイプライン開発に向けて包括的な手法を取ることと定義できます。目的を明確に定めることで、プロセスの初期段階で各主要関係者からの要件を明確に特定、定義し、構築されたパイプラインがこれらの要求を満たすよう、要件に照らし合わせて開発を継続的に確認できます。

このためには、まず、明らかになった下流データユーザーのビジネスニーズに対応できるよう、各プロジェクトに求められる最終的な状態を明確に定義する必要があります。なお、データパイプラインは、ほとんどの場合、最終的状態を実現するための手段であり、最終的状態そのものではありません。たとえば、最終的状態の適切な定義の例として、「CRM からクラウドデータウェアハウスにデータを移す」ではなく、「クラウドデータウェアハウス内の CRM データにアクセスできるようにすることで、チームが顧客をよりよく理解できるようにする」ということが挙げられます。これは単なる意味上の違いに見えるかもしれませんが、問題をビジネスニーズの観点から捉えることで、チームがこれらのニーズを最もよく満たす技術的判断を下すことができます。

解決しようとしているビジネス上の問題を明確に定義したら、各関係者からの要件収集を促進し、これらの要件をもとに、取り込みパイプラインの技術開発と実装を進める必要があります。開発に先立ち、下流データユーザーを含む各チームの関係者を集め、データパイプラインの技術的実装のための要件を収集することをおすすめします。この要件としては、重要スケジュール、稼働時間要件、データ更新頻度、データ変換、DevOps 関連ニーズ、セキュリティー上、ポリシー上、または規制上の要件などが挙げられます。

基本方針 2: チームを編成する

パイプライン開発で考慮すべき 2 つ目の基本方針は、チームを編成することです。つまり、データパイプラインの開発、デプロイ、保守を行うために、適切なスキルを身につけた適切な人材を適所に配置することです。パイプラインに対する要件を収集したら、データパイプラインの構築とデプロイに使用する概略的アーキテクチャの開発に着手できます。これにより、データパイプラインの構築、デプロイ、管理を適切に行うために必要な人材を特定し、社外パートナーまたは新しいチームメンバーによる追加サポートが必要な、想定される不備を特定できます。

適切な人材とスキルセットを確保するだけでなく、これらの人材がその能力を最大限に発揮できるように効果的に組織する必要があります。つまり、各チームの責務と、必要に応じて隣接するチームをサポートする能力とにおいて最適化されたチーム組織を編成する必要があります。

また、技術開発の妨げになる事柄を可能な限り防ぐプロセスを策定することも必要です。たとえば、最小権限のコンセプトに背くことなく、データを元のソースからクラウドのデータウェアハウスに移すために必要な、適切なすべての権限をチームに持たせることも求められます。開発者は、移行先のデータウェアハウスに加えて、元のデータソースにも（要件やアーキテクチャに応じて）アクセスする必要があります。たとえば、Salesforce Connected App を開発したり、これに接続したりするためのアクセス権や、検索広告 360° の特定データフィールドへの読み取りアクセス権を開発者に付与する必要があります。

基本方針 3: 価値創出までの時間を最大限短縮する

パイプラインの開発において考慮すべき 3 つ目の基本方針は、価値創出までの時間を最大限短縮することです。言い換えると、データパイプラインを開発・展開する前に、長期的なメンテナンスの負担を考慮することに加えて、利用可能な最小限のパイプラインを可能な限り早くデプロイすることです。一般的に、データパイプラインを構築するときは、メンテナンスの負担を最小限に抑えるため、コードを可能な限り少なめに記述することをおすすめします。これは、機能上、以下のように行えます。

1. 可能な限りインターフェースベースのデータ取り込みプロダクトを活用する。こういったプロダクトを活用すると、継続的なメンテナンスを必要とするコードの量を最小限に抑えることができ、ソフトウェア開発者ではないユーザーでもデータパイプラインを構築できます。また、データパイプラインの開発期間を短縮し、データパイプラインをより迅速に導入、更新することもできます。

Google Data Transfer Service や Fivetran などのプロダクトでは、いずれかのユーザーが開発したマネージド型データ取り込みパイプラインにより、SaaS アプリケーション、データベース、ファイルシステム、その他のツールからのデータを一元管理できます。このマネージドサービスでは、基本的にコードを記述する必要なく、データウェアハウスとソースを迅速かつ容易に接続できます。
ETL 開発者とデータエンジニアが管理するワークロードについては、Google Cloud の Data Fusion などのツールを使用すると、使いやすいインターフェースから、複雑な変換を伴う高度なパイプラインを設計、管理、監視できます。

2. インターフェースベースのプロダクトやデータコネクタでは不十分な場合は、必ず既存のコードテンプレートを使用する。例として、Dataflow に使用できるテンプレート（ユーザーが一般的なデータ取り込みのユースケースについて変数を定義してパイプラインを実行することができる）や、Google のデータセットチームがオンボーディングに使用している一般公開データセットパイプラインアーキテクチャなどが挙げられます。

3. 上記の方法では十分でない場合は、マネージドサービスを利用してパイプラインのコードをデプロイする。Dataflow や Dataproc などのマネージドサービスを利用すると、定義済みのパラメータ内でパイプラインのインスタンスが自動的にスケーリングされ、パイプラインの構成を管理するための運用上のオーバーヘッドを解消できます。

基本方針 4: データの信頼性と透明性を高める

パイプライン開発で考慮すべき 4 つ目の原則は、データの信頼性と透明性を高めることです。このドキュメントでは、この基本方針を、すべてのツールにわたりデータパイプラインを監督、管理するプロセスと定義します。それぞれが異なるツールを活用していたり、調整された管理計画に従って開発されていなかったりする多数のデータ取り込みパイプラインを使用すると、データパイプラインの数が増えるにつれて、データ取り込みパイプラインの管理上のオーバーヘッドが大幅に増加する「技術の拡散」を招くおそれがあります。サービスレベル契約を締結した場合、またはデータパイプラインを監督するための法規上の要件またはポリシー上の要件に従う必要がある場合は、これは特に面倒なものとなります。技術の拡散を防止するうえでは、レポート作成を自動化する簡素化したパイプライン管理プロセスを開発することが最善の策です。理論上は、すべてのデータパイプラインをクラウドベースの単一のプロダクトで構築することでこれを実現できますが、ユースケースに最適なプロダクトを選択することで得られる機能とコスト削減を享受できなくなるため、Google では、このような方法をおすすめしません。

Google Cloud Monitoring Service や Splunk などのモニタリングサービスを使用すると、オンプレミス環境やハイブリッドコンピューティング環境でホストされているプロダクトなどのさまざまなプロダクトからの指標、イベント、メタデータの収集を自動化でき、データパイプラインのレポート作成とモニタリングを一元化しやすくなります。Google Cloud の Data Catalog や Informatica の Enterprise Data Catalog などのメタデータ管理ツールを使用すると、データのニュアンスをよりよく伝えることができ、どのデータリソースが特定のユースケースに最も適しているかをユーザーがよりよく理解できます。これにより、データの不整合や更新の遅れが発生しがちな手動のレポート作成プロセスが不要になり、パイプライン管理の負担が大幅に軽減されます。

基本方針 5: 費用を管理する

パイプライン開発で考慮すべき 5 つ目の基本方針は、費用を管理することです。これには、クラウドリソースの費用と、クラウドリソースの設計、開発、導入、保守に必要な人件費の両方が含まれます。Google は、お客様の目標が必ずしも費用を最小限に抑えることではなく、投資の価値を最大限高めることであるべきと考えています。つまり、クラウドリソースの利用とスタッフの対応時間の無駄を最小限に抑えることで、投資の効果を最大限に高めることが重要です。費用管理に関しては、以下の複数の要因を考慮する必要があります。

作業に適したツールを使用する - データ取り込みパイプラインによって、レイテンシ、稼働時間、変換などの要件が異なります。同様に、データパイプラインのツールによっても利点と欠点が異なります。それぞれのデータパイプラインに適したツールを選択することで、パイプラインの運用効率が大幅に向上します。これにより、全体的な費用を削減し、スタッフの時間を最も影響のあるプロジェクトに集中させ、パイプラインの効率を格段に向上できます。
リソースのラベル付けを標準化する - 組織の支出を最も包括的に把握するために、すべてのツールとプラットフォームで一貫したラベル付けスキーマを導入、活用します。たとえば、すべてのリソースに対し、作成時にコストセンターまたはチームのラベルを付けることを義務付けます。一貫したラベル付けを行うことで、複数のチームの支出をモニタリングし、クラウドに対する支出の全体的な価値を算出できます。
費用管理策を導入する - 可能であれば、費用管理策を活用して、予期せぬ多額の出費につながる誤りを防ぎます。
クラウドの費用を把握する - クラウドデータウェアハウスとデータ可視化ツールを使用して、すべてのクラウドリソースの利用にかかっている費用を把握し、社内分析に役立てます。これを行わないと、クラウド費用の変化の背景と、これがビジネスにおける変化とどう関連しているかを把握できません。
全員で費用管理に取り組む - 費用管理は、クラウドリソースを作成または利用できるすべての人が責任を持って行うべきことです。費用管理を正しく行うため、社内でのクラウド費用報告の透明性を高めたり、利用状況に応じて社内のコストセンターへのチャージバックを実施したりすることをおすすめします。

長期的には、Google Cloud で利用できる費用報告の粒度を上げることで、重要業績評価指標をより正確に測定しやすくなります。費用ベースのレポート作成（たとえば「先月、BigQuery ストレージに何円費やしました」）から価値ベースのレポート作成（たとえば「何円の収益をもたらすお客様にサービスを提供するために何円を費やしました」など）に移行した方がよいでしょう。

費用管理の詳細については、Google Cloud のホワイトペーパー『費用最適化の原則について』をご覧ください。

基本方針 6: 継続的に改善されるサービスを活用する

6 つ目の基本方針は、継続的に改善されるサービスを活用することです。ユーザーにはわかりにくいですが、クラウドサービスの性能と安定性は常に改善されています。これらの改善により、時とともにパイプラインをより速く、より安く、より安定的に運用できるようになります。このような改善の恩恵は、以下の方法によって受けられます。

パイプラインとパイプライン管理の両方を自動化する: データパイプラインの自動化だけでなく、パイプラインの管理もほぼすべて自動化できます。自動化の対象には、パイプラインやデータのつながりの追跡、モニタリング、費用管理、スケジュール管理、アクセス管理などが含まれます。この自動化により、価値提案を大きく変える可能性のある各データパイプラインの長期的な運用費用を削減することができ、手動による構成を行うことで後のプロダクト改善のメリットを台なしにすることがなくなります。
パイプラインの複雑さを可能な限り最小限に抑える: 取り込みパイプラインは、UI ベースのサービスやマネージドサービスを利用して比較的容易に開発できますが、使用している間は継続的なメンテナンスが必要になります。最もメンテナンスが容易なデータ取り込みパイプラインは一般的に、複雑さを最小限に抑え、自動最適化機能を活用したものです。データ取り込みパイプラインでの変換時には、手動によるパイプラインの最適化を行う必要があり、基礎となるサービスの改善に合わせて適応またはスケーリングするのに苦労することがあります。ETL（抽出、変換、読み込み）パイプラインではなく、ELT（抽出、読み込み、変換）パイプラインを構築することで、このような変換の必要性を最小限に抑えることができます。これにより、手動で構成されたパイプラインではなく、特別に最適化されたクエリエンジンを使用してデータを変換するデータウェアハウスに変換を任せることができます。

次のステップ

クラウドベースのデータプラットフォームの開発の詳細については、ホワイトペーパー『Build a modern, unified analyticsdata platform』（英文）をご覧ください。また、Google のデータ統合サイトでは、データ統合の詳細や、データ統合を始めるための方法を紹介しています。

データ取り込みパイプラインを構築する準備ができたら、パイプラインがこれらの原則に対応しているかどうかを確認するうえで、Cloud Data Fusion と Fivetran がどのように役立つかをご覧ください。

- デベロッパーアドボケイト Shane Glass

- Google Cloud パートナーマネージャー Erin Franz

投稿先