データ分析基盤「Wodom!」の新しい幕開け
はじめに
JDSC 技術共同創業者の橋本です。魚介類の仕入れもできます。
それはさておき、この記事では JDSC のデータサイエンス （以下DS ）を補完する弊社の技術アセットである、データ基盤やデータパイプライン構築をする Wodom! （うぉどむ） の 2023年版のお話をさせてください。
開発チームの内部では Wodom!Pod ( Workflows over DBT on Modularized Pipeline Operations Deployment )と呼称しています。
JDSC の Wodom! とは
JDSC でデータサイエンス案件やPoC、AIモデル構築に取り組むうちに、いくつかのデータ基盤やデータパイプライン構築のニーズがあることから、データ基盤構築プロダクトとして、Wodom!の開発を行い、実際にいくつかのお客様にご利用いただいておりました。
よろしければ以下リンクをご覧ください。
「データサイエンス案件は、データ連携やデータの前処理が9割」であるとか、「データウェアハウスにデータが入ってしまえば簡単、データが入るまでがむしろ大変」といったことはこの業界ではよく言われることだと思いますが、色々なお仕事をご一緒する中で、私たちもこれらについてはとても実感があります。
データウェアハウスについては、Google Cloud さんであれば BigQuery や AlloyDB。 AWS さんであれば Athena や Redshift、Azure さんであれば Azure Synapse Analytics。それ以外にも Snowflake さん..などなど…、枚挙に暇がありませんが、データウェアハウス製品が費用面でも利用面でもリーズナブルになっていく一方、性能は向上しているので、私たちは恩恵にあずかっています。
その恩恵をいかにカジュアルに受け取るか、ならびに巨人の肩にひょいっと乗りたいという観点に特に我々は注目しました。そこで、データの取り込みと統合に注力したプロダクトとして、Wodom! を作成し、そのデータウェアハウスの力をまず扱えるようにする。その後、データの活用については弊社コンサルタントやデータサイエンティストと伴走して、ビジネスインパクトを出していこう、日本を UPGRADEしよう、という取り組みを続けてきました。
Wodom! によって、データウェアハウスの民主化を行い、一定の技術がある人が、そのようなデータウェアハウスの威力を活用できたり親しくなれたりするというところで、一定の成果を果たせたかなと思います。
犬は吠えるがキャラバンは進む
犬は吠えるがキャラバンは進みますし、リリースされたサービスは吠えるが、技術の負債化は同時に進みます。
JDSC は当時、 Wodom! のためのつよつよなエンジニアチームを組成し、Kubeflow （後に k8s ）で構成されたデータウェアハウスへの取り込みが可能な データ基盤プロダクトをリリースしていました。
こちらは以下リンク先をご参照ください。
一方で時が流れれば、よりユーザーフレンドリーで費用面で優位な新たなサービスが登場してきます。
私たちは「UPGRADE JAPAN」 のミッションのもと、我々自身や我々のサービス自身も UPGRADE すべきと考えています。また、ビジネスと研究や製品開発は良い意味で近しく連結してあるべきという Joint R&D の考えからも、データ基盤構築のソリューションは UPGRADEすべき、という思いを弊社でも強めておりました。
特に、四国電力グループのSTNetとJDSCが共同で「データ活用人材」を育成 ～データ分析基盤の実現性も検証〜｜株式会社JDSC にてご一緒させていただいたご縁から、データ分析基盤構築についての経験を踏まえて改めて社内でも再整理をし、データ分析基盤のための取り込みやパイプラインについてアセット化やプロダクト化を行い、新しい形の Wodom! として再構築することを考えました。
以降、この記事では従来の Wodom! と区別するために、新 Wodom! を Wodom!(POD) として表記します。
Wodom!(POD) のコンセプト、キーテクノロジーとアーキテクチャ
コンセプト
従来の Wodom! でも、そもそも地味に大変なデータウェアハウスへのデータ取り込みを、それなりに簡単にするという観点でのソリューション提供には、一定の成果を果たしていました。ですが、上述のとおりアーキテクチャやサービスとして良い新サービスが登場したこと。一方で難しいものは難しく、「データウェアハウスへのデータ取り込みが誰でもできる」というのは、やっぱりそれなりに難しいということもわかってきました。
そこで、利用想定ターゲットを少し pivot して、データベース技術者やインフラ担当の方とご一緒する。お客様と弊社とで、データ分析基盤を構築し、実際にデータの可視化や機械学習モデルのビジネス実装を伴走する場合において、どうなっているのが嬉しいかということを考え、UPGRADE Wodom! の名のもとに、改めてデータ分析基盤に必要なことや、自分たちが欲しいものを再整理してみました。
アーキテクチャとキーテクノロジー
上記のコンセプトにのっとって、データ基盤とパイプライン構築のアーキテクチャはシンプルです。アーキテクチャ図は上記で、 Cloud Workflows, Cloud Run Jobs, dbt を組み合わせて、Cloud Storage に置かれたデータを Workflows で BigQuery に Load 。 Load してから後段の Workflows で、Cloud Run Jobs で dbt コンテナを動作させます。dbt に記述された model 定義と SQL により、データマート構築までの、データパイプラインとデータ基盤を稼働させています。
パイプラインの起動については、Cloud Scheduler によって、Load からの一連の Workflows 稼働をベースとしていますが、PubSub 経由のイベント駆動型にするといったことも可能です。
また、一連のインフラとアーキテクチャ定義は Terraform の IaC により記載されています。Google Cloud の project 作成等の下準備だけは必要ですが、terraform apply をすることで、 workflows をはじめとする データパイプラインとデータ基盤の「かけうどん」のようなベーステンプレートが構築されます。
IaC については、自動構築の恩恵も確かにありますが、クラウドインフラやアーキテクチャがソース管理され共有されることに、むしろ恩恵があるように思います。個人的な推しとしては、Workflows + dbt on Cloud Run Jobs + BigQuery に魅力と可能性を感じますが、Workflows + Dataform + BigQuery と言ったマネージド構成に倒すといったことも考えられると思います。
JDSC でデータフローや DAG 的なパイプライン処理は Cloud Composer を結構使っていました。ですが、やや重厚すぎて、費用やメンテナンスが想定より嵩みがちでした。Wodom! 時代の k8s についても色々ありました。物事をシンプルにするという観点で Cloud Workflows はとてもありがたいサービスだと思っています。費用もお手頃ですし。
再びコンセプト
Wodom!(POD) については利用ターゲットを技術のわかる方にしたため、Cloud Storage へのデータの最低限の整形や転送、dbt 上の SQL 等の記載は必要です。また、昨今のデータ基盤のデータの取扱においては、 ETL より ELT 、あるいは E(T)LTではと言ったところが取り沙汰されており、従来の Wodom! から、そのコンセプトは継承されていて、事前にデータを絞り込めたり、転送量を減らせるなら費用も時間も効率が良くなります。そのあたりも技術のわかる方向けというコンセプトになっています。
また、いろいろなデータウェアハウスのサービスが登場していますが、いずれのサービスにおいても結局大魔王SQLからは逃げられないということもありました、というかみんな大好きSQL。
なのであれば、正々堂々 dbt のアシストのもとで、データ加工やモデリングを行うのが正しいのではというコンセプトで今回は考えています。SQL はテストやソース管理が難しい…ですよね。そういうところについても dbt が一定の補助になっているのも個人的にはありがたいです。
再びアーキテクチャとキーテクノロジー
そして、アーキ図を再掲しつつアーキテクチャの話題に戻ります。Data Lake としての Cloud Storage に入れる経路、ならびにData Mart からの出口戦略については、Wodom!(POD) では定義をあえて、していません。
Data Lake に入れるルートでは、DB dump を sync する。オンプレから embulk する。などなど、実際、人やシステムを含めて誰がやるのかが、ケースバイケースということがよくありました。
同様に Data Mart 以降の出口についても、Looker Studio や Looker、 Power BI、 Tableau での可視化。Application DB に export する。オンプレの DB に書き戻す。 BQ MLしたり、Vertex AI に投げつけるなどなど、こちらも実際はケースバイケースなんですよね。
いくつかの事例を持っているのですが、これらはそれぞれお客様が既存で使われている環境にも依存しますし、早すぎる最適化は良くないという格言にも従い、あえて前段と後段を定義していなかったりします。
実際に使ってみる様子
手前味噌ですが、早速 Wodom!(POD) を用いてデータの取り込みと Data Mart を構築。今回は Looker Studio までの可視化を行いました。
今回は、国土交通省提供の全国の人流データ（1km メッシュ、市町村単位発地別）の 2019年〜2021年のデータから、東京23区における人流から新型コロナと外出自粛の影響について、簡単な可視化をしてみようと思います。
・国土情報：全国の人流データ（1kmメッシュ、市町村単位発地別） を公開します - 国土交通省
・全国の人流オープンデータ（1kmメッシュ、市区町村単位発地別） - G空間情報センター
早速ですが結果はこちら
そこそこ直観を裏付ける結果となりましたが、商業地区やビジネス地区にあたる港区や千代田区が2020年に顕著に減少する一方、世田谷区や練馬区や足立区は増加傾向という傾向が見られました。
こちらはほんの一例ですが、前段の load 体系をある程度揃えることでデータの取込までをある程度スムーズに。また、データパイプライン処理をWorkflows と dbt で型化することで、データマートの作成をスムーズにし、後段の調査や可視化に注力でき、かつ時間効率も良い形で実装ができています。
結び
こちらの記事では、JDSC が最近社内で使っている Google Cloud のデータ分析基盤 Wodom!(POD) のご紹介をさせていただきました。
今後はよく使われる、可視化や Vertex AI 活用の類型化、また最近流行りの LLM や生成系AI のプロンプトエンジニアリングとの連携の仕方やそちらに向けてのデータ活用の知見を強化して、面白いビジネス実装や社会実装を行っていければと思います。
謝辞
最後に、スタッフロール的な謝辞です。 かつて弊社メンバーで Wodom! の開発に携わっていただいた皆様には、この場を借りて改めてお礼をします。
また、 Wodom!(POD) やデータ分析基盤と伴走プロジェクトでご協力いただいた皆様も、ありがとうございました。
【おまけ】ちなみに、流行りのAI の ChatGPT さんと相談もしました。
流行りに乗って ChatGPT さんとも相談してみました。実は Wodom!(POD) のお名前のコンセプトについては、ヒントを頂きました。すごい時代になりましたね。
それぞれの頭文字に対して、あなたのサービスの特性に合った単語を提案します：
W: "Wholistic" - 全体的な視点を持つという意味で、データの全体像を理解する能力を強調しています。
O: "Operational" - サービスが実運用に対応していることを示します。これは、提供されるソリューションが実際のビジネスニーズに対応していることを強調します。
D: "Data" - これはそのままで、データを中心としたサービスであることを示します。
O: "Optimization" - サービスがデータを最適化し、最高の結果を達成することを支援することを強調します。
M: "Management" - データ管理に重点を置いており、顧客がデータを効果的に管理できるようにサポートすることを示しています。
したがって、WODOMの略語は "Wholistic Operational Data Optimization Management" となります。データの全体的な管理と最適化に焦点を当てています。
あなたの提案は、サービスの機能を非常に具体的に表現しており、具体的で直感的な理解を促します。以下に各単語の意味を解説します：
"Workflows"：この単語は、一連の自動化されたプロセスまたはタスクのシーケンスを指し、頻繁に行われる作業を一元管理することを示唆しています。
"over"：これは一般的に、「〜を使用して」または「〜上で」の意味で使われます。このコンテキストでは、「DBT上でのワークフロー」を意味しています。
"DBT"：DBT（Data Build Tool）は、データエンジニアやデータ分析家が大規模なデータセットをより簡単に扱うためのオープンソースツールです。
"on"：ここでも一般的に、「〜を使用して」または「〜上で」の意味で使われます。「Modularized」に関連して、モジュール化されたプラットフォームまたはフレームワーク上で作業を行うことを示唆しています。
"Modularized"：この単語は、サービスがモジュール化された設計に基づいていることを示し、これにより各機能が独立して機能し、必要に応じて追加または変更できることを示唆しています。
したがって、「Workflows over DBT on Modularized」の名前は、DBTを使用してワークフローを自動化し、それをモジュール化された環境で行うことを可能にするサービスを強く示しています。非常に明確で、具体的なサービス内容を示しています
全体的なイメージ：
P: "Proactive" - アクティブに問題を解決し、予測する能力を強調します。
O: "Optimized" - サービスが効率的で最適化されていることを示します。
D: "Dynamics" - 動的な状況に対応でき、変化に対応できる能力を示します。
これにより、"Proactive Optimized Dynamics" となり、サービスが効率的に動作し、問題を予測し、動的な状況に対応する能力を持つことを強調します。
具体的なイメージ：
P: "Pipeline" - データパイプラインという具体的な概念を直接指します。これはデータの連続した処理を意味します。
O: "Operations" - データパイプライン上で行われる操作やタスクを指します。
D: "Deployment" - データパイプラインの展開または実装を指します。これは具体的にデータの取得、変換、ロードといったプロセスを含みます。
これにより、"Pipeline Operations Deployment" となり、サービスがデータパイプラインの操作と展開を管理することを明確に表現します。
この記事が気に入ったらサポートをしてみませんか？