エンジニアがいない組織で1からデータ基盤を構築した話
はじめに
本記事はQiitaデータ基盤・BIツール・データエンジニアリング Advent Calendar 2021 の17日目の記事です。
https://qiita.com/advent-calendar/2021/dataengineering
本記事では私が2年前に現職に中途で入社した際に、社内にITエンジニアがいない環境で1からデータ基盤を構築するために実施したことを簡単に説明したいと思います。
背景について
私は現在、卸事業・メーカー事業を中心としたビジネスを行っている企業のメーカー部門に所属しています。ちょうど2年ほど前に現職に中途で入社し、新設されたデータマネジメントチームに所属することとなりました。私が入社した当時の会社の状況としては、「データをマーケティングに活用していきたい、だけど何をやっていいのか全く分からない」という状態でした。そのような状況で、私にはまず始めに「マーケティングのためのデータ活用環境を整える」というミッションが与えられました。(もっとざっくりとした内容だった気がしますが、趣旨としてはこんな感じ)
とは言え、具体的に何を行うかについては全く指示がない状態です。そんな中でまず最初に手を付けたのが「データ基盤の構築」です。なぜデータ基盤の構築から手を付けたのかというと、、正直なところ、「一番イメージが湧いたから」です。
一般的には、組織としての事業戦略が明確に定義された上で、業務における課題に対してデータをどのように活用していくのか等を考えるべきではあるのですが、組織としてはそもそもデータをどのように活用するかなど、まったくイメージが湧いていない状態でした。(「データを使っていい感じに売り上げに繋げて」みたいな感じです。。)
幸か不幸か、入社後に私が最初に担当することになった業務が、とあるWEBのポータルサイトから膨大な量のPOSデータを手動でもくもくとダウンロードし、それをエクセルに張り付けてレポートを作成するという非常に単調な作業であり、またそれらのデータもアウトプットとしてのエクセルのレポートでしか管理されていない状態だったため、まずは加工前のデータをデータ基盤で一元管理するとともに、レポーティング処理を自動化することで業務効率化を行うという建前で、データ基盤の構築に着手することにしました。
つまり、業務効率化という体でデータ基盤の設計・構築をPoCレベルで進めつつ、並行してデジタルマーケティングの観点でのデータ活用イメージを少しずつ管理職や経営層に提案しながら整理していく方向にしました。
データ基盤の構築に向けてやったこと
データ基盤の構築を進めていく上で実際に行った作業は以下の5つになります。それぞれ順番に説明したいと思います。
- 上長へのデータ基盤構築についての説明・GCPの利用許可
- GCPを利用したレポート配信自動化のイメージ整理
- Google Cloud Platform(GCP)を利用してデータレイク・DWHの構築
- 簡易的なデータパイプラインの構築(Cloud Functions・Cloud Scheduler・Cloud Pub/Subを利用)
- データポータルを利用したデータ可視化
- 本番運用を考慮したデータパイプラインの再構築(troccoを利用)
上司へのデータ基盤構築についての説明・GCPの利用許可
私が所属している組織にはいわゆる「ITエンジニア」という職種は存在しません。基本的にはシステムに関する業務は要件定義レベルから全て、外部のITベンダーに丸投げしている状態です。そのような組織のため、クラウドサービスを利用してデータ基盤を内製したい、などと説明をしてもとても理解されないような状況です。
それでも私のミッションである「マーケティングのためのデータ活用環境を整える」ことを達成するため、
- 一般的な企業におけるデータ活用のイメージ
- データ基盤がどのような役割をになうものかについて
上記2つを上司に説明し、データ基盤構築を行うことについて許可を得ました。あと新設のチームかつIT投資に前向きではない組織のため予算がほとんど与えられない状態だったので、最低限のGCPの利用料(月5000円程度)についてのみ負担してもらえるように話をしました。正直、月5000円でどこまでできるか不安ではありましたが、そこまでデータ量がなければ何とかなるかなと思っていました。(結果、どうにかなりました、、というか今でもまだGCPの利用料は月5000円前後です。。)
GCPを利用したレポート配信自動化のイメージ整理
GCPを使って具体的に何を行うかを簡単に整理しました。とは言え、この時点では
データレイクに格納するデータの候補としては
- 外部業者から購入しているPOSデータ
- 自社の基幹システム上の販売管理データ
- Amazonベンダーセントラル上の売上実績データ(Amazonブランド分析レポート)
- 自社ECの会員情報、購入履歴等
こんな感じの想定でした。さすがに一度に全部進めるには人手が足りないので、まずは外部から購入しているPOSデータを一旦、データレイクに格納してそこからDWHに連携、データポータルで可視化＋メール配信、というイメージを整理しました。
Google Cloud Platform(GCP)を利用したデータレイク・DWH構築
ここからは具体的にGCPを利用してデータ基盤の構築を進めていきます。
Google Cloud Platform(BigQuery)を選定した理由
私は現職に就く前にはECサイトや予約システム等のインターネットサービスを運営している企業でDWH(Redshift)の運用を行ったり、業務委託(フリーランス)としてデータ基盤リプレイス案件に関わっていました。その際にAWS(Redshift)とGCP(BigQuery)を利用したそれぞれのケースでのアーキテクチャの検討や費用感についてはイメージが湧いていました。
そのような経験から、まずはPoCレベルで実際にデータ基盤を構築することを考えると、選択肢はGCP(BigQuery)しかありませんでした。(もし今から構築するならSnowflakeを触ってみたいです。。)
データレイクの構築
GCPを利用することにしたため、必然的にデータレイクについてはCloud Storage(GCS)を利用することになります。GCSはAWSで言うところのS3で、いわゆるオブジェクトストレージです。
まずはレポート作成等のために利用している様々なPOSデータのファイルをこのGCSに格納し、データレイクを構築します。
バケットやフォルダの構成について、オブジェクトストレージをデータレイクとして構築するケースが初めてだったので、どのような構成にすればよいかあまりイメージが湧いてませんでしたが、そんなにデータの種類があるわけではないので、一旦はPOSデータ格納用のバケットを作成し、その下には各POSデータの種類ごとにフォルダを作成し、更にその下には各POSデータの売上実績に関する日次のファイルを格納することにしました。
DWHの構築
DWHについてはGCPのDWHサービスであるBigQueryを利用します。BigQueryはGCPのDWHサービスなのですが、サーバレスかつフルマネージドという点が特徴のサービスです。
BigQueryを触ってみた感想として、とにかく運用が楽だという印象を持ちました。以前にAWSのRedshiftの運用をしていたことがあったのですが、スペック的には問題はなかったものの、サービスの運用に必要となる運用リソースが非常に大きい印象です。なんというか、実質的にDBサーバの運用をしている印象でした。
(今はもっと楽になってるのかも＋先日Redshiftもサーバレスアーキテクチャになるという話がありましたね。。)
BigQuery内のテーブル構成について、この時点だと特に複雑な仕組みを作る必要があるわけではなく、いくつかの種類のPOSデータをそのままテーブルとしてロードし(ETL処理なし)、BigQueryのスケジュールクエリ(クエリのスケジュール)でELT処理を実装することにしました。
簡易的なデータパイプラインの構築(Cloud Functions＋Cloud Scheduler＋Cloud Pub/Sub)
データレイク・DWHのイメージは整理できたものの、実際にGCSからBigQueryにデータを連携する仕組みがまだできていません。とにかくお金はかけられないので、GCPのサービスで安価かつ簡単にGCSからBigQueryに連携する仕組みができないか調べたところ、特にETL処理を行う必要がなければ、BigQueryで用意されているクライアントライブラリを利用すれば簡単にできることが分かりました。
＜Cloud Storage からの CSV データの読み込み＞https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-csv
これを自動化するため、一旦はCloud Functions上でクライアントライブラリを叩いてGCS上のファイルをBigQueryにロードするためのPythonのコードを書き、それをCloud Schedulerでスケジューリングして実行することにしました。
データポータルを利用したデータ可視化
必要なデータがBigQueryに溜まったら、あとはデータの可視化です。世の中ではTableauやらLookerやらイケてるBIツールがいろいろありますが、私の部署には予算がありません、、選択肢はデータポータルのみです。(RedashやMetabaseも無料で使えて良さそう(個人的にはMetabaseいいかもと思いました！)でしたが、VM(Compute Engine)を立てるという時点で予算的にアウト、、あえなく断念しました)
BigQuery内では先に触れた通り、クエリのスケジュールを利用してELT処理を実装してデータマート的なテーブルを作成し、そのテーブルをデータポータルからつないでデータの可視化を行うイメージです。
データポータルを使っていくつかダッシュボードを作ってみましたが、可視化する対象が明確になっている＋そこまで分析用途としてデータを深く掘り下げるような使い方をしない限りは、データポータルでも十分かなと個人的には感じました。
本番運用を考慮したデータパイプラインの再構築(troccoを利用)
データソースの種類が少しずつ増え、Cloud Functions＋スケジュールクエリでのELTでは管理が大変になってきたので、運用を意識したETL/ELTの仕組み＋ワークフローの構築を検討することにしました。このあたりになると、社内の情報システム部門からも「何か面白そうなことやってるな」とか「一緒にデータ基盤使わせて」みたいな感じになってきたので、話を進めやすくなってきました。
そうは言ったものの、社内にはITエンジニアが全くおらず、最悪私一人でデータ基盤の運用をしていく可能性があるため、Digdag+EmbulkのようなVMを立てることが必須となるサービスは検討対象外としました。GCP内のサービスでETL/ELT処理＋ワークフローの構築を考えると(当時(2020年12月頃)のサービスで考えると)、ETL処理だとDataflowやData Fusion、ワークフローだとCloud Composerが候補に上がりました。ただ、Composerについては裏でGKEのクラスタが常駐するため、月あたり最低でも6～7万円程度の費用が発生してしまい、とても手が出せません。何よりApache BeamでのETL処理の実装に自信がありませんでした。。
Data Fusionについては実際に触ってはいませんでしたが、界隈の方々による「利用料がとにかく高い！！」という声にビビってしまい、こちらも検討対象外となりました。何か良いサービスはないかと調べていたところ、troccoというマネージドなEmbulkサービスがあることを知り、早速トライアルを申し込んでみました。troccoを初めて触ったときは衝撃的でした、、こんなに簡単にETL/ELT処理ができるサービスが存在するとは、、トライアル2日目で早くも「もうtroccoなしでの運用は考えられない！！」という気持ちになっていました。
ちなみに前職でデータエンジニアとしてとあるETLサービスを利用してデータパイプラインの運用をしていたのですが、とにかく辛かった印象しかありません。。エンジニアがある程度いる組織ならもっといろいろな選択肢があるかと思いますが、私が所属する組織にはエンジニア職は0人、私が少しGCPのサービスを触ったり、Pythonでクライアントライブラリを利用した簡単なスクリプトを実装できる程度、あとは情報システム部門にインフラに強いメンバーが一人いるくらいのため、少しでも運用リソースを減らすことを考える必要があります。このような状況において、troccoはまさにうってつけのサービスだと思います。
予算的な問題はありましたが、幸いなことに情報システム部門ではtroccoの導入には前向きに検討してくれたため、troccoはすぐに導入することができました。こうして何とか実運用に耐えうる(と思われる)データパイプライン構築の目途が立ちました。
https://trocco.io/lp/index.html
その後の取組み
一般的な企業からしたらデータ基盤とは呼べるレベルのものではないかもしれませんが、、一旦は最低限の基盤が出来上がりました。
ここから先は現在、実際に取り組んでいる内容です。
オンプレBIツール(SQLServer Analysis Service)のCUBE移行
現在、オンプレ環境で動いている、SQLServer Analysis ServiceというBIツールのようなサービスの裏側にあるCUBEをBigQuery内で再現することにしました。(ベンダーにも協力してもらいました)
具体的には、CUBEイメージをBigQuery内のストアドプロシージャーで再現するというものです。
CDPの構築
社内のデジタル施策を強化していくため、自社ECのリプレイスを行うことが決まり、それにあわせてKARTE(WEB接客ツール)・Datahub(KARTE内のCDP機能)の導入を行いました。(急に強気なサービス選定w)
KARTE側で自社ECの会員情報や購入履歴等の情報を利用できるようにするため、自社ECパッケージから会員テーブル、注文テーブル等のデータを一旦BigQueryのテーブルに連携し、KARTE側からSQLで参照できる状態にして、施策やメールマーケティングのセグメント作成などに利用します。
とりあえずインフラ的な部分は整ったものの、社内にデジタルマーケティングに精通している人材がおらず、なぜか私自身でKARTEの施策の検討＋実装まで行う始末、、まあ、とても勉強にはなりますがw
primeNumber様のセミナーで登壇しました！
本ブログを元ネタして、
「非IT企業のエンジニア不在組織で、ゼロからデータ基盤を構築した話」
というテーマで登壇させていただきました。
もしご興味があれば、みていただけると幸いです！
