「データ収集基盤とデータ整備のこれまでとこれから」Data Engineering Study #2イベントレポート

第1回勉強会「Data Engineering Study #1」では「DWHとBIツール」の選び方について学びました。これらはデータを扱うためのツールなので、当然「データ」そのものを集めないといけません。実は大容量データの取り扱いには専門的な知識が要求されます。

今回の勉強会では、データを集めるための基盤の話と、集めたデータをビジネス活用しやすい状態に整備する方法の、2つのテーマについて学びます。

基調講演には「前向きデータ整備人」勉強会主催者のしんゆう氏をお招きし、今回のテーマの概論をお話しいただいた後、実際にデータ収集・整備を行われている2社の事例からユースケースを深掘りしました。

当日の発表内容はこちらのYouTubeでご確認いただけます。

基調講演「事業に貢献するデータ基盤を作ろう・考え方編」

データ基盤とは、「収集フェーズ」を速やかに、かつ正確に行う仕組みのこと

まず、「何のためにデータ基盤を作るのか」について語られました。「どんなデータ基盤を作るか」については話題になりやすい一方、「何のためにデータ基盤を作るか」はあまり語られていない傾向にあるそうです。

しんゆう氏：データ分析は目的の決定から始まる一連のプロセスです。その中でデータ収集というフェーズがあり、知りたいことのために必要なデータを集めてくることになります。データ基盤というのは、データ分析プロセスにおいてこの収集フェーズを速やかに、かつ正確に行う仕組みのことだと言えるでしょう。

そこで、データ基盤を作るうえで意識しておくべき2つのポイントが紹介されました。

1.プロセス

しんゆう氏：良いデータ基盤が整っていないと後が続きません。データ基盤が整っておらず、収集フェーズで引っかかると、それだけ意思決定が遅くなってしまい、その質が落ちてしまいます

2.データ基盤

しんゆう氏：データは意思決定に使われて初めて価値に繋がります。価値のないデータ基盤を作らないためにはどうしたらいいのでしょう。よくあるのは、そもそもの問いが違うケース。ニーズにあっていないのに基盤だけ作っても使われないというのは当然です

「基盤」と「利用」のバランスを取る「データアーキテクト」「データ整備人」

「基盤」を作ることと、そのデータを実際に処理して洞察し、意思決定していくという「利用」のバランスが悪いと、うまく機能しません。この「基盤」と「利用」は個別に扱われがちであり、広い視野を持って取りべきであると強調されました。

しんゆう氏：『基盤』と『利用』の間で誰かがやってる業務はありませんか？具体的にどんな役割があるかを説明します。

収集されたデータは、『データレイク』『データウェアハウス』『データマート』のどこかしらに、何らかの形で置かれます。『利用』については、集計からモデリング、処理、分析をするフェーズです。その間には大きく3つの役割があります。

1つ目はデータを利用する人のために必要なデータを作ったり、集計したり、集めてくる役割。2つ目に、データを速やかに、スムーズにパスするためにデータを整理しておく役割。3つ目は、基盤を作る人とのコミュニケーションを行い、汚いデータの整理や不足分を補う役割です。

この辺りの役割をまとめて、「データ整備」と呼んでいます。誰かがやらなきゃいけないものの、困ったことに評価がなされにくいという問題があります。貧乏くじ扱いになってしまい、役割の押し付け合いになるといった不幸な状況が起きてしまいます。

私の主張は、この業務は1つの役割として認識し、『データアーキテクト』『データ整備人』のような人を置くべきだと考えています。例えるなら、生産者と小売店舗をつなげる、小売業における物流や中間業者の役割をもつイメージです。

「基盤」「整備」「利用」のバランスをどう取っていくべきか

データ基盤と整備のこれからの論点として、「基盤」「整備」「利用」のバランスをどう取っていくべきかという点が挙げられるそうです。この3つの役割は1つが大きく欠けると他が機能しなくなるという問題があります。

しんゆう氏：『利用』がなければ、基盤と整備なんてやる必要がありません。『基盤』が欠けていたら『整備』のしようがないし、『整備』がないと業務効率が著しく悪くなるのです。この3つの役割のバランスがよい状態とはどのような状態か、そしてそれをどう評価するか。ここが今後の論点であり、課題です。

事例紹介1「データ収集の基本と 『JapanTaxi』アプリにおける実践例」

このセッションでは、データ基盤へのデータ収集方法について、基本的な内容が説明されました。具体的には、取るデータの種類（ファイル、DB、API）とデータのとり方（バッチ、リアルタイム）の組み合わせに対して、典型的なシステム構成を紹介されています。 また、後半ではJapanTaxi分析基盤でどのように実現しているか、その事例が紹介されました。

JapanTaxiのデータ分析システム全体と収集の役割

渡部氏：JapanTaxiでは、データが生まれる『事業システム』と、それを分析する『分析システム』に分けています。直接の利益向上を目指していくために、データ収集からアドホックに分析したり、ダッシュボードで可視化したり、データアプリケーションを使って意思決定を行うのがシステムの全体像です。

