GCPユーザーがETLを利用する5つのシナリオ

2022/07/20

copied!

AWS、Azureと並ぶ「3大クラウド基盤」として活用されている「Google Cloud Platform (GCP)」ですが、フルラインナップのサービスが提供されているだけでなく、超高速なデータ処理を売りとする「BigQuery」など、強力なサービスも多数有しています。

以下では、GCPユーザーが具体的にどのようにETLを利用して業務を効率化しているかについて、ETL製品「Reckoner」開発元である当社ならびユーザー企業様の経験を踏まえて、「5つのシナリオ」をご紹介いたします。

(1)BigQuery→ETL→Cloud SQL (MySQL, PostgreSQL)
(2)Cloud SQL (MySQL, PostgreSQL)→ETL→BigQuery
(3)Cloud Storage → ETL → BigQuery
(4)BigQuery→ETL→Excel, CSV
(5)Excel, CSV→ETL→BigQuery
マルチクラウド＋SaaS＋オンプレミスのデータ統合にETLが貢献
- マルチクラウドを「手動バッチ」でデータ統合するのは正解か？
- マルチクラウド＋SaaS＋オンプレこそETLを使うべき
ETL「Reckoner」でGCPのデータをさらに活用

(1)BigQuery→ETL→Cloud SQL (MySQL, PostgreSQL)

GCPのDWHであるBigQuery上のデータを、ETLで抽出・変換、そしてGCPのRDBサービスであるCloud SQL (MySQL, PostgreSQL, SQL Server) にロードするというシナリオです。

例えば、BigQuery上にある各所から集められたデータの中から、必要なデータのみを切り出してRDBに載せ、システム・サービスを構築するイメージです。

具体的には、高速なBigQueryでデータの取捨選択・分析を行い、欠かせないデータを特定、その後当該システム・サービスで利用するフォーマットにデータを変換したうえでロードする、という流れです。

高速なBigQueryの活用、高速なETLデータ処理により、短時間で大量のデータが準備可能となります。これにより、新規システム・サービス稼働までの時間を短縮できます。

(2)Cloud SQL (MySQL, PostgreSQL)→ETL→BigQuery

次は、上記1とは逆に、RDB上のデータをETLで変換した上で、BigQueryにロードするというシナリオです。

各システム・サービスに点在している多数のデータベース上のデータを、必要なデータ変換をETLで行った上で、BigQueryにロードし、データを集約するイメージです。

BigQueryをメインのDWHとして利用し、多数のRDBを接続させているユーザーからすると、最も多く利用され、またコスト効果やデータ変換効率が分かりやすいシナリオの1つです。

(3)Cloud Storage → ETL → BigQuery

オブジェクトストレージであるCloud Storage上のデータを、ETLで変換したうえで、BigQueryに集約するというシナリオです。

これは、上記2のRDB→ETL→BigQueryという「DWHに分析用データを集約する」のと同じ用途になりますが、データベースではなくオブジェクトストレージである点が異なります。

多くのETLでは、オブジェクトストレージも問題なく取り扱うことができます。これによりユーザーは、その都度データの取得方式やデータ変換の違いを意識する必要がなくなります。そして、BigQuery上にロードされたデータを一元的に取り扱うことが可能となります。

(4)BigQuery→ETL→Excel, CSV

BigQuery上のデータを、ETLで変換した後に、ExcelやCSVにロードするシナリオがこちらです。

DWH上のデータの中から、特に重要な項目のみを抽出し、表形式でデータを保持します。必要なデータのみをわかりやすく共有し、「経営会議」「営業会議」などの場で議論や検討する際に多用されます。また、特定の領域におけるデータを定型フォーマットで都度出力し「定点観測」するのも有効です。

(5)Excel, CSV→ETL→BigQuery

ExcelやCSVで取得した比較的小規模なデータを、ETLで変換した後にBigQueryにロードするシナリオです。

例えば、「セミナー参加者情報」「協業企業から共有された見込み客リスト」「担当者が短時間で分析したデータセット」などを、DWHに投入する際に利用されます。

ExcelやCSVで作成されたデータの多くは、DWHに格納されているフォーマットに最適化されていないため、ETLで変換してからロードします。

