流通／小売 … "スモールデータ"のバッチ処理をHadoopで効率よく
～10時間かかっていた在庫計算を1時間に短縮
小売業の膨大なデータ
eBayやWalmartなど米国の流通/小売の大手企業が導入するHadoop事例は、文字通りビッグデータで、あらゆる部分にペタバイトや億単位の数字が並ぶ。こうした先進的な企業による事例、たとえば消費者の行動分析やリアルタイムな商品レコメンデーションなどはビッグデータのイメージを非常にわかりやすく伝えるものであり、逆にビッグデータでなければHadoopを使う意味がないというイメージさえ醸成されつつある。
実際、国内の流通/小売業者に聞くと「うちにはビッグデータはないのでHadoopのようなシステムは必要ない」という回答が返ってくることも少なくない。だが、Hadoopは本来、基幹業務のバッチ処理に適した並列コンピューティングシステムであり、スモールデータにおいても効率的であることがいくつかの事例で証明されている。ビッグデータはなくてもバッチ処理ならどこの企業にもあるはずで、Hadoopを適用することでその処理性能が改善する可能性がある。
現行の業務システムにおける最大のボトルネック、それはディスクIOだ。既存のRDBMSベースのシステムにおいては、ディスクの処理が追いつかないため、夜間バッチと言いながら夜間に処理が完了しないケースも多い。Hadoopはクラスタ内の各サーバにディスクIOを分散することで、IO性能を大幅に改善することが可能であるため、数十～数百ギガバイト程度の比較的小規模なデータでも、バッチの処理時間を大きく短縮し得る。月次のレポートを週次どころか日次、あるいはそれ以下で処理することも十分可能だ。
ある地方都市を拠点に複数の店舗を展開するBスーパーは、在庫管理がうまく回らないことによるコスト増大に悩まされていた。とくに商品発注のタイミングや発注量が店舗ごとにばらばらで、しかも発注担当者が商品の需要予測を大きく見誤るケースが増えてきており、大きな問題となりつつあった。商品発注はいわゆる担当者の"KKD(勘と経験と度胸)"にもとづいて行われがちだが、そうしたあいまいな判断が結果として不良在庫の増大や物流コストを押し上げており、このままの状態が続けば経営を圧迫することは疑いなかった。
在庫管理を最適化するにはいくつかのプロセスが必要となるが、BスーパーがNSSOLからまず最初にやるべきこととして推奨されたのは、夜間バッチとして10時間以上かけて行われていた在庫計算をHadoopにリプレースするという案だ。Hadoopに移行することで、クラスタ内の複数のサーバに処理を分散できるため、これまで10時間以上かかっていたバッチ処理を1時間以内に完了することが可能になるという。もしバッチ処理の時間が大幅に短縮できれば、発注担当者は直近の在庫情報をもとに発注を行うことが可能になる。出荷量の変動が少ない商品であれば、自動発注に切り替えることもできるだろう。PoCのエントリーを利用し、Hadoopで実装した場合の処理性能を測定すると、少なくとも10倍以上ののパフォーマンスでバッチ処理時間を短縮できることが判明している。
現在、Bスーパーはエントリーの検証内容をもとに、SQLをHiveに書き換える作業を進めている。懸案だったのは、バッチ処理システムがCOBOLで組まれていたため、アプリケーションをあらたにJavaで開発しなければならない点だが、既存コードを最大限に活かす方針で開発を行うことで、工程の省力化を図っている。
Hadoopディストリビューションには、基幹システムでの導入事例が多いCloudera社のCDHを選択した。在庫計算システムは扱うデータ量が500GB程度であり、決して多くはないが、Bスーパーにとっては日々の業務に欠かせないミッションクリティカルな領域でもある。仮にバッチ処理中にトラブルが発生すれば、業務に多大な支障が生じてしまうため、できるだけ信頼性の高いディストリビューションを選びたいという要望があった。CDHはBスーパーのような流通/小売のさまざまな基幹システムで使われてきた実績があるため、今回のシステムに適していると言える。
この在庫計算システムのHadoop実装が良い結果につながった場合、Bスーパーでは定番商品や季節商品の需要予測などへのHadoopの活用を検討している。半日以上かかっていたバッチ処理が大幅に短縮できれば、ユーザはその時間を別の業務にあてることができ、人的コストなども大幅に削減できる。Hadoopというとビッグデータの華やかな事例に目が行きがちだが、ギガバイトクラスのスモールデータでも、Hadoopの良さを十分に活かすことができるのだ。
