物流データはどこに置けばいいのか？
—データの種類と使い方から考える保存先
・なぜデータの種類によって保存方法を変える必要があるのか
・保存先を判断するときに見るべき7つの軸
・3年前のデータと今日のデータを、同じ方法で比較できるか
保存先の検討は、しばしば技術の選定から始まります。しかし選定の前に決まっていなければならないことがあります。何を、どれだけの期間、誰が、どう使うのかです。
これが決まっていない状態で保存先を選ぶと、次のようなことが起こります。
「分析用にすべてのデータを1か所に集めました。ただ、集計に毎回30分かかります」
生のログから毎回KPIを計算し直しているため、画面を開くたびに時間がかかる。ダッシュボードは作ったものの、待たされるので使われなくなる。
「速く見られるように集計値だけを保存しています。ただ、去年の内訳は追えません」
集計後の数字だけを残したため、細かい単位に戻れない。「なぜこの数字になったのか」を確認できない。
この2つは、どちらも保存方法の選択が用途と合っていない状態です。そして両方を同時に満たそうとすると、保存先は1つでは足りなくなります。
1. なぜ保存方法を変える必要があるのか
基盤の中で扱うデータは、種類ごとに求められることが違います。
| データ | 主な用途 | 考えること |
|---|---|---|
| 生ログ | 後から再分析・監査 | 保持期間・容量。ふだんは読まないが、消せない |
| 整形済みデータ | 分析・集計 | 検索性・加工性。条件を変えて何度も取り出す |
| KPI・集計値 | BI・意思決定 | 参照速度・更新頻度。多くの人が繰り返し見る |
この3つは、性格がまったく違います。
だから、保存先も一つとは限りません。
逆に言えば、すべてを1か所に置いて問題が出ないなら、分ける必要はありません。データ量が小さく、利用者が数人で、参照も日次で足りる規模であれば、単一の保存先で十分です。分けるのは、1か所では無理が出たときです。
シリーズの順序として、ここまで扱ってきたのは「どう関連付けるか」「どう品質を保つか」「いつ処理するか」でした。置き場所を最初に決めようとすると、何をどう使うのかが決まる前に構成が固まります。
用途が見えた後に置き場所を決める、という順序を維持する方が、後戻りが少なくなります。
2. 結果として、保存先の種類が分かれる
用途による性格の違いから、実際に使われる保存先はいくつかの型に分かれます。ここでは対応関係だけを示します。
| 保存先の型 | 向いているもの | 性格 |
|---|---|---|
| データベース（DB） | KPI・集計値、参照頻度の高いデータ | 決まった形のデータを速く取り出す |
| データウェアハウス（DWH） | 整形済みデータ、分析用のデータ | 大量のデータを条件を変えて集計する |
| データレイク | 形が定まっていないデータ、加工前のデータ | 形を問わずそのまま受け入れて溜める |
| オブジェクトストレージ | 生ログ、画像、長期保存が目的のデータ | 容量あたりの費用が低く、大量に置ける |
それぞれの技術的な仕組みは、ここでは扱いません。重要なのは、これらが「どれを選ぶか」という択一の選択肢ではないことです。生ログはオブジェクトストレージに、分析用はDWHに、KPIはDBに、というように併用されるのが通常です。
用途——何を、どれだけの期間、誰が、どんな速さで使うのか——が決まれば、置き場所の候補はかなり絞られます。
3. 保存先を判断する7つの軸
実際に置き場所を決めるとき、見るべき点は次の7つに整理できます。
現在の量で判断すると、拠点追加やセンサー増設で行き詰まります。判断すべきは、想定される増加を含めた量です。
1か月なのか、3年なのか。監査や契約上の要件がある場合は、そこが下限になります。要件がない場合でも、季節変動を見るのであれば、1年程度は残しておくと比較しやすくなります。
分析担当者が数人で条件を変えながら使うのか、現場の管理者が数十人で同じ画面を開くのか。後者は参照速度が重要になります。
止まると現場の作業が止まるのか、翌日に見られれば問題ないのか。求める可用性は費用に直結するため、用途ごとに分けて考える必要があります。
設定変更、容量の追加、障害時の対応を誰が担うか。自社に担当を置けるのか、任せるのか。これは技術選定と同じくらい重要な判断です。
保存に関する費用は、量と期間の掛け算で増えていきます。導入時点の額ではなく、3年後の状態で見る必要があります。
4. クラウドかオンプレか、任せるか自前か
上の7軸に加えて、大きな方針として2つの判断があります。これも用途から決まります。
| 判断 | 選ぶ理由になるもの | 注意する点 |
|---|---|---|
| クラウド | 量が増える前提。拠点追加に対応しやすい。初期投資を抑えたい | 量と期間に応じて費用が伸び続ける。通信が前提になる |
| オンプレミス | 現場で完結させたい処理がある。持ち出しに制約がある | 容量の増設に手間がかかる。機器の更新が発生する |
| 任せる（マネージド） | 運用に人を割けない。立ち上げを早くしたい | できることが提供範囲に収まる |
| 自前で構築 | 独自の要件がある。既存の資産を活用したい | 維持と更新を自社で担い続ける必要がある |
ここでも、全体を一律に決める必要はありません。現場のリアルタイム処理は現場側に置き、分析用のデータはクラウドに集約する——という組み合わせは、物流現場では自然な形です。
ここまでの判断軸が定まっていれば、具体的な製品やサービスの比較は絞り込みの作業になります。逆に、軸が定まっていない状態で製品比較を始めると、どれも「できる」と書かれているため決められません。
先に決めるべきは、自社の用途と制約です。
5. 保持年数とコストは、必ず一緒に考える
保存先の設計でもっとも見落とされやすいのが、期間と費用の関係です。
データ量は、1日あたりの発生量が同じでも、期間の分だけ積み上がります。1年で問題なかった量が、3年で3倍になります。しかも拠点やセンサーが増えれば、1日あたりの量そのものも増えます。
ここで問われるのは、3年前のデータと今日のデータを、同じ方法で比較できるかという点です。
費用を抑えるために古いデータを集計値だけにまとめた場合、3年前のデータは細かい単位で見られなくなります。そのとき「今年と3年前を工程別に比較したい」という要望が出ると、比較の粒度を今年側に合わせて粗くするしかありません。第3回で触れたとおり、集計してしまったデータは細かい単位に戻せません。
そのため、実務的には次のような整理をしておくことになります。
「いつまで、どの細かさで持つか」を決めることです。
まとめ：置き場所は、用途の結果として決まる
生ログ、整形済みデータ、KPIの集計値。この3つは、読む頻度も、量も、求められる速さも違います。だから、同じ保存方法では無理が出ます。保存先が複数に分かれるのは、設計が複雑だからではなく、用途が複数あるからです。
判断の軸は、データ量、保持期間、更新頻度、利用者、可用性、運用負荷、コスト。そしてクラウドかオンプレか、任せるか自前か。いずれも「何にどう使うか」が決まってはじめて判断できます。
「何にどう使うか」から置き場所を決める。
ここまでで、つなぐ・関連付ける・品質を保つ・処理する・蓄積するという要素が揃いました。しかし、基盤は作った日が一番よく動きます。センサーは壊れ、WMSはバージョンアップで項目が変わり、拠点は増え、データ量は増え続けます。次回は、止まる・変わる・増えるへの備えを扱います。
何年分をどの細かさで持つか、参照頻度が下がったデータをどう扱うか、拠点追加でコストがどう変わるか——保存の設計は、比較したい期間と利用者の要件から決まります。現状のデータ量と使い方を整理するところからご一緒できます。
「とりあえず全部残しているが、この先が不安」という段階からでもご相談いただけます。
お問い合わせはこちら