ここでデータ収集が考えるべき範囲が、『データソース』から『データレイク』『データウェアハウス』に入れる部分です。今日はこの部分の作り方を説明していきます。

データソース

データソースの種類と取得方法について解説していきます。

まずはExcelやスプレッドシートを使用するもの。ウェブサイト、ECサイトを見ても上から順番に頻度が低いものから高いものへ並んでいき、一番頻度が低いものとしてはExcelやスプレッドシートにコードマスタに入っており、これらは手動でアップロードすることもあります。オブジェクトストレージにはAmazon S3やGoogle Cloud Storageなどの製品がありますが、主にシステム間のデータ連携目的で利用され、ファイル形式ではCSV・JSON・Avro・Parquetがよく使われます。また、APIによる呼び出しもありますが、これはインターネット上に公開されているAPIでトークンをもらうものです。

次にデータベース。データベースにはユーザーのマスタだったり、商品のマスタといったトランザクションが入っています。もっと頻度の高いやつではアプリケーションのログファイル、具体的にはアプリに入ったあとに検索されたり、購入されたりした際に残るものです。

DBからとる方法で、一番簡単なのがSQLです。セレクト文をデータベースで投げるもので、セレクト文投げるとカーソルが返ってきて、そのカーソルに対してデータが塊で落ちてくるものになります。他にはエクスポートする方式もありまして、ダンプ方式や更新ログ方式というものがあります。

更新ログ方式というのは、データベースにどういう更新がかかったかをlogに出してあげて、復元用データベースに適用してあげるというもの。負荷がとても小さく、ダンプ方式よりもデータの鮮度は高く保てます。デメリットとして、自前で構築するのはかなり至難の業でして、その製品について相当精通している必要があります。なので、既製品の利用が前提となります。例えばtrocco®︎やAWSのDatabase Migration Service、Attunity、Oracle Goldengateなどです。

次はログファイルをエージェントで取るところです。アプリのサーバやコンテナに、アプリケーションがログをばんばん吐くと、エージェントはログの『tail -f』で一番最後の行をずっと取っていき、収集マネージャに渡します。1つ目のポイントとしてはアプリログをこの収集エージェントで取れる形にする必要があること。例えば、JSON形式を出してくださいみたいな、そういうのをこっちが事業システムに働きかけなければならず、調整が大変だったりします。あとは急に重量が増えたときにバッファが溢れちゃったり、クラッシュしたりすると、ログが消えちゃうので、注意する必要があります。こういうことができるのは、『Fluentd』『Logstash』とか『Amazon CloudWatch Logs』ができるものになります。

最後に一番流量が多いもので、分散キューを利用した収集です。ブラウザやスマホアプリに入ってるSDKやIoTデバイスから直接イベントを送ってくれます。JavaScriptが「マウスの移動」「クリックしました」といった情報を全部受信して、分散キューに入れてあげます。

アプリデータや外部データの取得には「trocco®︎」を活用

次にJapanTaxiにおける実践例を紹介いただきました。渡部氏が在籍する「Mobility Technologies」は、JapanTaxiと「MOV（モブ）」で知られるDeNAのオートモーティブ事業部が合併して立ち上げられた会社です。タクシー配車アプリ「JapanTaxi」のデータ収集では、毎日タクシーから多くのデータ流量があるといいます。

渡部氏：分散キューの扱い方としては、『Kinesis Data Streams』で受けて『Lambda』をコンシューマーとしてBigQueryへと。あとアプリログはFluentdという、イベントログをエージェント型で取ってくるもので取得しています。『Firebase』は直接『BigQuery』の生データに突っ込んでくれます。

あと、アプリデータはSQLで取得しており、ここは『trocco®︎』を使っています。外部システムはAPIコールが多いので、『trocco®︎』や自前の『python』でAPIコールをしています。また、ダウンロード数などは、直接BigQueryに入ってくる仕組みを自社で開発しました。

データ収集における3つの勘どころ

セッションの最後には3つの勘どころが紹介されました。

渡部氏：1個目はETL製品の付き合い方です。ETL製品は世の中にいっぱいあります。私が選ぶときの選定基準は3つです。

データの収集するときは優先度を考えましょう。
データ全部が等しく重要な訳ではなく、やはり重要度があります。目的の分からないデータは取らないことが重要です。
『データを一箇所に集めよう』『データレイクにとりあえず溜めよう』といったデータ収集チームができた時点で事業から遠くなってしまうので、要注意だと思います。

事例紹介2「メルカリにおける分析環境整備の取り組み」

データ基盤へと収集したデータを事業成果につなげるためには、データを効率的に使えるようにするための整備が欠かせません。メルカリにおける分析環境整備の取り組みと収集したデータの整備について、分析環境の整備を担当している永井氏より事例をご紹介いただきました。

社員のおよそ4割が「BigQuery」を扱うメルカリのデータ活用

