[GCPユーザー向け] ETLでデータ分析環境を構築するための3つのポイント
Google Cloud Platform (GCP) の各種サービスをご利用されている方は、過去に「各サービスからどう効率的にデータを取得、変換・加工し、本当に必要な分析に回せばよいか」について、頭を悩ませたことはありませんでしょうか。
以下では、GCPユーザーがどのように効果的にETLを活用すべきか、またどのようなポイントが重要かをご説明します。
目次
ETL上で加工されるデータ元はどのGCPサービスが多いか
GCPユーザーから「GCPからのデータ取得・加工作業において、どのように効率化を実現できるか」についてお問い合わせを頂く場面が増えてきました。
特にお問い合わせが多いケースは以下の3点です。
- Google Computing Engine (GCE) 上で稼働するデータベース
- Google Cloud Storage (GCS)
- BigQuery
なお、各データ元から取得したデータの変換・加工についてですが、「ストレージのデータをパースして、DBまたはDWHに入れる」「特定条件で抽出しデータマートを作成する」といった活用をされたいケースが多いです。
データの出力先としては、同じくGCPのBigQueryのようなDWHや、SalesforceといったSaaSで活用されるケースが多いようです。
GCPユーザーがデータを変換・加工する3つの方法とポイント
データを膨大に扱うGCPユーザーが、データを変換・加工したい時に、取り得る方法は3つあります。
具体的にどのような作業が発生するかを、「GCE上で稼働するデータベースから、データを取得、変換加工、出力する」という流れで比較してみましょう。
1.手動でデータを都度取得、変換・加工、出力する
まずは、自分自身でその都度、データを取得、変換・加工、出力する方法です。
- データベースに対してクエリを投げて、必要なデータをCSV形式でダウンロードする
- ダウンロードしたCSVを、Excel上で変換・加工する
- CSVファイルのインポート機能がある出力先であれば、CSVファイルをそのままアップロードする。CSVインポート非対応の場合は、APIを経由してデータをアップロードする。
ETL (Extract, Transform, Load) の全ての作業を手動で行うわけですので、相当な工数がかかります。また、自動化できていないため、夜間処理などが行えないのもマイナスです。
また、手動作業となると、一定の確率で必ずヒューマンエラーが起こります。この場合、手戻りが発生するだけでなく、「すぐにデータが必要」なユーザーの意思決定に悪影響が出ます。
2.上記1の作業を自分で自動化する
次に、上記1の手動作業を自動化する方法を考えてみましょう。
- バッチ処理を行うためのスクリプトを作成
- 各サーバーで必要な設定を行う（必要に応じて新たなサーバーを立てる）
- スクリプトをテストし、正しく動作するかを確認する
- 正しい動作が確認できたら、自動処理を設定し、正しく動作するかを確認する
- 自動処理の正しい動作を確認したら、本番データの処理を設定する
データ周りに強いエンジニアがいれば、スクリプトの作成、サーバー側の設定、複数回のテストを実施したうえで、処理を自動化することが可能です。夜間バッチにも対応できます。
問題としては、それぞれの処理（ワークフロー）ごとに上記の作業が必要である点です。このため、必要な処理を全て自動化しようと思ったら、エンジニアのリソースを大量に消費することになりかねません。また、データ取得先、データ出力先の仕様が変更となった場合は、全てのワークフローの修正が必要となる点もマイナスです。
さらに、サーバーの管理が新たに必要となるため、エンジニアがインフラ管理に工数をとられることもマイナスとなります。
3.ETLを利用する
- ETL上で処理を設定
- ETL上でテストを実施
- 問題なければスケジュールを設定
ETLを利用して出てくるアウトプットは、上記1と2と変わりありません。大きな違いは３点あります。
1つめは、「エンジニアの工数を消費せずに自動化が実現できる」ことです。製品にもよりますが、コーディング不要のETL製品であれば、エンジニア以外の人がこれらの処理を設定することが可能です。さらに、クラウド型のETLであれば、インフラ面の管理は完全に不要となります。
2つめは「接続先の仕様が変更となった場合は、ETLを提供する開発元が修正対応を行ってくれる」点です。このため、仕様変更に対応してワークフローを全て見直し、修正する必要がなくなります。
3つめは「サポートが受けられる」ことです。上記2の場合は、マニュアル（英語・日本語）を読み解いたり、Webなどで同様の処理を行っているブログなどからしか情報が得られないため、一度躓くと解決に時間がかかります。ETLを利用していれば、サポート窓口から専門的な知識のある担当者に問い合わせできるため、問題を短時間で解決できます。
このように、効率面を考えるとETL利用が、他の2つの方法に勝っていることが分かります。
GCPユーザーがReckonerを選択すべき理由
多量のデータ変換・加工を行う際、ETLを利用すべきである理由についてご説明させていただきました。では、どのETLを使うべきかという質問に対して、「当社のETLであるReckonerを選択すべき」理由についてご説明します。
1.クラウドネイティブであること
ETL製品には、「オンプレミス時代から提供されている製品」と「クラウドネイティブ製品」の2通りがあります。
オンプレミス時代から提供されているETL製品は、「クラウド対応」とアピールされていても、自社で構築するサーバーが必要であったり、SaaSへの対応が不十分な場合が多くあります。ネットワーク的に完全に閉じた環境でのバッチ処理を超高速で行うのであればよいですが、それ以外の利用、特にSaaS連携を前提とした利用には不向きです。
クラウドネイティブのETL製品は、「インターネット接続ならび、SaaSからのデータの受け渡しを前提」とした製品となります。このため、SaaS間でのデータ加工変換処理をいかに簡単かつ効率的に行うかに焦点を当て、設計がなされています。Reckonerも、クラウドネイティブのETL製品です。
2.日本発・完全日本語対応製品であること
Reckonerは、日本で開発されたETL製品です。すなわち「日本語でのサポート」「時差なし・同じタイムゾーンでのサポート」を提供できることを意味します。
海外のETL製品は、日本では代理店からの販売がメインで、最初のサポートは代理店が行うケースがほとんどです。そして、代理店で解決されない問題については海外の開発元にエスカレーションされます。この場合、時差があるため問題に関するやり取りが頻繁に行えず、解決までに時間がかかることを意味します。
Reckonerは日本・東京で開発されるETL製品で、日本時間で業務を行っているため、業務時間内に集中してやり取りが行え、早期に問題解決ができます。
加えて、Reckonerは「ドキュメントがすべて日本語で提供」されています。
ドキュメントの一部、また大半が英語でのみ提供されている場合、どうしても「英語のドキュメントを見るのを後回しにした結果、手戻りや問題が生じる」ことがあったり、「英語ができるスタッフにだけ負荷が集中する」ことが起こります。
ドキュメントがすべて日本語で提供されているReckonerでは、このような問題は起こりません。
3.固定費 + 従量課金型で安価であること
ETL製品には、大きく分けて「買い切り型の製品」と「SaaS (サブスク型) の製品」の2タイプがあります。
買い切り型の製品は、初期投資が数百万以上かかる場合が多く、後から「製品選びを間違えた」と気づいた場合や、「新機能の投入が遅いので乗り換えを検討したい」場合などに、気軽に乗り換えることができません。結果、生産性が低い製品を渋々使い続ける羽目になってしまいます。
これに対して、Reckonerは「月額固定費 + 従量課金」のSaaSです。月額15万円から利用開始でき、より多くのデータを扱う場合のみ追加費用が発生する、従量課金型となります。
14日間無料評価、データ周りのコンサルティングも可能
Reckonerは14日間無料で評価利用可能です。評価利用期間に作成いただいたワークフローは、本契約に移行後もそのままご利用いただけます。よって、「とりあえず14日間試してから決める」ことが可能です。
また、社内のデータ連携周りを一度全て見直したい、ETLで最適化する方法を教えてほしい、という場合には、コンサルティング （有償）もご利用いただけます。Reckonerをフルに活用し、データ抽出、変換加工、ロードをできる限り自動化する過程で、Reckonerに精通したスタッフによるコンサルティングが役立ちます。
ぜひReckonerを利用し、エンジニア工数や人件費を節約し、「これまでと同等、または安価なコストでより多くのことを実現」頂ければと思います。
ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。
