アルパインがSparkでカーナビデータ分析の実証実験。RDBよりも数十倍の性能と多くの知見を獲得
カーナビやカービジュアル製品を提供するアルパインは、近年ビッグデータ解析のオープンソースプロジェクトとして注目を集める「Apache Spark」を活用したビッグデータ分析の実証実験を、クリエーションラインと協業で行なった。
今回、この実証実験プロジェクトに参加したアルパインの黒田倫太郎氏と、Sparkのエンジニアとしてクリエーションラインから参加した木内満歳氏にインタビューを行った。
―― 今回のプロジェクトはアルパインさんから木内さんに直接コンタクトがあったということですが、そのきっかけを教えてください。
木内:アルパインの研究部門でエンジニアをしていた黒田さんがクリエーションラインのグラフデータベースに関するブログ記事を読んでいて、あるセミナーで私が登壇したセッションを聞いた黒田さんから、セミナー後に「ビッグデータに関してちょっと聞きたいのですが」という感じで質問を受けたのが始まりですね。
黒田:そうです。「カーナビのデータを使って何か新しいサービスを作れないか?」と考えていて、「どうしたらデータを分析できるか」をいろいろと検証していました。そのときはRDBにデータを入れて分析してみましたが、とても遅くて使い物にならなかったのです。
―― 「カーナビのデータ」というのは、GPSの座標や車の速度がどれくらいか、といったデータですよね。
黒田:そうです。実際には「どこから動き出して」「どれくらいの速度で走って」「どこで止まったか」といったものですが、このような多くのデータをそのままRDBに入れて処理していました。この処理がとても遅くて、RDB以外のNoSQLやグラフデータベースを調べていた時にクリエーションラインさんのブログ記事を読んで勉強したという経緯です。「これは直接訊いたほうが早いな」ということでセミナー後に木内さんを捕まえて、こちらのやりたいことをぶつけてみたという感じです。
―― なるほど。それでクリエーションラインと色々と打ち合わせなどを経て2015年の夏から実証実験のプロジェクトが始まったということですね。
木内:そうです。先ほど黒田さんがおっしゃったようにカーナビのデータには様々な種類のものがあって、数ヶ月分のデータは全部で数百GBにもなります。クリエーションラインは、このデータの中から用途に合わせて必要な部分のみを抽出し、要らない部分は排除したうえでグラフデータとして可視化してユーザの行動を分析する、というところまでを担当しました。
―― 実際にSparkが使われているのは、そのデータを加工するという部分ですね。
木内:はい。まずは最小単位であるデータセットから始めて、データの個数を増やしながら分散処理を行うサーバーのインスタンスも増やしていき、最終的に大規模なデータが来ても実用に耐え得るかを検証しました。―― 結果から伺いますが、実証実験は「成功した」と言って良いのでしょうか。
黒田:成功と言って良いと思います。Sparkの分散処理でカーナビのデータ分析をスケールさせることが実証されましたから。今回の実証実験では「こうなるだろう」という結果を想定して進めましたが、思ってもいなかった知見を得ることもできました。分析をやってみて良かったと思います。
―― システム的な話を伺いますが、今回はパブリッククラウド上にSparkとHDFSを構築したということですが、利用したのはどのようなサービスですか。
木内:今回はDigital Oceanのシンガポールリージョンを利用しました。このサービスはメモリとCPUとデイスクを割り当てて仮想マシンを作成するものですが、その上にSparkとHDFSを構築してリソース管理にはApache Mesosを使いました。
―― 通常の仮想マシンを利用するという意味では、アマゾンのAWSやグーグルのGoogle Could Computeなどがありますが、あえてDigital Oceanを使った理由は何ですか。
木内:今回は最終的にアルパインさんの社内サーバーに移行することが最初からわかっていたので、なるべくクラウドベンダー固有のサービスに依存しないようにDigital Oceanを選びました。最近のAWSやGCPだとマシンタイプなどの選択肢が多過ぎて使いにくいし、Elastic MapReduceなどのビッグデータ用に用意されているサービスを使ってしまうとそこから抜けられなくなってしまいます。Digital Oceanのサービスは本当に仮想マシンを作るだけで、あとは全部自分でやれるのが良かったですね。それと今回使用したストレージは全部SSDですが、それをある程度の価格で構成できたのも良かったと思います。
黒田:実際に最終的なソフトウェアは社内のサーバーに移行して、サーバークラスターで順調に動いています。初めて使ったDigital Oceanでしたが、選択は正しかったかなと思います。
―― 今回のシステム化で一番苦労したところは。
木内:最初にカーナビのデータから簡単に車の発進と停止を検出できると思ったのですが、それがうまくいきませんでした。つまり「どうもデータがおかしい」と。
黒田:実際にはカーナビがセンサーから受け取ったデータを正しく記録しても、センサーの値に誤差やタイムラグが入っている場合が数パターン発見されました。それらの生データを人間が理解できるようにキレイにする必要があったということです。
木内:例えば夜に車を停めて朝にまた動かしたとすると、本来は同じGPSの座標から動き出さなければいけないのにずれている。車が動き出した瞬間のデータなのに速度がゼロじゃない、つまりセンサーがデータを吐き出すちょっとしたタイミングのズレなどが出てしまった。そのままではうまく分析できないのでSpark側でかなり色々なクレンジング処理を行ないました。結果的にそれをグラフデータに整形して可視化や分析を行ったという流れです。
―― それは、根本的にカーナビのデバイスがちゃんとしたグラフデータを出す仕様になっていれば、もっと簡単になったのではないですか。
黒田:そのためにはデバイス側をだいぶ作り直さないといけません。「そのデータで何ができるのか?」をちゃんと考えて仕様を提案しないといけないということだと思います。
―― 通常、Sparkの場合は処理のロジックをScalaで書くのが一般的だと思いますが、今回ではPythonを採用した理由は。
木内:もともと私たちもScalaで書こうと思っていましたが、アルパインさんにPythonをかなり知っている方がいらしたこと、実際に調べてみたらPythonでも問題なさそうだったことからです。実際にやってみるとコンパイルが必要なScalaよりも実行結果をすぐに確認できるPythonのほうが向いていたと思います。分析システムは常に試行錯誤の連続だと思うので、「書いて実行して確認してダメならやり直し」がしやすいのは必要なことだと思います。
今回のプロジェクトは、アルパインにとって初めて使うパブリッククラウド、初めて使うOSSのSparkとMesos、初めて付き合ったSIerのクリエーションラインと、「初めてづくし」だったという。そのチャレンジを見事に乗り切ったアルパインだが、実際のサービスとして実を結ぶまでにはもう少し時間がかかりそうだ。
引き続き、アルパインの挑戦に注目していきたい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Spark Streamingの概要と検証シナリオ
- 分散型データストアApache Kuduの特徴とユースケース
- Spark 2.0を活用した配電設備の負荷集計システムの性能検証
- BBTowerがクリエーションラインと協業、EMCアイシロンを利用したHadoopプラットフォームの構築とサービス提供を発表
- HBaseの概要とアーキテクチャ
- ビッグデータ処理基盤に対応したFDWの紹介とhdfs_fdwの設計・構築の紹介
- 先進ユーザーがリードするHadoop/Spark応用事例~Sparkで5倍の性能アップ~
- 米MSがBashシェルをWindowsに搭載、Emac、VT100などをサポート [Build 2016速報]、ほか
- JavaScript用パッケージマネージャYarnが公開、MySQL次期メジャーバージョン8.0登場、など
- Sparkのデータ処理プロセスと処理性能のボトルネック