マルチクラウド＋SaaS＋オンプレミスのデータ統合にETLが貢献

一般的なデータ統合業務は、GCPだけでは完結しない場合が多いです。つまり、AWS、Azure、SaaS、オンプレなどの他のプラットフォームを含めてのデータ統合が必要となります。つまり、GCPの中だけを考えるのではなく、他プラットフォームを含めた統合を考えなければ、真の意味でデータの基盤構築は成し遂げられません。

また、たとえ上記で挙げたようなデータ統合を行っていたとしても、データ統合に「手動バッチ」を用いているケースが非常に多いです。しかしバッチには下記で解説するようなデメリットがあるため、透明性を持ってデータ統合を実現するには適しません。

この章ではマルチクラウドにおいて手動バッチが適切ではない理由と、それに代わる代替案として「ETL」を利用すべき理由を述べていきます。

マルチクラウドを「手動バッチ」でデータ統合するのは正解か？

先に述べたように、マルチクラウドの統合に手動バッチを利用するのは適していないと考えられます。ここでは3点、手動バッチのデメリットを挙げて解説していきます。

まず1点目に、「クラウドやSaaSの接続に関する仕様変更が生じた場合、バッチごとに対応が必要になってしまう」という点です。これは接続するデータソースが多ければ多いほどその工数は肥大化し、さらに作業ミスや作業漏れも発生しやすくなります。

2点目は、「バッチはブラックボックス化しやすい」という点です。特に社内エンジニアに頼んで内省した場合にブラックボックス化が生じやすく、エンジニアが多忙でドキュメントを作成せず、特定のエンジニアしか中身を理解できないといったケースがあります。またそのエンジニアが退職した場合、内容の理解が引き継がれないというリスクもあります。これもまた、バッチの数や内容が肥大化するたびに、大きなリスクとなり得ます。

最後に3点目は、「バッチのパフォーマンス低下のリスク」という点です。バッチは自由度が高い反面、データの処理速度はプログラム自体のパフォーマンスに依存します。データ処理速度が低下した場合、バッチを稼働させている環境のリソース配分に問題があるのか、もしくはバッチプログラム自体に問題があるかを切り分けないといけません。しかし、バッチがブラックボックス化している箇所の切り分けが行えず、かといってバッチを止めることもできないため、根本的な解決をすることが困難になります。バッチのパフォーマンス低下で困るのはエンドユーザーであり、データを使った経営判断や意思決定の速度や質に影響してしまう恐れがあります。

これら3点から考えても、マルチクラウドに手動のバッチを使用することはおすすめできません。

マルチクラウド＋SaaS＋オンプレこそETLを使うべき

すでにデータ統合された基盤を持っている組織の多くは、大量で巨大なバッチプログラムに支えられているケースが多いのが現状。データ基盤に対して抜本的なテコ入れを行うのは大きなリスクが伴う為、新しいデータソースを追加するだけで、根本となる基盤の改善を行なう組織は少ないでしょう。

しかしこれはリスクの見送りであり、生じるデメリットをデータを使用するユーザーに押し付けているとも言える状態です。結果として、意思決定の質の低下や判断の遅れ、データ取得にかかる工数の増加といった、生産性の低下を招いているかもしれません。

データ統合ならびにデータ基盤の構築は、クラウドに対応するETLやDataOpsなどの登場により、より洗練した形で行えるようになっています。

UI/UXの優れたETLは、エンドユーザーのETL操作、データ操作を容易にします。DataOpsの登場により、「個別最適化されたサイロを多く作り、そこの橋渡しする形でのデータアクセス、データ統合を行う」といったデータ運用ではなく、より抜本的なデータ基盤の見直しが可能となっているのです。

DataOpsとは？

このように、データを取り巻く環境は常に進化し、最適な環境を構築できるツールや知識は備わっています。手動でバッチで組んた膨大なリスクを内包した脆いデータ基盤は、ETLを用いることで強固で安全なデータ基盤へと移行することができるでしょう。

本記事で紹介しているGCPとの連携も同様です。GCPだけで完結しないSaaSやオンプレの統合もETLを利用することで、よりスムーズで管理に手がかからない形で統合できるはずです。