認知度が高まっているが、まだまだSparkの活用例は少ない
「本セッションではあくまでもSparkとKafkaを使ってリアルタイム基盤をどう作っていくのか、従来のHadoop基盤と比べてどういうメリットがあるのかについて説明する。したがってプログラマよりは、アーキテクチャに携わる方向けの内容となる」
こう最初に宣言し、田中氏のセッションは始まった。田中氏は現在、IBMでHadoopやSparkを使った解析基盤の構築に携わっている。前職ではWeb系の会社で大規模アーキテクチャ設計や実装、サーバサイドプログラム、フロントエンドプログラムを担当していたこともあり、いわゆるフルスタックエンジニアである。
これまでビッグデータの処理基盤として用いられてきたのがHadoopである。Hadoopの認知度は非常に高く、会場でもそれなりの人数の方が「業務ですでにHadoop基盤を使っている」と手を挙げていた。そして一昨年ほど前から注目を集めているのが、Sparkである。
Sparkは当初、イノベーターやアーリーアダプターを中心に注目を集め、今ではアーリーマジョリティ、レイトマジョリティへの広がりを見せつつある。とはいえSparkを業務で利用している会社はまだまだ少ないが「昨年末より事例も登場してきた」と田中氏は語る。
HadoopやSparkの認知度の向上の背景には、ビッグデータの広がりがある。「ソフトウェアはもちろん、ITコンサル、金融系、ハードウェア系、教育分野、医療分野、通信キャリア、広告、ECなどというように「いまや特定の分野ではなく、さまざまな業界を横断してビッグデータは展開されている」と田中氏。もちろん、ビッグデータといっても業界によってそのデータ量はさまざまだが、たとえば数千万PV、数億PVのコンテンツを有するWeb系システムでは、単純なサーバログだけで1時間に数GB～数十GB、1日に換算すると100GB近くのログが吐き出されることになる。そのほかにもユーザーログやアプリケーションログなども収集できる。
ログデータだけではない。Webサイトデータ、センサーデータ、ログデータ、カスタマーデータ、オフィスデータ、オペレーションデータ、ソーシャルデータなどを収集し、これらのデータを組み合わせて分析したり、高度な機械学習をしたりして新たな価値を生み出そうというのがビッグデータである。数十～数百TB級を分析するための基盤技術として採用されてきたのが、「Hadoopを中心としたHadoopエコシステムだ」と田中氏は語り、基盤アーキテクチャの説明へと入った。
オーソドックスなHadoop解析基盤では何が問題なのか
オーソドックスなHadoop解析基盤は、Hadoop（HDFS＋MapReduce）とHadoop上でSQLを扱うHiveや機械学習を扱うMahoutで構成。これにより、単位時間当たりに集めたデータをHadoop上のHiveやMahoutで1日数回の頻度で解析を実行し、ストレージやBIに反映できるようになる。「以前はこのような基盤を提案してきた」と田中氏は語る。というのも、1つのRDBで保存不可能な大量データがHFDSを利用することで保存が可能になること、保存したデータに対し、分析や機械学習が現実的な時間で実行可能になるからだ。
しかし「このオーソドックスな基盤には問題点もある」と田中氏は指摘する。それは「データを受け取りHadoopへ格納する際のタイミング。この基盤だといずれの場合も数時間に一度データをインプットする形となり、この遅延はリアルタイム分析基盤構築のための枷になる」と田中氏は言う。
それだけではない。データを処理する部分やデータを反映する際にも問題があるという。データ処理する部分については「HDFS上のファイルをMapReduceで処理するものはディスクアクセスが多くなるため、レイテンシも高くインタラクティブな処理やリアルタイム処理には不向き」、データ反映についても「データ反映をRDBにする場合、書き込み不可の時間帯を外さないと別システムの足を引っ張るなどの考慮事項が増え、生産性が悪くなる」と田中氏は言う。
