#hcj-2014
Number of word 4134
Hadoop Conference Japan 2014 に参加してきました
個人的な所感としては。
- spark楽しそう(だけどまだ触るには勇気が)
- Prestoも熱そう
- MapR書くよりもSQL書く方がお手軽
以下はメモ書き。
keynote
hadoop を取り巻く環境について
- 始めて普及した並列分散
- データの読み込みのスループットを最大化
- 全件データの処理を実現
- シンプルなモデル(MapReduce)
- YARN
- MapReduceからそれ以外のアルゴリズムも
- 複数の並列分散エンジンを併用できる環境
- メモリーの大容量化、10Gbpsネットワークの普及
- インメモリー処理の実現性の向上
- データの読み込みのスループットを最大化
The Future of Data
Doug Cutting
- 未来について
- ハードウェアの価格の低下、性能の向上
- データの重要性の向上
- オープンソースが勝ち残る
The Future of spark
Patric Wendlell
- Sparkの目的
- データサイエンティスト、エンジニア能力の拡張
- 表現力のあるクリーンなAPIの提供
- 多様な環境にわたって統合されたランタイム
- API stability
- 3か月サイクルでマイナーリリース
- 必要におおじてメンテナンスリリース
- Spark SQL
- MLlib
- Spark + R
- DataBricks
Hadoop エコシステムの片鱗と見えてきた使いドコロ
- TreasureData
- なぜHadoop使うのか
- Hadoopを使うのは最適な解か
- 安いストレージとして使うだけならHadoopより良い物は沢山ある
- データの収集ソフトウェア
- 多種多様なデータ・ソース
- fluentd,flumea,kafka,sqoop
- ファイルフォーマット
- Schema on Read
- 管理・人的コスト低減の支援
- 簡単にデータを扱うか
- Tez, Spark
- SQL on Hadoop
- Impala, SlarkSQL, Presto Drill
- Mahout, Spark MLlib
- 今までの時代
- データを入れるだけ入れたけど、レポート化できる人の限られている
- 今までは何でも入れられるだけ
- これからはだれでも取り出せるようにしないと意味がない
- Hadoop -> MPP
- Twitter: Hadoop -> Vertica
- Pinterest: Hadoop -> redshift
- 非構造化データの領域に踏み込む
- 混沌の時代
- Hadoopを使うのは最適な解か
- なぜHadoop使うのか
セッション
マルチテナント化に向けた Hadoop の最新セキュリティー事情
- Hadoopのユースケースの移り変わり
- バッチ処理を効率よく行うため
- 部門単位での利用、クラスターの乱立
- 近年
- バッチ処理 + インタラクティブな処理
- SQLによるアクセス
- データは一部の人だけのものではない
- クラスターの共有(マルチテナント)
- マルチテナントのメリット
- データの複製不要
- 業務の取り巻き
- 性能・効率の改善
- 課題
- リソースの分離と管理
- Role管理
- バッチ処理を効率よく行うため
- マルチテナントとセキュリティーの関連性
- 認証
- kerberos
- 相手が何者であるかを保証するプロトコル
- 暗号化
- kerberos
- 認可
- HDFS ACL
- ファイルシステムレベルでのaccess control
- Apache Sentry
- データベース、テーブルview、行列の粒度でアクセス制御
- HDFS ACL
- 認証
- 認可モジュールSentryの紹介
- Apache Sentryはモジュールとして開発されている
BigQuery and the world after MapReduce
- BigData at Google
- ログ分析するのにMapReduceを書いてる場合じゃない
- BigQuery ( sql base )
- indexなんてないんや
- 全文検索、120億行、10秒ぐらい
- storage料金
- Quesy料金
- Column Oriented Storage
- もはやスタンダード
- Colossus File System
- GFSの次のもの
- MPP
- 1TBの内容を数秒で舐めるためには何台必要なのか
- JOIN
- small join
- broadcast JOIN
- ばらまいてコピー => JOIN
- JOIN Each
- shuffleしてjoinできる
- BigQuery Streaming
- fluentd
- fluent-plugin-bigquery
- BigQuery User-Defined-Function-with-JavaScript
- クエリ内にJavaScript書く
- Cloud Pub/Sub
- FlumeJava
- MillWheel
SQL によるバッチ処理とストリーム処理
- @tagomoris
- stream処理
- norikra
- Hadoop
- Hive/ Presto
- SQL is NOT the best;
- But, SQL is better than NONE.
- Batch processing
- hive
- Stream processing
- storm
- kafka
- esper
- norikra
- fluentd
- stream処理
- Lamda Architecture
- Streaming
- 速報値
- Batch
- 確定値
- 両方に対応したい
- Streaming
- Stream処理
- レイテンシが低い
- 同じ処理をバッチとしても実行できる必要がある
YARN
- TD
- PlazumaDB
- S3上で動作
- HDFS is not used
- Hadoop Cluster
- Customize hadoop
- Customize hive
- Customize Pig
- PlazumaDB
- Customize Impala
- Customize Presto
- 独自queue
- 独自scheduler
- YARN cluster
- プロダクションにはまだ入れてないが環境整えている
- PlazumaDB
- YARNとは
- Job History Server注意
- 起動してないと過去ログが追えなくなる
- NOTE
- Use the Hadoop 2.4.0 and later
- Capacity Scheduler、there is a bug
- deadlock
- hadoop-conf-pseudo doees not work
- 2.2.0 and 2.4.0
- 結構違うので注意
- Use the Hadoop 2.4.0 and later
- Job History Server注意
Presto
- what is Presto
- Facebookで作られてoss化
- HDFS上のデータを可視化したい
- うまくいかない
- hiveが遅すぎる
- hiveをバッチ化 => 中間DBに入れる
- 中間DBはスケールしない
- HDFSに保存してないものは入れなきゃならない
- Presto
- 中間データベースの取り除く有効な手段
- 他のデータストアを舐めることにも対応
- Hiveとの使い分けが必要
- 巨大なjoin
- group by
- Interactiveなクエリを発行できる
- 複数のデータ・セットをまとめて表示できる
- BI tools
- 可視化に利用していく
ODBC/JDBC is very complicated!
- Prestoの実行モデルについて
- not MapReduce
- 全部並行で動いてる
- 一個死んだら全部死ぬ
- メモリー溢れてしまうとクエリが死んでしまう
- メモリーの使用量はクラスターで管理されて、クラスターが死ぬことはない(はず)
- がクエリは死ぬ