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と較べてどうなのか
内容のメモは以上です。
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 の続きです。
続いて、個別セッションの前半。先は長い。。。
個別セッション
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に参加してきたので、その時に取ったメモを整理してアップ。長くなるので、まずはキーノートから。間違いがあってもご容赦ください。
当日の資料は、以下のページにアップされると思うので、詳しい情報は以下を見てください。
http://www.eventbrite.com/e/hadoop-conference-japan-2014-tickets-12016613013
それぞれ別の立場から話しているのに、Hadoopの用途が大量データの保存と単純な集計から、汎用的な分散処理基盤かつMPPまで包含するような方向で進化しているという観点が共通しているところが面白いですね。
キーノート
開会挨拶
- 参加登録者
- 1296名 -> 最終的には1299名
- 約65％が初めて参加する人
データ
Hadoopのこれまで
だんだんYARNが中心に座ってきている
- MRの経験をもとに複数の分散処理エンジンを使い分ける時代に
『The Future of Data』
未来は予測できないが、いくつかの事実が真実を予測
『The Future of Spark』
- Speaker: Patrick Wendell （Apache Spark主要開発者, Databricks）
今日のスライドは、自分で日本語に翻訳した
Spark開発者の一週間
- 500 Patch
- 200 update issue
- 140 Mail thread
- ...
Spark開発目標
- Data scientist, engineerの能力拡張
- CleanなAPI
- 多様な環境に適用
- 強力な標準ライブラリ
API互換性を維持
Spark Stack
- Spark SQL
- MLlib
- Graph X
- Spark Streaming
Sparkの未来は「ライブラリ」
- パッケージ化してどこでも使えるように
Spark SQL
DatabricksではクラウドでSparkを提供している
『Hadoopエコシステムの変遷と、見えてきた使いどころ』
- Speaker: 太田 一樹 （Treasure Data CTO）
- Hadoopの本質的な価値とは
- Collect any types of Data
- Store any types of Data Economically
- Faster use of Data
- Better use of Data
ここまで使うことでHadoopの価値が出る
Collect any types of Data
- Fluentd
- Apache Flume
- Kafka
- Sqoop
Store any types of Data Economically
- どんなタイプのデータも格納可能
- ファイルフォーマットに注目が集まっている
- どんなタイプのデータも格納可能
Faster use of Data
Better use of Data
- Impala, Presto, Drill
- Mahout, Hivemall
データベースの進化
スキーマ管理がもたらす問題
- 一部のレポートしか作れない
- データの整合性はとれるが、出てくるころには使えない
現在のトレンド
今後、Hadoopは構造化データとの境界線に突入
- HadoopだけでMPPができるように
- トレンドを読みながら技術を利用すべき
キーノートのメモはここまで。
溜まってきた大量の名刺やシャッツキステのポイントカードをしまうのにちょうどいい道具を調べた
最近、名刺やらシャッツキステのポイントカードが貯まってきて、カード状のものを保存するのに使えそうな道具を調べたので、その時の内容の備忘録を書いてみました。*1
自分で探せていない範囲がまだありそうなので、この用途でもっといいものがあれば、教えていただけるとありがたいです。
調べるにあたっての前提
以前は、名刺はきちんと名刺ファイルにファイリングしていました。しかし最近は、ものぐさでファイリングしなくなってしまっていて、その管理方法も限界に…。また、電子化しておいて、実物は廃棄してしまうという方法もあると思うのですが、収集癖があるから現物を捨てるのは忍びないので、それも今回は除外。
上記の前提なので、今回は入れるのに手間がかからない箱状のものをターゲットとしました。
どうやって見つけるか
箱状のものを使うと決めたものの、最初にカード状のものをしまう箱をどういう単語で検索すべきかという問題に引っかかりました。いろいろ試行錯誤して検索してみた結果は以下の通り。
- カードホルダー → ハズレ
- 主に社員証をぶら下げるものや財布上のカード入れが引っかかる。
- カードケース → ハズレ
- 主に財布上のカード入れが引っかかる
- カードボックス → 当たり！
- 主に名刺を1000枚単位で収納できる箱やカードゲーム用カードを入れる箱が引っかかる
- 「ネームカードボックス」とすると、名刺をしまう箱に絞り込める。
- 名刺箱、名刺ケース → 当たり！
- 名刺を買った時に入っているような箱が引っかかる。
- ネームカードケース → 微妙
- 主に社員証をぶら下げるものが引っかかる。ただし、あとで取り上げる今回買った製品がたまたま「ネームカードケース」という製品名だったため、それだけ例外的に引っかかった。
「名刺箱」というのは、見つけてしまえば当たり前の検索ワードなのですが、当初は「カードケース」で検索していたので、なかなか見つけられずに苦労しました。。。
500枚以上のカードを入れるのに使えるもの
今回探したものの中で、500枚以上のカードがある場合に使えると思ったのは「カードボックス」系のものです。このジャンルのものは、今回初めて知りました。探してみるとあるもんなんですねー
自分で買ったのは以下の「ネームカードケース」。選んだ決め手は、下の箱の高さが名刺の縦幅よりも低く、名刺が取り出しやすい点。この製品はフタがパカっと完全に外れるタイプなので、フタに蝶番がついている方がお好みであれば、そちらもよいかも。
また、今回はファイルはなしということで除外しましたが、カードボックスの類似製品として、このジャンルだと下の商品のような円形に名刺をパタパタ入れていくものも見つけました。
「ローロデックス」という製品なんですね。どこかで見た気がしますが、名前を知るのは初めて。名前を知らないと全然見つけられない。。。
数百枚程度のカードを入れるのに使えるもの
数百枚程度のカードを入れる場合は、今見つけられているものの中では「名刺箱」が良さそうという結論です。名刺を買った時の箱が残っていれば、それを使うのが一番リーズナブルですが、単体で買うこともできました。
ただ、安い名刺箱はネットでは5個単位、10個単位ものが多くて、1個だけ買う方法がなさそうなのがネック。余った分は、小物の整理にも使えるので、まとめて買っても使うところはあるように思いますが。
透明なものがいいか、中は見えない方がいいかは好みの問題ですが、以下のようなものがありました。*2
 3240円以上で送料無料！(沖縄県をのぞく)幅57x奥行93x高20mm名刺が100枚入るサイズです【HEIKO/... |
