残念なビッグデータの例
マインドテックの冨です。
ビッグデータブームも落ち着きをみせ、最近はIoTだ、FinTechだと、別のキーワードにトレンドが移っているようです。そんなこともあって、以前ほどは「データ分析、いぇい！」なシーンも減ってきているかと思いますが、特にIoTではリアルタイム計測～リアルタイム処理と分析の難易度が上がってきています。Apache Sparkだ！MQTTだ！とか、いろいろと聞こえてきます。そんな中でもデータ処理関連のご相談を時々受けるのですが、少しヒアリング＆サンプルを見せて頂くと、「これはシンドイなあ・・・」と思う案件がいくつかございます。（知人では「データ分析案件で出てくるデータの9割以上はゴミだ！」と言い切る人もいます。）
そんな中で「こんなデータは嫌だ！」というケースをいくつかご紹介して、他山の石と頂ければと思います。（もちろんフィクションです。かなりを脚色していますが、似たような事が起こっています・・・）
1．そもそもデジタル化されていない
「うちには大量にデータがあるから」と出かけていくと、大量の段ボール箱に入った記録シートなどがお目見えするシーンです。思わず涙がこぼれそうです。これらを実際に分析の俎上にのせるには、データの手打ちでの移し替えが常です。最近はOCRの精度も良くなってきているので、昔と比較したら格段に作業効率は良くなっているのですが、センサーの設置地点ごとに記録表の表組が変わっていたりすると目まいがします。
当然、手打ち写経で打ち間違いなどの作業ミスも発生しますし、なかなか困難を極める現場となりますね。
2. フォーマットがバラバラ
取得した時期、拠点などで、フォーマットが異なっていたりすると、単純にデータストアにロードできず、整形など何らかのプレ処理が必要になります。こちらも最近はETLなどのローダーが普及してきていますし、インポート処理も親切な作りになっているツールも多いので、何らかのデータストアに格納されているものであれば、変換は容易になりました。単純に数字だけといったものは意外とやりやすいのですが、手入力したコメントのような文章が入ってくる平文のテキストファイルだとツライ事が多いです。’ や " 、, ：; スペース、タブ文字など、どんな文字でも入りうると、正規表現を駆使してもデータの区切りを定義する難易度が跳ね上がります。レコード数が多いと「おお！やっと入った！」と一時的に安心しても、途中から列がずれているのを見つけて落胆すること数限りありません。
3. データの連結を考慮していない。
最近のアドテク関連は、いかにしてデモグラ情報と行動ログを関連づけるかとか、同一人物が違うデバイスを使った時の記録をどのように突合させるかなど、データ連携をさせるための工夫の歴史といっても過言ではないと思います。そんな中、結合に必要なキー情報（会員番号とか、機器の識別コードとか）が無い状態で、「年齢別とか男女別の売上比を出してみて」と言われましても、どうしようもないんですね。あとから追加できる情報ではないため、お手上げ状態になります。
似たような例としては、名寄せを全く考慮していないケースもあります。例えば「NTT東」「NTT東日本」「東日本電信電話株式会社」は一般的に同一会社とみなされます。これを何も前処理をしないで単純に集計すると、異なる3つの会社があると見なされるんですね。そうすると結果を見誤る事になります。こちらもデータ名寄せを支援するためのツールやサービスも出てきていますが、もともとはデータ取得時に考慮されているとベストです。
4. 必要なデータが取れていない
データマイニングといった探索的な処理の場合には、あまり表だった問題にならないわけですが、知りたい集計結果、KPIを出すために必要なデータが、なぜか取れていないというケースが、ちらほら見かけます。分かりやすい例えでいうと、コンビニの売り上げ分析で「年齢別」「男女別」の集計をしたいというニーズがある場合、レジに登録する際に「＊＊歳台」「男性」といった情報も併せて登録する必要があります。または「”＊＊ポイントカード”はお持ちですか？」といった具合に、カードの登録情報と上記のような名寄せを行って得られる場合もありますが、いずれにせよ、何らかの手段でデータ化しないと分析に使えないわけです。
この逆もしかりで、欲しい分析結果に関連性が薄いデータを大量に渡されることもあります。「とりあえず何かの役に立つかもしれないから」と言われましてもねえ。
5. 欠測が多い、精度が怪しい
データ前処理の段階で、クレンジング等を行う際に、ひとまず仮にデータを可視化して傾向を見るといった作業をすることが多いです。その際に極端に大きい／小さい値を異常値として取り除く事があります。すると、明らかに異常値だらけというデータを見つける時があります。センサーの管理が無茶苦茶だったりするわけですね。同様に欠測期間がやたらに長いものが見つかることもあります。メンテナンス期間とか停電など、ある程度の期間に固まっているとかであれば、比較的対応しやすいのですし、一時的な欠損であれば前後の値の平均を暫定的に使うなどで処理できます。ついでに言うと、データソースが複数にわたっている場合、それぞれの時計が同期しているかも重要です。
現場のトラブルは挙げていくとキリがないわけですが、他には保存メディアに関するトラブルは比較的多いですね。保存したCD-ROM, DVD-ROMが読めなくなったなどが典型例ですね。(「"MOドライブ", “zipドライブ", “DATテープ"に入っているんだよ」みたいな希少メディア関連は、最近はほとんど無くなりました 🙂 ）
こんなわけで、ただただ「大量にあるデータを使って、何かうまい事を言ってみせろ。ビッグデータだろ」的なケースにおかれましては、しばしばご期待にお応えしかねるケースも出てくるわけですが、逆に言えば、これからのデータ分析プロジェクトにおいて、欲しい成果が決まっているのであれば、それに合わせる形で分析手法、取得データの設計をされるのが望ましい限りです。