【勉強会】SparkSummit2016報告会＆データ分析勉強会
Learning Data Science with SparkR
- リクルートテクノロジーズ 石川さん
Databricks Cloud Community Edition
SparkR
GLM in SparkR
- Spark1.5からMLlib
- GLM：Generlized Liner Models、線形モデル
- RFormula
- RMSE、Root Mean Squared Error
Sparkとは、分散クラスターでのビッグデータ分析をインメモリーで高速に行うOSS 米Databricksは、その開発の中核を担う企業 Sparkを開発した米UCBの研究組織AMPLabからスピンアウトして、2013年に設立されたベンチャー企業
Spark MLlibをつかったアクセスログパターン解析事例
- NHNテコラス 佐藤 哲さん
クラスタリングによるデータ解析の事例
背景
- WebのHTTPアクセスのユーザ属性が知りたい
- 仮説：アクセス時間帯、アクセス先、アクセス回数が似ている
- ログから抽出Spark
- 類似度計算結果格納HBase
- クラスタリングMLlib
- MapReduceだと３段階必要なところ、Sparkなら一発でかける
ETL（前処理）
類似度計算
- ユーザ属性の距離
- 圧縮プログラムを使った類似度計算
- CDM、Compression-based Dissimilarity Measure
- NCD、Normalized Compression Distance
- 計算結果をHBaseに格納
- ユーザ間のNCDを全て計算すると、距離行列ができる
クラスタリング
- アルゴリズムはPIC、Power Iteration Clusteringを使用
まとめ
- Sparkは多段処理がMRに比べ楽で性能がいい
- Hadoopは勝手に負荷をコントロールしてしまう
- Sparkの方がスペックをフルに使う
IoTの現場で利用されるSparkアプリのアーキテクチャ
- Hortonworks 今井雄太
- 主に自動車系のIoTの事例
HadoopSummitでのSpark
- Netflix、4000台
- ETLをYARNの上でSparkを動かす
- Spark Streamingはどこにいってもディスられてた
- Yahoo!Incのデータ処理パイプラインで比較
- Spark StreamingとFlinkとStormを比べた話、SparkStreamingの一人負け
- 逐次処理ならSparkStreamingじゃない
HDP：Hortonworks Data Platform HDFS+YARNがHadoopのコア SparkもYARK上
データアプリケーション
訴求的分析
リアルタイム
- 近い過去に対する処理
予測
- 未知のデータ、未来の事象
業務モデル
- 車からセンサーデータを収集
- 物流会社、トラックがどこにいて、どのくらい継続して運転してるかとか
- FUELマネージメント、燃費の効率化
- 速度、気圧、気温、降水量、トラフィックカメラ
- PredictiveMaintenance、車が故障する前にメンテナンスをする
Architecture
- NewYorkが地下鉄の情報をパブリックデータとして公開してる
- Apache NiFi（データ移動のマネジメント）
- Kafka（MessageBroker）リアルタイムに取り込むライン
- HDFSとかS3に静的情報を保存、リアルタイムフィードも必ずストレージに保存
- Source of Truth Netflixがよく言う
- HDFSのデータを機械学習に通して、HBaseに追加、回帰分析情報を出したり
- HDFSからHive/SparkSQLでBIツールへ
- 悩み
- EtoEでのメタデータやスキーマの管理
- リファレンスアーキテクチャ
データ処理、分析基盤
- NTTデータ 土橋昌さん
データ処理基盤が押さえるべきポイントの話
基盤がしっかりしないと分析は出来ない
背景
- 日次バッチを時間毎にしたい
- 組織が分かれると責任分解点ができてしまうとか
結論
- 蓄積
- 処理
- パイプライン
- この３つを制すること
- これを突き詰めると、データの基本セットを機械的に生成、オンデマンドでデータを生成、ができる
- 現実にはなかなかできてない
ポイント
蓄積
- ログを扱うなら、生データをためていざという時に取り出せるようにする
- 活用先が絞れるなら、スキーマ付きデータストアか、スキーマ付きフォーマットがいい
- 入力データのみでなく、中間データや結果データも保持、ストレージは余裕を持っておく
- 削除、アーカイブ化にも注意
- 利用度合いを可視化することで消す根拠にする
- アーカイブ化にも馬力が必要
処理
- 自分のワークロードで意図通り動くことを確認すること
- 分散処理系のOSSは特に、開発元の目的特化している可能性も
- ログを扱う場合の、前処理の考慮も大事
- 試行錯誤はずっと残る、Sparkはそれを意識した作りになっている
- リソース消費が読みづらくなって、リソース分割が鬼門になる
パイプライン
- IFや機能を勝手に決められないことが多い、対向先とか
- 概説部分は条件が多くなりがち
- 柔軟性を持たせるためにメッセージングシステムを入れると良い
- 故障点が増えることはトレードオフ
- パイプラインに流す頻度に、分析のサイクルが束縛されることに注意
- データの利用者によって、要求されるサイクルが変わる可能性もある
- 「高速に、絶対に落とさず、重複しない」は安易に合意しない、良く考えること
- 結局費用対効果、その条件が守れないと、結果どうなるかを良く考える必要がある