まずメルカリにおけるデータ分析の現状について語られました。基盤には「BigQuery」が非常に中心的な存在となっており、取得したデータは「BigQuery」に格納され、分析時も「BigQuery」にクエリを投げ、データマートを作るときも「BigQuery」上に作っています。他には、ダッシュボードツールとして「Looker」を導入しているとのこと。

永井氏：700名の方々が分析に使ってるテーブルのバリエーションも100種類をゆうに超えており、そこで使われているデータのバリエーションも非常に多い状況です。データを扱っているロール（役割）としては、私と同じようなアナリストと呼ばれる、人の意思決定を支援するために分析してる担当や、マシンラーニングのエンジニアの方やプロダクトマネージャーの方、CSの方ファイナンスの方、さまざまな職種の方がメルカリの中でデータを活用しています。メルカリの社員数1,800名のうち、およそ700名が『BigQuery』を使っている計算です。

次になぜデータの基盤の改善に取り組むのか、その動機について語られました。

永井氏：多くの社員が分析に使ってる環境を整備していくことで、会社全体の生産性を改善していくことが作業時間を削減する面でも、そこから得られる成果という面でも大きいと考えています。重要であるにもかかわらず、分析環境の整備が十分に行われてるかというと、まだまだ行き届いていないところが多いのです。その課題のフェーズとしては、今使ってる基盤をどのように運用改善していくかという『運用フェーズ』の課題が大きいと考えています。

改善のサイクルを回すことで、攻めの改善を行う余力も

永井氏：次に、メルカリのデータ基盤は理想的にはどういう状態にしたいのかについてお話しします。一言で言うと、『改善のサイクルを回し続ける状態』にしていきたいなと。

そこで避けたい状況として挙げられるのは、運用に追われてメンバーが疲弊する状態です。改善に使える時間が減ってしまい、さらに現状維持が大変になって行く。こうしたマイナスのサイクルが一番避けたいこと。逆に改善に取り組むことによって現状維持が楽になり、更なる改善ができるというサイクルが回っていくことが望ましいです。

こうして改善のサイクルが回っていけば使える時間はどんどん増え、最終的には現状維持だけでなく、今までできなかった環境整備も行えるという、攻めの改善を行う余力もでてくる、それが理想の状態です。

分析基盤は「業務要件とKPIと基盤」のセットで見直そう

続いて語られたのが、メルカリでの具体的な取り組みについて。現在は「レガシーなデータセットを廃止する」という取り組みを行っているそうです。

永井氏：現状維持コストの中でも、結構古くなってしまったものをメンテナンスしていくコストは一番に削減したいところ。

メルカリの分析環境の中のごく一部にはデータpipelineが2系統あるという問題があります。ここでは仮に『分析テーブル（新）』と『分析テーブル（レガシー）』と呼びます。この状況下では、メンテナンスコストがかさむという弊害が生まれます。また、2つのテーブル間で若干の変更、反映のタイミングの仕様が違うために、同じ定義のKPIを集計しようとしても数字が合わないといった、メンテナンス上の厄介な問題を起こしているのです。

どうしても『分析テーブル（レガシー）』の仕様で計算するKPIが必要というチームがあり、『分析テーブル（新）』で再現しようとしたのですが、技術的に難易度が高くて完成できず、新環境に片寄せすることができない課題がありました。

『分析テーブル（レガシー）』が廃止できない原因がどこにあるのかというと、レガシーなpipelineに依存した業務が止められないから残さざるを得ない、というもの。

ここで必要な取り組みは、レガシーな『分析テーブル（レガシー）』をすぐなくすのではなく、どうしてその業務では『分析テーブル（レガシー）』から計算したKPIが必要であり、そのKPIをどのように使っているかという業務理解と、そこに対して必要なKPIの要件を調べて行くことによって、何とか『分析テーブル（レガシー）』依存を脱却できないかに取り組みました。もう少し時間はかかりそうなのですが、一部で脱却することができました。

データ基盤は、どういう集計をしたいかっていう要件と、その業務に依存してるところが大大きいため、基盤単体で考えるのではなく、『業務要件とKPIと基盤』はセットで考えて見直していくことが改善に必要なポイントです。

「時間の再投資」を続けて行い、改善の輪を大きくすること

永井氏：メルカリにおける分析環境の整備の事例を紹介させていただきましたが、現状としてまだまだ改善の余地があります。逆に言うと、改善をすることで生産性を上げて行く余地があるのです。改善後のありたい姿としては、改善に使える時間を捻出して、改善によってさらに時間を得てという、『時間の再投資』を続けて行い、改善の輪を大きくすることです。

そのための取り組みとして、レガシーなデータセットを廃止する取り組みを行っており、そのためには、業務要件をKPIと基盤っていうのをセットで考えることが大切だと思いました。

過去のData Engineering Studyのアーカイブ動画

Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。

当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。

過去のアーカイブもYoutube上にございますので、ぜひご覧ください。

https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw