[GEOTRA 森山氏]ビッグデータ生成処理の失敗と挑戦 #データ負債解消

Connpass詳細はこちら

アーカイブはこちら

資料はこちら

本日はビッグデータ処理でデータ量で苦しめられた経験を発表させていただきます。

まずGEOTRAはGEOTRA Activity Dataというサービスをメインでやっています。このデータ自体は一般的に人の位置情報のデータを提供していて、街中の生活者1人1人の動線が分かる人流データを販売しております。

データフォーマットにある通り、Machine Learningで秘匿化の問題をクリアしつつ、1人1人の移動がわかる非集計のトリップデータを提供しています。

データはIDで識別します。例えばID034の方が朝の時間帯に通勤で車を使ってある場所からある場所に移動しました。その方が8時にどこへ行った、というデータを持っています。

そして地図アプリ自体もGEOTRAで提供していまして、こちらは日比谷公園に来訪された方の人流データです。黄色の範囲が日比谷公園にいらっしゃる方の出発地の多い場所で、近隣が多めです。

左側のグラフはそこにいらっしゃる方のトリップの情報や属性情報、性別、年代を出しつつ、どこから来ているかといったデータになります。

Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です

【かんたん30秒】無料登録で転職相談する

GEOTRA Activity Dataによる移動目的の推定

GEOTRA Activity Dataには移動目的という項目を追加していて、トリップエージェント(IDが付いている方 )が移動した時の移動目的をデータの中に付与しております。

付与するロジックは基本的に到着地点です。例えば、病院に行っていればHospital(通院)が目的だと判断します。

先ほどのHospitalのようなデータはPoint of Interstデータと呼ばれるのですが、建物が何かで移動目的を切り替えています。例えば、ラーメン屋→Eat、会社→Work、 小売事業者→Retail、病院→Hospitalといったデータをトリップデータとは別に日本中の様々な建物情報を持っています。

移動目的を紐付ける際はトリップデータとPoint of Interestデータを掛け合わせて、トリップデータに対してPoint of Interestデータのどれが1番近いのかを処理しています。

そうすると、トリップデータ数がn個でPoint of Interestデータがm個あったら単純計算でn×m通りのパターンが存在するので、数が膨大になればどんどん増えていくのは容易に想像できるでしょう。

データの増加により処理時間が膨大に

その後、想像通り処理時間が雪だるま式に増えていくという課題にぶち当たりました。

元々事業を開始した際は基本的に街や市単位のデータだったので、ある程度お客さんの方で対応できていました。しかし、お客様に色々データを提供していくと、今度は都道府県でデータを欲しいというお客さんもいて処理時間が伸びていきました。

複数の都道府県になると処理時間もさらに増えていって、最終的には2週間経っても処理が終わらない状態になりました。

以降は試行錯誤の日々で、まずはクラウドのインスタンスサイズを4倍くらいに変えても全然変わりませんでした。

他にもトリップを64分割して分散処理したりしてもまだ変わりませんでした。

そして、最終的にトリップデータとPoint of Interestデータの両方を分割してようやく短縮できました。それぞれ64分割して並列処理で回していくと、現実的な処理時間となったんです。

今回のように対応エリアが増えた数だけ、Point of Interestデータは増えます。 処理をある程度早くするためにエリア単位でくくって、ここに来た人の2分の1の確率でこの人は病院に来た、3分の1で仕事に来た、といった処理を入れていました。

この移動の確率分布を複数の都道府県全部で見ていましたが、例えば、東京の千代田区にいる方のPOIを見つけたいのに、全然違う埼玉県のある市のデータの処理をやっていて時間がかかっていたりしました。なのでしっかりと分割して処理することが大事だと分かりました。

視聴者からの質問に答える質疑応答タイムへ

――ここからは、視聴者の方からの質問に回答していきます。まず1つ目は、「データ構造の負債を解消するために専用のメンバーを配置しているのでしょうか、それとも開発メンバーが機能アップデートと並行して進めているのでしょうか」という質問です。陳さんからご共有いただけますか。

陳:我々は全て同じメンバーがやっています。なぜなら、ここを分けると背景がわからないメンバーも入ってきてしまうからですね。 基本的に解消する際は短期間で皆で一緒にやり切るという形で進めています。

――続いてtocknさん、お願いします。

tockn:弊社も同じで、特に負債解消の専門チームは置いていません。プロダクトを開発するメンバーが解消しています。クォーターの最初の2週間は非機能系の改善に当てるといった改善ウィークも設けたりして、色んな方法でプロダクト開発と共に並行できる施策を練っている感じですね。

――続いて大島さん、お願いします。

大島:Nayose Groupは歴史が長く大きいチームになっていて、その結果システムとしても大きくなってしまいました。そのため、チームを分割してより改善しやすくなる構造にしています。

――続いて森山さん、お願いします。

森山:弊社も機能アップデートと並行してやっていますね。 開発を進めるか、負債を解消するかを天秤にかけていて、場合によっては負債の解消を優先しています。

――最後に弓場さんはお願いします。

弓場:フツパーもチームを分けてはいなくて、開発メンバーが担う体制で今はやっています。

――続けて、「どれぐらいの時間をかけて負債を解消してきましたか」とのことですが、陳さんからお願いできますか?

陳:基本的には2〜3週間でやりきることを徹底しています。 何か行動的に問題が発覚した場合は一旦開発を止めて2〜3週間で全部やりきって、無理にその先に進まないという判断をしてきました。 短期間で細かく、問題があるところだけ集中的にアタックする形ですね。

――続いてtocknさん、お願いします。

tockn:先ほどの回答と被りますが、改善ウィークみたいな形で1週間〜2週間を改善の期間に当てていますね。あとは、クォーター単位でプロダクトや非機能系の開発も含めて何をやるのかを整理する段階で期間を当てはめたりしています。

――続いて大島さん、お願いします。

大島:細かいところは2週間くらいの短期間でやって、 どうしても歴史的経緯で大規模改修が必要なタイミングであれば半年〜1年ぐらいかけて、現在動いているものをリプレイスする形です。

――続いて森山さん、お願いします。

森山:大体メンバーは複数人いるので、一人が負債回収して、もう一人は機能開発という感じでやっていましたね。負債回収をやると大体1ヶ月ぐらいかかります。それぐらいで今回の課題などは対応していました。

――続いて弓場さん、お願いします。

弓場:今回発表したデータベースの移行に関してはいきなり全部を変えるのではなくて、ステップを区切って1ヶ月単位で行いました。

――本日のイベントはこちらで終了とさせていただきます。 登壇者の皆さん、視聴者の皆さんありがとうございました。


Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です


この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

イベントレポート

転職