去年は忙しくてなかなか社外イベントに参加できなかったのですが、今年は会社の後輩が登壇するということもあり、Hadoop/Spark Conference 2016へ参加してきました。
結局ミーティングで会社に戻らなければならず、後輩のプレゼンは聞けなかったのですが。。。
にしても、Hadoop界隈のプロダクトも随分増えているもので、数年勉強してなかったせいで、悔しい思いもしたので、今年は勉強したいなぁという思いを強くしました。
INPUT/OUTPUTが予測不能というのは、エンタープライズではあまりないのですが、やはりネットサービスやっていると当たり前になってきてますね。また、クラウドの採用がもはや当たり前の世の中で、まだまだ日本のエンタープライズへの適用は進んでないので、これからが勝負かなと思うところです。
※以下は自分用メモですが、ご参考まで。
2016/02/08 きゅりあん(大井町)
講演資料
http://hadoop.apache.jp/hcj2016-program/
1.Keynote
Hadoopを取り巻く環境2016
- 参加者1367名
- ディストリビューションにより多様になってきたが、Linuxのそれと一緒で現在過渡期と言える
Apache Hadoopの現在と未来
- 本体の構成要素
- MapReduce
- YARN(最近登場)
- HDFS
- MWのインターフェイス
- バッチはHiveQLなどのSQLが主流
- Apache SystemML、Google TensorFlow、Project Catapultなど、
CPU, メモリ, ディスクだけじゃなくてGPGPU、FPGAなどの活用されていく
- HDFS
- データ暗号化、ローリングアップグレードで利用できる局面が増えた
- 開発コミュニティ
- YARNの処理基盤の80%はHive,Spark
Yahoo! JAPANのデータプラットフォームの全体像と未来
- データの3V
- 100以上のデータバラエティ
- 649億PV
- ベロシティ
- データプラットフォーム
- Hadoop
- 6000ノード
- Hadoopに関する技術チャレンジ
- データ容量 4倍/年
- 毎日13億行が追加
- 10万クエリ/h
- useからmakeへ
- 作る側に回って、日本中の課題を解決へ
Hadoopのストレージの現状と展望
- 2012年以降、Enterpriseフェーズへ
- 2016-2020年 ssdへ
- NAND flash、3D XPoint memory
- RAM 256GB以上へ
- ストレージ
- HDFS
- シーケンシャル利用
- HBASE
- ランダムアクセス利用
- KUDU
- 両者のいいとこどり
Spark Conference Japanの開催にあたって
- Spark SQL / DataFrame利用が多い
- MLlib、Spark Streamingも利用されている
Spark 2.0: What’s Next
- 2015年にR言語サポート、飛躍の年
- 利用用途
- BI、DWH、レコメンデーション、ログ処理、不正検知・セキュリティ
- 2.0
- フロントAPIの創設
- 10倍のパフォーマンス
- API Foundation
- Streaming DataFrames
- DataFrameとDataSetのマージ
- ANSI SQL
- DataFramesによる次世代ストリーミング
- 4,5月リリース予定
さくらインターネットが構築した、Apache Sparkによる原価計算システム
- 資産を持つだけに、コスト計算が重要だが、Excel頼み
- Asakusa FrameworkでバックエンドがHadoopかSparkかは意識しなかった
2.ストリーミングアーキテクチャ: StateからFlowへ
- エンタープライズの世界
- モノリシックだと複雑性が増し、専門化してしまったので、n層アーキテクチャへ
- 3層アーキテクチャが乱立してサイロ化
- 分断を補うために生まれたのがESB(エンタープライズ・サービス・バス)
- コントロールの複雑性の課題は解決できてない
- スタートアップの世界
- マイクロサービスの考え方が主流
- JavaScript、Pythonなどを利用してAPIで連携
- パーティショニング
- RPC Layer、Logic Layer、Data Layer
- ジョブとコミュニケーションの方法を与えることで、ライトウェイトを維持する
- Google、Facebookなどが成功した事例
- 有償な技術者が雇えたことが大きい
- RPCも重要だが、遅延処理(Deferred Processing)も重要
- RPCはシンプル
- REST、Protobuf, Avro
- メッセージ・ベース・サービス
- メッセージ受信者が動作してない可能性
- 永続化キューが必要
- 秒間数百万メッセージ、Gb/sのトラフィックはありえる
- マイクロサービスにおいて、耐障害性・高性能が必須で伝統的なキューでは対応できない
- Flowにおける処理
- 従来型のプログラムはほぼバッチ
- 有限の入力と出力
- 処理時間、コスト、可用性、正しさを重視
- ストリームは全く違う
- レイテンシ、コスト、コミットメントレベルが重要
- 暫定的な出力、入力が存在することを考慮
- 遅延をどう考えるかがフローベースコンピューティングで重要
- 現実世界へのFlow適用
- マイクロサービス・ダイアグラムで表現
- エラーキューや再開処理用のキューなどの用意が必要
- メッセージング機能は耐障害性がある基盤であり、入れるのが適切じゃないものにも注意
- 1TBのファイルなどを飛ばすのは現実的じゃない
- 現在可能なプロダクト
- Kafka
- MapR Streams
- 従来のキューで耐久性を確保すると1万メッセージ/秒未満
- まとめ
- マイクロサービスは自然な進化
- マイクロサービスは耐障害性があり、高速で、Kafka風のキューイング前提
3.リクルートライフスタイルの考えるストリームデータの活かし方 ~AWS + Kafka + Spark Streaming~
- ビッグデータの普遍的テーマ
- Volume 数十TB規模
- Variety データ点在
- Velocity
- 全社共通のデータ分析基盤
- DWH
- 使い分け
- IBM Netezza
- Amazon Redshift
- Tresure Data
- Pythonの独自ETLフレームワーク
- Kafkaによるデータハブ基盤、Sparkによるストリーム処理基盤が必要
- クラウド、オンプレミス
- AWS採用
- データハブ基盤
- KafkaとKinesis検討
- ストリーム処理基盤
- Spark,Stormを検討
- KafkaからSparkStreaming、DynamoからLambda、API Gateway
- ポンパレモールで活用
- この商品を今何人見てます!を表示
- 技術詳細
- 入力
- SparkStreamingのログ出力が膨大、古いものは思い切って捨てる
- アプリ開発
- ロジックは関数化してローカルでもテストできるようにする
- ストリーム処理の稼働
- エラーハンドリング
- 出力
- ストリーム処理と出力の独立性を確保する
- Lambda+API Gatewayは低コストなのがメリットだが、テストが難しい
- モニタリング
- Grafana Dashboards、Cloudwatch
- まとめ
- 「なかったら作る」の姿勢
- プロダクト間の隙間
- コアテクノロジーはOSS