高級感が欲しい場合
今回自分では買っていませんが、「名刺箱」で調べてみると、凝ったものも見つかりました。千代紙のものは、値段も手頃なので個人名刺入れとかによいかも。ほかにも、漆器で1万円超えみたいなものも見つかりましたが、さすがに使う機会なさそう…。
 【ホームステイのお土産】【海外出張の手土産】【和柄】【外国人に喜ばれる】【日本のおみやげ... |
 木製漆塗りの縁起物の名刺箱(名刺ケース) ラッキーアイテム ビジネスギフト、父の日ギフト、就... |
以上、どこにニーズがあるかわかりませんが、調査メモでした。
今日はこの辺で。
一人遊園地に行ってみた
今日は、花やしきに行ってきました。行った理由は、花やしきのローラーコースターに乗ってみたかったから。
全然下調べせずにいったので、花やしきのローラーコースターがまだやっているか不安でしたが、行ってみたところ、まだまだ現役で稼働していました！
なんと去年還暦！ そして、還暦の人は無料で乗り放題！！
楽しい！！！ ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌.
ただ、周りはカップルか子供連ればっかりで、一人で行くとその人の心が試されます。人の迷惑にならない限り、どんなところでも行きたかったら行くべきだとは思いますが、周りがキャッキャウフフしている中に一人でいると精神が徐々に蝕まれていくので、基本的には一人で遊園地に行くのはおすすめできませんね。
ちなみに、一時期Twitterで回っていたぼっち検定では、一人遊園地は上から2つ目のレベルになっています。ただ、神レベルのラブホテルは、旅行で使えば割と簡単に達成できるし、千葉のネズミの国はパスポート持ってソロで行ってる人が結構いるので、上位の方が割と簡単に達成できるような気もします。
【ぼっち検定】 初級 一人で牛丼 5級 一人でラーメン 3級 一人でファミレス 1級 一人で居酒屋 初段 一人で温泉 ニ段 一人で回転寿司 三段 一人で海水浴 五段 一人で焼肉 名人 一人で公園の手漕ぎボート 独聖 一人で遊園地 神 一人でラブホテル
今日はこんなところで。
#qpstudy を開催して、第2セッション「アーキテクチャ設計の勘所」で発表してきた
先週の土曜日、4月19日に qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 を開催して、第2セッション「アーキテクチャ設計の勘所」で発表は、自分から発表させてもらいました。
今回は、ドワンゴさんの会議室を借りて、ドワンゴのエンジニアの方にニコ生の配信までやっていただきましたドワンゴさんマジドワンゴ。
自分の発表資料はこちら。
今回の勉強会のテーマ
今回の勉強会のタイトルは「〜俺の屍を超えて行け、でも踏まないで〜」ということで、新人インフラエンジニアに伝えておきたい基本的な内容をテーマに、ベテランにも何らかの気付きがある中身とすることが、今回の勉強会の目標でした。
結果、初参加の人の割合も多く初参加と2回目以降の参加の人がおよそ半々。会場参加者が、スタッフ抜きでほぼ100人。ニコ生は、当日が300人強で、タイムシフトも含めた視聴数は826人。ニコ生の視聴者がここまで増えたのは、ドワンゴ研究開発チャンネルの力が大きかったと思いますが、内容も好評で、大成功だったと思っています。ありがとうございました！
また、オープンソースチャンネルとアメーバのガールフレンド（仮）のプロデューサーさんに協力いただき、会場に来た人限定で、公式公認でクロエ・ルメール（CV: 丹下桜）さんに、勉強会の開会挨拶をしていただきました。
いきなりの大人の力の無駄遣いぶりに参加者がポカーンとしていた気もしますが、スタッフのテンションは上がりました。この場を借りて関係各位にお礼申し上げますm(__)m
自分の発表
発表にあたっての自分の課題は、自分がインフラ全体設計を行う際のプロセスを整理して言語化することでした。
自分がやってきたことを振り返ると、インフラ全体設計は、過去の経験や類似システム事例から決めてしまうことが多かったように思います。しかし、それでは新人にも、チームメンバーにも自分がやっていることをうまく伝えることができません。そこで、今回の勉強会を機に、まとめたのが上に載せた資料です。
話のポイントを簡単にまとめると以下のような感じです。
- インフラ全体設計のインプットは、「機能要件」→「アプリ機能」と「非機能要件」の2つに整理可能
- Web三層モデル」を理解し、利用することが設計の基本
- どんな設計に場合も、どうしてそのアーキテクチャを選んだのか説明できることが重要
余談ですが、途中、どうやっても変更できない「非機能要件」として、総務省の事故報告制度みたいなものがあることも紹介しました。
今回のスライドの「途中にCMを挟む」スタイルは、スライドの途中に休憩用のスライドを入れておくというテクニックを応用したものです。このような本論と関係ないスライドを入れておくことで、以下のようなことを狙っていました。
- トピックの切替の時に、それまでの話と関係ないスライドを挟むことで、聞いている人を集中を一旦解いて、頭を切り替えてもらう
- 自分も、そのスライドのタイミングで一息ついて、聞いている人全体を確認する
- 休憩スライドが出た時の時間を確認することで時間配分を確認する
長時間のプレゼンで集中しっぱなしだと、聞き手も話し手も疲れてきますし、こういうスライドを入れていた方が自分としても気持ちが楽でした。
個人的には、参加者の世代を考えていなかったために、最近のポエムブログの流行とオープニングをクロエ・ルメールをかけたオープニングポエムと『男坂』のネタが通用しなかったのが最大の誤算です。さすがにときメモのラジオを聞いてる世代はいなかったか…
合わせて読みたい
第5セッションの@nekoruriさんが、僕の発表内容を引き継いで、ミドルウェア設計の勘所を話してくれたので、そちらも続けてみてもらえると、より内容がわかりやすいと思います。
順番が前後しますが、そのほかのセッション資料もアップされているので、こちらも是非。
第1セッション 構築作業の全体フェーズ
第3セッション『ハードウェア設計の勘所』
第4セッション『ネットワーク/OS設計の勘所』
第6セッション 今後のインフラエンジニアとは
- こちらは、資料非公開です。
また、前回の qpstudy 2013.07はDBに特化した内容でしたが、こちらもおすすめです。
最初のqp劇団による寸劇は置いておくとして、@nippondanji さん、@choplinさんのお話は、ほかではなかなか聞けないいい内容なので、さらにDB部分を掘り下げたい方は、合わせて読むと理解がさらに深まると思います。おすすめです。
漢(オトコ)のコンピュータ道: qpstudyで発表したスライドをアップロードしました。 （Ust: http://www.ustream.tv/recorded/36485447）
qpstudy 2013.07 NoSQL （Ust: http://www.ustream.tv/recorded/36487771）
勉強会の企画について
勉強会自体の報告は、ここまでですが、スタッフらしく企画のことを少し。
今回の勉強会の企画を決めるに当たっては、スタッフで飲み会ミーティングをして、ネタ出しをして、あとはSkypeチャットで、随時詰めていきました。4月に入っても全然具体化していなかったので、だいぶハラハラしましたが、、、
ネタ候補は以下のような感じ。
- 引継はどうあるべきか、どうするべきか 年度を越えて引継ぎをしてちゃんとできた人できなかった人がいらっしゃると思います。割とある出来事なのに今まで語られることがなかったこの分野にメスを入れますとかなんとか
- コマンドのアウトプットを理解する
- 「インフラデザインパターン」はなぜパターンなのか
- 「今すぐ使える基礎」
- 「年寄りから知っておいて欲しい情報基盤のいくつか」
- 「これを知らないと恥ずかしい」を新人向けに NICのボンディングとか
- 『ソフトウェアの教科書』 qp版
- 春ということで、新人向けに「プログラムはなぜ動くのか 2014年版」
- cgi getとpost
このエッセンスを煮詰めていって、今回の内容にしましたが、ネタとして上がっても、途中で落としたものもあるので、次回以降に取り上げられればと思っています。
関連エントリ
最後に、今のところ見つけている参加者ブログを。qpでは、「ブログを書くまでが勉強会」というのをキャッチフレーズの一つにしています。
ブログを書くと、自分が理解できたことも整理できますし、勉強会スタッフのモチベーションも上がるので、できるだけブログを書いてくれたら、嬉しいなと。とはいえ、自分でも書けないことが多いのですが^^;
参加者
- 【勉強会】qpstudy 2014.04 - Qiita
- qpstudyに行ってきた - としたにあんの左脳
- 4/19 「qpstudy 2014.04 俺の屍を超えて行け、でも踏まないで」勉強会参加：情熱の行方：So-netブログ
- qpstudy201404に行ってきた！ - ITとか野鳥とかその他諸々のメモ
- qpstudy 2014.04 へ行ってきました #qpstudy | こえむの編集後記
- qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 #qpstudy - Togetterまとめ
スタッフ
今日は、こんなところで。
