Hadoop Conference Japan 2014 参加メモ（個別セッション①） #hcj2014
Hadoop Conference Japan 2014 参加メモ（キーノート） #hcj2014 の続きです。
続いて、個別セッションの前半。先は長い。。。
個別セッション
BigQuery and the world after MapReduce
Speaker: 佐藤一憲 （Google）
Google I/O で、GoogleはMapReduceを使っていないという話があった
We use Dremel ≒ Google BigQuery(MPP)
- 68B records in ~20 secs
- 120億行フルスキャンで10秒ぐらい
- コスト
- Storage 0.026/GB per manth
- Query: $5/TB
- Column Oriented Storage
HDFSの元となったGoogle File Systemも現在は使っていない
- Colossus
The next generation Google File System
- Tail Latency が低い -> レスポンスが遅いノードに引きずられない
- Colossus
The next generation Google File System
Google BigQuery
Scanning 1 TB in 1 sec takes 5000 disks
処理
- Mixer -> Shards -> Mixer
JOINの方式
- Small JOIN: Broadcast JOIN
- Big JOIN: JOIN EACH, GROUP EACH -> Shuffle
- 608M x 38M records -> 90s
BigQuery streaming
- 1M rows/s を格納可能
- Fluentd Plugin bigquery がこれに対応していて、データを流し込める
Google I/Oで発表された今後実装予定の機能
QA
Fluentdで今後チャンクにIDをつけるようにする。インターネット経由だと重複は結構ある。Googleへのデータ送信時に、そういう重複排除の仕組みは提供されるか。
- 現状はない。インポートしてもらって、Group BYで重複を排除してもらう等が必要。
- Exactly Onceに関しては、Google I/Oでも質問があって、Dataflowの中ではできている。
BIツールから直でつないで使うのか、スプレッドシートに書きだすのか、どちらの使い方を想定しているか
- 両方ともユースケースがある
大きなデータでクエリが走らないのは？
- おそらくソフト的なクォータ設定で止まっている。
- サポートを購入してもらうと制限を外せる
- Reserved Capacityというメニューがある
クエリの結果の整合性は？
- トランザクションはサポートしていないし、スナップショットとしての整合性も保証していない
Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤
- Speaker: 油井 誠（産業技術総合研究所）
Hivemallは、Hive上で動くOSSの機械学習ライブラリ
- HiveのUDF、UDTFで実装されており、Hiveに慣れていれば、追加の学習コストが少ない
- 学術研究の結果をいち早く取り込んでいる
既存ツールはプログラムが必要
- すべてのステップがHiveQLで実行可能
- add jar
- source のみで実行可能
- すべてのステップがHiveQLで実行可能
特徴数の削減をサポートしている
- 学習時やテスト時に予測モデルをメモリに収める必要がない。
EMRに自動構築するBootstrapを提供している
最新のオンライン学習アルゴリズムをサポート
- CW、SCW、AROWをサポート
- 学習の収束が高速
- 10イテレーション→2, 3イテレーション
オンライン学習で精度がよい
- confidence weighted
- 重みと確信度を更新する
- 確信度が十分な重みについては、小さな更新。学習初期は大きな更新。
- confidence weighted
UDAF（集約関数）での機会学習
-
- Sparkは担当領域を各ノードでキャッシュするので今後のバージョンで高速化する可能性がある
- SparkのMLlib はサンプリングを利用したMini-batch勾配降下法
Hivemall
- amplify UDTFでデータを増幅してShuffle
- rand_amplify UDTFでデータを増幅してMap Only Shuffle
Apache incubator化の打診がある。Hortonworksから打診を受けている。
QA
Hadoop Conference Japan 2014 参加メモ（個別セッション②） #hcj2014
Hadoop Conference Japan 2014 参加メモ（キーノート） #hcj2014 と Hadoop Conference Japan 2014 参加メモ（個別セッション①） #hcj2014 の続きです。
長くなったので、最後のセッションはさらに分割します。
A Deeper Understanding of Spark Internals
- Patrick Wendell （Databricks）
Agenda
How spark runs, focus on performance
Major core components
- Excecution model
- The suffule
- Caching <- not cover in this session
Scala example
最初の文字の出現頻度を数える
sc.textFile("hdfs://names")
.map(name =x> (name.charAt(0), name))
.groupByKey()
.mapValues(names => names.toSet.size)
.collect()
Excecution model
Create DAG/RDDs
- HadoopRDD
- map()
- groupby()
- mapValues()
- collect()
- HadoopRDD
Create execution plan
- pipeline as much as possible
- Split into "stages" based on need to reorganize data
Schedule tasks
- split each stage into tasks
- schedule tasks
The shuffle
- Redistribution data
- Pull-based
write intermediate file to disk
- network bound
各パーティションごとにHash mapを構築する
- 一つのキーと値のペアはメモリ上に収まる必要がある
What went wrong?
- Too few partition to get good
- Large per key groupby()
shipped data accross the cluster
Ensure enough partitions
- Minimize memory
- minimize shuffled
- Know the standard library
too few partitions/too many partitions
- reasonable number of partitions
Fix the problem
.repartition(6) .distinct()
Low level performance
QA
Does spark support JOIN?
- yes
Hive, Shark or SparkSQL
- SparkSQLに統合しようとしている
- Sharkは新しいプロジェクトでは使うな
- SparkSQLに統合しようとしている
LT
LTを見に行きましたが、こちらのメモはカオスなので、一旦割愛で。
Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報
- 嶋内 翔（Cloudera）
- 今日はこのために来たと行ってもいい
Impalaのサービス
impalad
- クエリを実行する
- どのデーモンもクエリを受け付けられる。
- 受け付けたノードがコーディネータ
statestore
- ネームサービス
- impaladの簡単な死活監視のみ
- このサービス自体は死んでいても動作はする
catalogd
- メタデータ管理
- あとで詳細
実行計画
- シングルノードプランの作成
- プランフラグメントに分割
インメモリの実行
メタデータ管理
HBase連携
- 1行インサート可能
- 高速にインクリメントするカウンタをHBaseに持つ等のユースケースが可能
リソース管理
Llama
- 低レイテンシ用のアプリケーションマスタ
- YARNのスケジューリングを細かくするためのサービス
- YARNのリソース配分をキャッシュ
- 1.4でプロダクションレディ
- 低レイテンシ用のアプリケーションマスタ
Sentry
- データベース、テーブル、ビュー、列、行の単位でアクセス制御
- エコシステム全体で利用可能
パフォーマンスと最適化
スケーラビリティ
Impalaはリニアスケーラビリティがある。
HWを倍
- クエリによるがおおよそ倍の性能
- 倍のクラスタで、倍のユーザ
- 同じか良くなる傾向
ロードマップ
- 1.4
下半期に2.0を出す
- LAG
- LEAD
- 相関サブクエリ
- Nested Data（JSONとか）を入れる
Impala本からPDFが無償公開されているので読むと良い
QA
Impalaバージョン同士の比較は？
- バージョンの差異はすぐにはデータがない
UDTFは？
- 望んでいるというのは認識している。プライオリティが高いがまだロードマップに載ってきていない。
Hadoop Conference Japan 2014 参加メモ（個別セッション③） #hcj2014
Hadoop Conference Japan 2014 参加メモ（キーノート） #hcj2014 と Hadoop Conference Japan 2014 参加メモ（個別セッション①） #hcj2014 と Hadoop Conference Japan 2014 参加メモ（個別セッション②） #hcj2014 の続きです。
メモはここまで。
並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法
- 古橋 貞之（Treasure Data）
会場でPrestoを使っている人はどれぐらいいますか？
- 10人ぐらい
- これは話し甲斐がある
- 10人ぐらい
HDFS上のデータを可視化したい
- Hiveは、可視化には遅すぎる
- ODBC接続が安定しない
- ただし、Hiveは、巨大なJOINなどでは有効
- ODBC接続が安定しない
- Redshift, PostgreSQLは、コストが高いし、スケーラビリティが低かったり
- 中間データベースを使うと、余計な手間がかかる
- Hiveは、可視化には遅すぎる
Prestoを使うと解決可能
- PrestoはHiveにもMySQL上にあるデータにもクエリを投げられる
- Prestoをハブとして解析プラットフォームを作れる
全体アーキテクチャ
Connector
- Hive
- Cassandra
- MySQL(beta)
BI tools needs
Prestgres
- PostgreSQL protocol gateway
- PostgreSQLのODBC/JDBCで接続できる
PostgreSQL に見えるんだけど、裏ではPrestoが動く
- pgpool-Ⅱを改造してクエリを書き換える
- 書き換えたクエリがPostgreSQLの中でさらに各サービスへのクエリに変換される
Tableau/ChartIOからクエリをかけられる
- PostgreSQL protocol gateway
Prestoの実行モデル
Monitoring
Laad map
- Huge JOIN and Group by
- Task revovery
- Create View
- Plugin repository
- Native store
情報源
QA
- 想定質問としてあるのが、Impalaと較べてどうなのか
- 確かにImpalaと比べると遅い
- アグリゲーションの最適化が図られているので、だんだん早くなっている。開発スピードが早い。
- impalaよりも、リソース管理がしっかりしており、メトリクスが取りやすい。運用が考慮されている。
- 拡張性が高く、開発がオープン。
- プルリクエストが２，３週間でマージされる
- 確かにImpalaと比べると遅い
- 想定質問としてあるのが、Impalaと較べてどうなのか
内容のメモは以上です。
