設備のセンサー、購入履歴、操作ログを集めると、データの件数だけでなく、届く速さや形式の違いも処理上の問題になります。
ビッグデータは、大きな量、多様性、生成速度などの特性によって、保存や処理、分析の仕組みを拡張する必要があるデータを扱う概念です。
何件以上なら該当する、という一律の件数で決まるものではありません。

量以外に確かめる性質

たとえば、工場の設備監視では、日次の点検表と、短い間隔で届く温度の測定値では扱いが違います。
後者は、到着の遅れや重複、通信が切れた期間も考慮しなければ、同じ時刻の状態を比較できません。
画像や文章を合わせるなら、測定値と結びつける識別子も必要です。

  • 量:保管量と、必要な時間内に処理する件数。
  • 多様性:形式、単位、記録の粒度、発生元の違い。
  • 速度:生成される頻度と、判断までに許される時間。

これらを見て、集計をまとめて行うか、到着に応じて処理するかを決めます。
拡張できる構成を選んでも、何を測ったデータかがわからなければ、分析の前提は整いません。

製品判断につなげる例

仮に、故障の予兆を知らせるサービスを作るなら、初めに「何分前に、どの故障を知らせたいか」を決めます。
その判断に必要なセンサー、故障の記録、対象設備を選び、まず限られた範囲で予測できるかを確かめます。
すべてのログを先に蓄積すると、保存費用が増える一方で、正解となる故障記録が不足していることもあります。

データ量が増えても、特定の設備しか含まれない偏りは自動的には解消しません。
また、同じ設備の連続した測定値を無作為に分けると、過去の状態を覚えただけのモデルを高く評価する可能性があります。
時間や設備単位で、学習と評価の条件を分けて考えます。

収集の前に決めること

用途、保存期間、更新頻度、利用する担当者を整理し、取得から削除までの費用を見積もります。
小規模なデータベースで答えられる問いなら、その構成から始める選択もできます。
データの意味と品質を確認する仕事は、大規模な処理基盤でも必要です。

参考資料