人流データ計測の為のデータ分析基盤の改修 - デジタルマネージ・ウィズエー様
実績紹介
こんにちは。
今回は、弊社が実際に取り組んだ案件の紹介をしたいと思います。
デジタルマネージ・ウィズエー様の、データ分析基盤の改修を支援させて頂きました。
今回改修した基盤は、AWSで構築したものです。
EBPMに用いる人流データの収集と、人流データを可視化するデータ分析基盤
EBPM（Eveidence Based Policy Making）とは、政策立案や政策評価で用いられる手法で、データをエビデンスとして用いて、本当に実効力のある政策を立案したり、評価していきましょうというものです。
自治体向けにEBPMサービスを提供されているデジタルマネージ・ウィズエー様は、人流データを使用してEBPMサービスを展開しています。
今回の人流データは、駅構内の人流データを取り扱ったものであり、自治体を始め、民間企業向けのデータも外販しています。
この人流データの収集方法は、IoTデバイスを使用して収集したものであり、大量のログが発生します。
その為、日夜IoTデバイスのログが基盤へ蓄積されていくことから、データ量は膨大になっていきます。
デジタルマネージ・ウィズエー様のデータ分析基盤は、大手SIerにPoCとして構築してもらったものでした。
その後、サービス展開当初からクライアントもデータも増えていき、ビジネスを取り巻く環境が変化していった結果、PoC当初のデータ分析基盤ではサービスが立ち行かなくなっていました。
アーキテクチャとAWS製品の見直し
デジタルマネージ・ウィズエー様の基盤は、AWSとtableauによって構成されていました。
その為、既存の構成を踏まえた上で、弊社としてスコープとしたものは以下になります。
①アーキテクチャの見直しと、使用するAWS製品の見直しを行うこと
②生成された論理テーブルを物理テーブルで持つこと。
③IoTデバイスから吐き出されるログ（Jsonファイル）の読み解きと物理テーブルとして展開すること
どうしてスコープを上記3つに絞ったのかについて、既存のアーキテクチャを引き合いに出しながら説明していきます。
PoCフェーズのアーキテクチャでは、S3がIoTデバイスのログを格納するデータレイクとしてありました。
その上で、S3からAmazon Athenaへデータが連携され、Amazon Athenaでログが論理テーブルとして出力され、その論理テーブルをtableauのデータソースとしていました。
ちなみに、Amazon Athenaとは、AWSが提供するインタラクティブなクエリサービスであり、SQLを使用してAmazon S3に直接データを分析できるツールです。
Amazon Athenaは、サーバーレスであることからインフラの管理が不要であり、データ量に応じて支払う従量課金型のサービスです。
しかしながら、データ分析基盤や大規模なWebアプリケーション開発をしてきた方々ならご存知の通り、膨大な量のデータを処理しなければいけない場合、データソースとするテーブルは物理テーブルで保持すべきです。
これは、物理テーブルには直接データが格納されている為、クエリ実行時のオーバーヘッドが少なくなることに起因します。
これによって、物理テーブルをデータソースとすることは、論理テーブルと比較してデータの取得やクエリの実行速度が速くなります。
また、デジタルマネージ・ウィズエー様の場合、S3に格納されているデータはJSON型であり、ネスト構造のデータを展開しつつ集計するといった膨大な計算量が必要でした。
その為、事前に計算できる部分を予め処理しておく必要性があったのですが、既存の構成はEBPMのPoCフェーズということもあり、事前の前処理なくAmazon Athenaで論理テーブルを生成し、それをデータソースとしていました。
その結果、tableauの表示速度が遅延する他、論理テーブルを生成する段階でもタイムアウトが発生していたのです
上記のことを踏まえた上で、アークテクチャを見直し、今後のビジネスのグロースに合わせてAWS製品を選定し直そうと思いました。
具体的には、アーキテクチャの中で中間テーブルを持たせてETLを行う為に、Amazon Athenaの代わりにAmazon Redshiftを導入することにしました。
IoTデバイスから吐き出されるJsonファイルの読み解きと、物理テーブルとしての展開
IoTデバイスから送信されるデータはJSON形式で4重の入れ子構造になっていました。
Athenaで行われていた処理に関して、データ分析基盤の仕様書はなく、カラムの意味は誰にも分からない状態でのスタートとなりました。
IoTデバイスのベンダーが公表している公式のドキュメントと、データ分析基盤から出力される実際のデータを見比べながら、データの読み解きとBI表示に必要なカラムの精査を行いました。
データの読み解きの中で、S3からRedShiftにデータを移行する際に、JSON形式のデータをどのように扱うかという問題がありました。
具体的には、JSON型のデータを完全にフラットな形式（すべてのネストを解除した形式）で保存するべきか、それともSUPER型として半構造データのまま格納するべきか、という問題です。
BIのパフォーマンスを向上させる為には、データソースとなるテーブルのカラム数を最小限に抑えることが重要です。
その為、JSON型のデータをフラット化する際に不要なカラムを省いたデータマートを作成しました。
その一方で、省かれたカラムは今後の利活用を見越して、RedShift内に下記のような形でテーブルを設けました。
1. S3からJSON形式のままデータを格納するテーブル（データレイク）
2. JSONを全てアンネストした、全てのカラムを持つマスターテーブル（データウェアハウス）
3. BIのソースとなるテーブル（データマート）
また、S3からデータを格納し、マスターテーブルとBIのソーステーブルに差分を挿入する処理を日次で行うシステムとして、ある程度のリアルタイム性も担保しました。
最後に
いかがでしたでしょうか？
データの読み解きは、データエンジニアリングの肝要な点の1つです。
データの読み解きの正確さと、それを物理テーブルとして持つことは、BIの表示速度からAIの予測精度に至るまで関係しています。
また、データの読み解きを間違えると、企業が損失を招く場合もあります。
例えば、製造業のお客様は、製造原価を把握した上で商材の価格を決定しています。
その為、原価と粗利を計算し、適正価格を付ける為に、BIで製造原価をモニタリングしたいといったお客様が数多くいらっしゃいます。
この時に、製造原価を算出する為に使用するデータやその読み解きを間違えると、不正確な原価がBIに表示され、不正確な原価で商材の価格が決まります。
その結果、本来得られた筈の粗利よりも少ない粗利しか入ってこない場合、そこに企業の損失が発生します。
上記の例以外にも、会計領域で同様の事象が起こり得ることを想像してみて下さい。
（恐い話ですが、某大手コンサルティングファームが誤ったデータの読み解きをしてしまい、クライアントのデータ分析基盤をスクラップにしてしまったり、某大手AIベンダーが、誤ったデータの読み解きでAIを実装し、実際の業務で運用されそうになっていたケースも見てきました（そして、その改修をする為に駆り出される））
大規模開発は勿論ですが、データエンジニアリングはその性質上、責任が伴うセンシティブな業務であるとともに、高度なスキルセットが必要です。
ただ、データの読み解きは大変な一方で、知的好奇心を刺激し、難解なパズルを解いたような達成感もありますし、ビジネスインパクトにも繋がってくる為、やり甲斐は一層です。
データエンジニアリングの大変さは、意外にまだ知られていませんが、HOUSE OF DATAがデータサイエンスは勿論のこと、データエンジニアリングの必要性と重要性を発信していけたらと思います。
弊社では、数多くのデータ分析基盤を構築してきたデータエンジニアが多数在籍しています。
製造業における製造原価をモニタリングする為のBIや、営業の予実管理をする為のBI、広告代理店における広告のROIを管理するBIから、金融機関や保険会社といったセキュリティ要件が高い企業様の支援にも携わってきております。
データ分析基盤や、データ基盤でお困りごとがございましたら、是非HOUSE OF DATAへご一報下さい。
Discussion