Hadoop / Spark Conference Japan 2016に行ってきました
Hadoop / Spark Conference Japan 2016に行ってきましたので、その内容についてレポートします。最近は機械学習とSparkに興味があるためランチはB会場のライトニングトークを聞き、午後はD会場のセッションに参加しました。なお、スライドは順次Hadoop / Spark Conference Japan 2016（2月8日、東京）の講演・LTのプログラム | 日本Hadoopユーザー会に公開されるそうなので、そちらも合わせてご覧下さい。
Keynote
まずは午前中のKeynoteです。他にもKeynoteに関する記事を見つけたのこちらも合わせてご覧下さい。
- #hcj2016 Hadoop/Spark Conference Japan 2016 午前キーノートのメモ - #garagekidztweetz
- Hadoop / Spark Conference Japan 2016 - satoshihirose
- YARN、HDFS、そしてSparkの将来像とは：「Hadoop/Spark Con」基調講演 - ZDNet Japan
ご挨拶、Hadoopを取り巻く環境2016
濱野 賢一朗 （日本Hadoopユーザー会, NTTデータ）
NTTデータの濱野さんから最初のご挨拶とHadoopを取り巻く環境、そしてカンファレンスを行っている意図についての説明でした。Hadoopエコシステムは年々広がる一方で定義が難しくなっているなというのは同感でした。
- Spark Conference Japan 2016 初開催！（併催）
- Hadoop10周年！
- 参加登録者数1347名！約63%がはじめて参加される方！
- いまのHadoop
- Hadoopは終わった。何がHadoopなのか？
- Hadoopはひとつのものではなくなった
- 初期のHadoopはMapReduceとHDFSと言われていた
- 周辺ソフトウェアが出てきたImpala、Presto、Drill、、、
- Hadoopエコシステムという言い方も昔からあったが、どこからどこまでを含めるか
- パッケージングの多様さ
- 利用するパッケージによって含まれるソフトが異なるようになってきた
- Linuxディストリビューションでも同じ話があった。当初はディストリビューションによって含まれるソフトが異なったが、今は落ち着いている。つまり、Hadoopも過渡期だと思われる。
- 今は難しい時期。だから、情報収集が重要になると考え、このカンファレンスで情報収集してもらえたら
- 分散処理はまだまだ進化・変化・浸透していく
- 昔から分散処理の研究はあったが初めて世の中に普及したのはHadoopだと思う
- 成熟していくのはこれから
Hadoopの現在と未来
鯵坂 明（Hadoopコミッタ）、小沢 健史（Hadoopコミッタ）
Hadoopコミッタであり最近PMCにも就任した鯵坂さんと小沢さんからは、Hadoopの現状と将来についての話がありました。YARNの将来像として機械学習というコンテキストが出てきていて、機械学習がいまホットなんだなーと改めて思いました。
- Hadoopとは
- MapReduce、YARN、HDFS
- YARNの現状
- Hadoopを取り巻く現状
- 分散処理ミドルウェアのインタフェース
- バッチ処理はSQLに似た言語による記述が主流
- HiveQL/Pig Latin/Spark DataFrameなど
- バッチ処理とストリーミング処理を透過的に扱えるような言語が登場
- Apache Flink、Google Dataflowなど
- DataflowはApache Beamとして採択された
- 機械学習に特化した高水準言語
- Apache SystemML、Google TensorFlowなど
- 多種多少な分散処理ミドルウェアの登場
- GPGPUやFPGA
- YARNの将来
- YARNもGPGPUやFPGAを含む様々な計算リソースを扱えるようなデータセンターOSとしてさらなる進化を遂げる
- HDFSの現状と将来
- ここ1,2年でも継続的に機能追加されている
- SSDやメモリを活用する機能が追加された
- セキュリテイ/運用性
- POSIX ACLs
- データの暗号化
- ローリングアップグレード
- Hadoopの開発コミュニティ
- Huaweiが2位になっている
- 日本ではNTT、NTTデータ、Yahoo! Japan
- ソースコードの行数だけでなくレビューやMLでの対応などいろいろあるので、ソースコードの行数というのはあくまでの目安として欲しい
- Hadoopをよりよくしていきたい
- メンテナスリリースの継続
- Java 8/9対応
- 新しいハードウェアを意識した高速な処理基盤の実現
- Hadoopの開発者をもっと増やしたい
- YARNは着実に広まっている
- 500名以上が利用しており、会場の半分の人はYARNを使っているようで、着実に移行している
- 80%はHiveとSparkを使っている
関連記事
Yahoo! JAPANのデータプラットフォームの全体像と未来
遠藤 禎士（ヤフー）
（現時点でスライドは公開されていないようです）
Yahoo! JAPANの遠藤さんからはYahoo! JAPANのデータプラットフォームの全体像と今後についての話がありました。Hadoopに関する技術チャレンジということで年々増えるデータサイズ、クエリ数に対してNode数を増やすのではなくチューニングで対応したという話でした。ワークロードにもよるのでしょうが、チューニングすれば同時クエリ数を10倍に増やせるようです。
- Yahoo! Japanのビックデータ
- Variety: 100以上。検索キーワード、広告、コンテンツ、購買情報など
- Volume: 649PV
- Velocity: 秒間50,000アクセス
- データプラットフォームの全体像
- 6000Noteds, 120PByte
- これから
- Tezの導入が本格化
- LLAPは午後のセッションで
- Sparkはデータサイエンス部で70nodeで検索のグラフ分析
- Hadoopに関する技術チャレンジ
- 年率4倍
- CPU使用率も2.4〜3.3倍/年
- この問題をお金ではなく技術でどう解決するか
- 事例：広告レポートのチャレンジ
- 1万クエリを10万クエリにチューニング
- Metastore ServerはLocal Mode
- RMとAMをバランスよくチューニング
- DataNodeのリソースを有効活用
- クライアントサイドの最適化
- 最後に
- USEからMAKEへ
- Hortonworksさんとパートナーシップを結び、Hadoopにコントリビュート
関連記事
Hadoopのストレージの現状と展望
Todd Lipcon（Cloudera）
（現時点でスライドは公開されていないようです）
ClouderaのToddさんからHadoopのストレージの現状と展望についてのお話でした。ストレージを専門とされていることもあり、とても丁寧にストレージという観点でHadoopの歴史的経緯を説明し、最後にKuduの紹介をしていました。とてもゆっくりと聞き取りやすいように英語を話してくれていたのが印象的でした。
- 自己紹介。Hadoopのメーリングリストのアクティビティとその時期の仕事内容の紹介
- Hadoopプラットフォームの進化について年代を4つに分けて説明
- Basics/2006-2007: HDFSとMapReduceのみ。HAもない。ユースケースもBatchのみ
- Production/2008-2011: HDFSにHAが実装されHBaseも登場
- Enterprise/2012-2015: エンタープライズ向けのアクセスコントロールや暗号化が実装され、SQL-on-Hadoopにより高速化
- Next-gen/2016-2020: NAND flashや3D XPoint memoryへの対応、Apache Kudu
Spark Conference Japanの開催にあたって
猿田 浩輔（Apache Sparkコミッタ）
Apache Sparkのコミッタである猿田さんからはSpark Conference Japanを開催した背景についての説明とセッションの紹介がありました。
- 開催の背景
- Spark熱の高まり
- 日本語の書籍も発売された
- Sparkへの日本人コントリビュータの増加
- すでに商用運用している例も多数
- 多くの人の情報交換の場となれば
- 参加者の70%がSparkの利用を検討している
- 利用されているコンポーネント
- Spark SQL/ DataFrameが多いが、MLlib、Spark Streamingも多い
Spark 2.0: What's Next
Reynold Xin（Databricks）
DatabricksのReynoldさんからはSparkの現状と2.0の紹介がありました。私はあまり英語が聞き取れないのですが、Reynoldさんはジョーク満載のトークをしてる印象でした。そして、Spark2.0が今年の5月にはリリースされるというのに驚きました。ほんと進化が速いと思います。
- 日本語の翻訳付きのスライド
- Sparkのソフトウェアスタック
- エコシステム
- Databricksの紹介
- 2015年はSparkにとって大きな年だった
- さまざまな実行環境
- Standalone modeが48%で次がYARNの40%
- 51%がパブリッククラウド上
- Sparkを利用している業界
- 上位のアプリケーション
- BI、データウェアハウス、レコメンデーション、ログ管理、ユーザー向けサービス、不正検出/セキュリテイ
- 違う見方でのスタック図
- フロントエンドとバックエンドで分ける
- Spark 2.0
- フロントエンドAPIを作る
- バックエンドは10倍のパフォーマンスにする
- DataFrame経由にして将来はGPUなどにも対応する？
- ストリーム処理に関する課題
- Sparkは既にかなり速い
- Spark2.0のリリーススケジュール。4月-5月に正式リリース
関連記事
さくらインターネットが構築した、Apache Sparkによる原価計算システム
須藤 武文（さくらインターネット）
（現時点でスライドは公開されていないようです）
さくらインターネットの須藤さんからは、さくらインターネットの原価計算システムを作った背景とそのシステムがSparkで実行されるようになったという話がありました。これまで知らなかったんですが原価計算システムということでやはりノーチラス・テクノロジーズさんなんだなと思いました。あと、DSLにして処理系を変えられるAsakusa Frameworkの強みがはっきりと出てるなと思いました。
- 普通の業務システムの話し。コミッタとかいるわけでもない
- Sparkを使っている意識もない。Asakusa Frameworkを使っているだけで、バックエンドがMapReduceからSparkに変わったらしい
- それぐらい意識しなくてもよいものだということを話せばよいのかと考えている
- C会場で詳細を話す。ここでは頭出し
- さくらインターネットの紹介
- データセンター、バックボーン回線
- 原価計算システム
- 投下した資本は計画通り回収できるか
- サービスを提供するのにどのくらいコストがかかっているかを把握する必要がある
- コストが分かれば予測できるようになるはず
- データ量は300GB/day
- オンプレミス。サーバは売るほどある。物理サーバを30台でアドホックに増設している
関連記事
- さくらインターネットが構築した、データセンターの要素すべてを対象とした精緻な原価計算システムの仕組みとその背景 － Publickey（午前ではなく午後のセッションのレポート記事です）
ランチ&ライトニングトーク
リクルートテクノロジーズさまご提供のランチをいただきつつ、B会場のライトニングトークを聞きました。
自動的なビッグデータ機械学習技術：Spark上で複数の学習アルゴリズムの自動選択が可能に
（上田 晴康, 富士通研究所）
（現時点でスライドは公開されていないようです）
- 最初は機械学習の概要説明から
- 質問した所、参加者はほぼ機械学習知っていた
- 複数の手法を並列で試し、データサイズを増やしながら精度が上がらない手法は捨てる
- 単純な組み合わせで6日→2時間に短縮した
- 学会発表もした
- 5,000万件を超える大規模データから機械学習により数時間で予測モデルを生成する技術を開発 : 富士通の模様
Apache Sparkを用いたスケーラブルな時系列データの異常検知モデル学習ソフトウェアの開発
（河原 亮, 日本アイ・ビー・エム）
- センサー間のパターンが異なるようになる
- 予め予測モデルを作っておく部分がバッチだが、時間がかかるのでSparkを使ってみた
- Before
- LASSO回帰。大雑把に言うと最小二乗法
- ハイパーパラメータを少しずつ変えながら精度向上
- モデルの評価はCV
- After
- 自作した
- SparkのCVだとランダムだが、今回は時系列データだったので
- 気づき
- Sliding window処理は関数を1つ使うだけだが、順番が変わるバグがあるので注意？
JVM, OSレベルのチューニングによるSparkアプリケーションの最適化
（千葉 立寛, 日本アイ・ビー・エム）
- だいたいオライリーの本に書いてある
- あと論文も書いている
- IBM Research | Technical Paper Search | Workload Characterization and Optimization of TPC-H Queries on Apache Spark(Search Reports)
- 普通のIntel、Open JDKでも速いので安心してください
- Heapのサイズを変えるだけでパフォーマンスがあがる
- NUMA
- Spark1.6系になるとGCのオーバーヘッドはへっていた
データサイエンスにおける一次可視化からのSpark on Elasticsearchの利用
（大木 基至, NTTコミュニケーションズ）
（現時点でスライドは公開されていないようです）
- まずは一次可視化はElasticsearch
- 手軽にSparkからElasticsearchを操作できる
- そもそもHDFSに入れれば、、が、Elasticsearchにとりあえず入れて可視化して見せれば良いケースが大半なので
グラフデータベース事始め
（中井 亮矢, 日本オラクル）
- グラフデータベースはググると構築した、性能試してみたという記事はよく見かける
- ふと立ち止まって、何に使うのか
- 非構造データの受け皿と分析
- 受け皿とはスキーマレス
- 分析は知る/見る/切る
- 2部グラフ的な考え方（正確な2部グラフではない）
- メールとか
- 売上データで同じ手法を適用するといろいろ見えるかも
- レコードからグラフを起こせる
GunosyにおけるSpark Streaming活用事例
（森本 淳司, Gunosy）
- Kafkaを時前で運用するのがつらいのでKinesis
- Spark StreamingからRDBを利用する際の考慮点
- 集計結果をRDBに保存はあり
- Spark使うことで速報値の誤差を最小化出来るといいと思っている
午後
午後はD会場にいました。
次世代アーキテクチャから見たHadoop/Sparkの位置づけ ～特にRDMA・NVMを軸としたときの分散並列処理の観点から
神林 飛志（ノーチラステクノロジーズ）
（現時点でスライドは公開されていないようです）
ノーチラステクノロジーズの神林さんからは次世代アーキテクチャから見たHadoop/Sparkの位置づけの話でした。残念なことに移動した時点でD会場は満席でスライドを見ずに神林さんの話す内容だけメモしていました。恐らくですが、以下あたりの話をまとめて詳細に説明した内容だと思います。
- ASCII.jp：神林節炸裂！Asakusa Frameworkは「分散」から「並列」へ (1/3)
- Sparkを使うべきか、見送るべきか、何を知っておくべきか (1/4)：EnterpriseZine（エンタープライズジン）
- RSA（Rack-Scale-Architecture) - 急がば回れ、選ぶなら近道
- Multi-version Conflict Serializability - 急がば回れ、選ぶなら近道
- Storage Class Memory - 急がば回れ、選ぶなら近道
Hadoop/Sparkのアーキテクチャの次が見えてきているというのは、個人的にはかなりわくわくしました。あと、神林さんが数年前からトランザクション系の読書会を開催しているのはこの辺りを見据えてなのだなーと納得してたりしました。
- Hadoopは右側を見ている。1000ノード超え
- 20ノード程度なら効率は悪い
- Hadoopはどう見ても100ノード以上
- 何が違うかというと故障の発生率。100ノード超えると壊れるが、10ノードぐらいなら壊れない
- 障害対策の仕組みを入れるのでアーキテクチャに制約を受ける。途中にバリアを入れるとオーバーヘッドとなる。レプリケーションもオーバーヘッドになる
- どれぐらいのオーバーヘッドなら許容できるのか。100ノードなら許容できるが、10ノードならやり直せばいいので早く終わって欲しい
- 理想を言えば利用者が選べるのがいいが、出来ない
- 最悪オーバーヘッドで7割になる。3割ならいいが。。
- オープンソースなので提案したが却下された
- データサイズがデカイ方が偉いというのを誇る人がいるが、止めた方がいい。品がない
- コミッタが出てることをPRしている事自体がオープンソースではないが、そこは察してあげて
- コミッタにならないといけないというのはオープンソースではない
- 新しい形のプロプラ。要はオープンソースになったIBMとして見ればいい
- だから新しい物がでない。中で喧嘩になる
- DataFrameいらない。99%はSQLしか使わない
- ムーアの法則は終わった。Intelが主張している時点で終わってるｗ
- メニーコア、バスの高速化とか
- HPCの技術
- RSA
- インターコネクト
- NVM（不揮発性メモリ）
- 遅い。DRAMの代わりにはならない。ただしSSDより2桁速い
- 大体1000コア。
- 要は2,3年後には小型のスパコンがみなさんの手元に届く
- SoC（System on a chip）でやるので、メモリすぐ呼べる
- 全部オンプレ。オープンソースはない
- データベースを作るのが大変なのはリカバリー。車の例えで言うとエンジンがデータベース。電気自動車が出て、誰でも作れるようになった。これと同じことが起きる
- データベース関係は特許が切れるようになるのでこれからおもしろくなる
- MS一番進んでる、Oracle力技、HP脱落気味、SAPフルコミット、Hadoopガン無視
- Sparkもって2,3年。だってこっちの方が速い
- OSは普通に各ノードにOS入れるが、ほんとは分散OSにしたい。。
- MesosでRSA。。
- RSAで通信のボトルネックは取れる。ただし失敗するのでビサンチンはなくてもcommit failureはある
- データはローカルに置くのがいいという結論ではない。全体の半分ぐらいはそういう結果が出ているが、半分は遅くなっている
- 転送がネックになっている。ので、インターリーブ
- 処理を飛ばすかデータを飛ばすか
- Sparkはデータを飛ばす
- インターリーブを事前に計算できるか？→無理というのが今の結論
- joinの時に手元でやるのと飛ばすのとどっちがよいか。これはケース・バイ・ケース。やらないと分からない
- 論文でも両方やってみてstats取ればいいと書いてあるｗ
- これはおもしろい。結局アプリで決めることになる。ただし、Hadoopは制御出来ないので別のものを使うことになる
- 更新どうする。分散トランザクション
- MVCC
- どこでやるのか、ハードウェアでやるのかバージョンでやるのか
- Hadoop関係ない。捨てるので
- Linux Container？
- おれおれトランザクションマネージャを作る。これをやってるのがワークスアプリケーションズさん
- ユースケースを絞って実装
- ほんとにメンテ出来るか
- バス遅延をどうするか。これは分散系の知識
- パフォーマンスは出る。10倍は最低。100倍ぐらい出るかも
- グローバルの競争で勝てない。SIerが技術のキャップになっているユーザー企業さんは勝てない。。
- Hadoop陣営
- ガン無視する：100台以上を相手にしている。そうなったら捨てる
- アダプティブに行く
- Hadoopが無理に対応しようとするなら
- 分散OS：いらない。YARNでいい。YARNもRSAには対応すると思う。パフォーマンスが出るかは謎だが
- スケジューラ：現状だと無理。いいものが出てくればいいが
- トランザクション：無理。いまだと最初から作った方がいい。これ動くとHiveいらなくなる。技術的にも難しいし政治的にも難しい
- 障害設計：Zookeeper無理
- 全体としてもう少し身軽なら行けただろうが、、イノベーティブのジレンマに見える
- この分野は賭けるに値する。ただし、難しい。ほんとに難しい
関連記事
ビッグデータ可視化の性能を徹底検証 ～SparkSQL、Hive on Tez、Hive LLAPを用いた既存RDBデータ処理の特徴～
新郷 美紀（NEC） 蒋 逸峰（Hortonworks）
NECの新郷さんとHortonworksの蒋さんからはビッグデータ可視化の性能を徹底検証ということで、とあるクラウドDWHとSparkSQL、Hive on Tez、Hive LLAPの性能比較の話がありました。なお、このセッションからは席を確保できました。
- とあるクラウドDWHとOSS（Hive）の比較
- スタースキーマ
- Tableauからアクセス
- デフォルトの設定でHiveが遅い
- 1ヶ月前に相談を受けた。。結果出たの2,3日前。もっと早めに連絡欲しかった(^_^;)
- Spark SQLの方がデータ件数が多いと約半分の速度になった
- エグゼキュータのメモリ設定が必要。適切に設定しないと処理が途中で止まってしまった
- ブロードキャスト結合パラメータの効果
- Paruqet利用で読み込みデータ量が90%削減、処理時間を50%削減
- 今回のデータサイズだとCache Tableの効果なし
- Hiveでも大体同じぐらいの結果に出来た
- HDPのLatest Buildを使った
- TezとLLAPでそれ程差はなし
- チューニングというとSQLを見直すと思うが、午前中のYahoo! Japanのセッションでもあったように設定でチューニングできる
- Hiveチューニングの基本はデータのロード
- パーティショニング
- ORCとしてストア
- クエリ実行
- Tez/LLAPにする。MRは使わない
- CBOを使う
- Hiveのデータロード
- テキストデータをORCにするのが重要
- Hiveパーティション
- 不要なデータがスキップされる
- ORCファイルフォーマット
- カラム型フォーマット
- Hiveと相性が良い
- CBOの効果
- 今回の場合は処理が18%向上した
- Apache Tez
- MRに替わる新しい分散処理エンジン
- Hotonworksの顧客で実績もある
- Tezのチューニング
- AMとContainerの再利用
- Hive LLAP
Spark MLlib Now and Beyond
石川 有（リクルートテクノロジーズ）
リクルートテクノロジーズの石川さんからはSpark MLlibについてのお話でした。Pipeline APIを利用したことはなかったのですが、ほんと便利そうだなと思いました。ぜひ試してみたいと思いました。
- 自己紹介
- Sparkのコントリビュータ
- Sparkによる実践データ解析監訳！
- 質問
- 使ったことがある人は3〜4割
- プロダクションは5名ぐらい
- エンジニアが9割
- MLlibとは？
- spark.mllibパッケージとspark.mlパッケージがある
- spark.mllibが昔からあるパッケージ
- Spark.mlパッケージ
- DataFrameを利用した機械学習パイプラインのためのハイレベルAPIを提供
- Spark1.6ではspark.mlの利用を推奨
- Pythonのsckit-learnライブラリのAPI設計の影響を受けている
- SparkとMLlibの簡単な歴史
- spark.mllibはRDDを操作するように作られた
- spark.mlはDataFrameをサポートするように作られた
- 1.6ででたDatasetについては新しいパッケージは作らない方針
- MLlibは追加するライブラリのガイドラインがある
- よく知られているアルゴリズム
- おれおれアルゴリズムは追加しない
- スケーラブル
- DataFrame API
- 構造化データを扱うためのAPI
- 可読性が高い
- Pandasに影響を受けている
- 様々なデータソースに対応
- 豊富なビルトイン関数
- Catalystによる処理の最適化
- Pipeline API
- 以下のように同じような手順を複数繰り返す。これをPipelineとして定義することでまとめて扱える
- モデルの作成と評価
- パラメータの試行
- トークナイズ
- ロジスティクス回帰へのパラメータ
- クロスバリデーション
- 過学習の検知
- Spark1.6から学習モデルの永続化をサポート
- 学習したモデルのバージョン管理も簡単
- Spark MLlib 2.0 Roadmap
- Pipeline永続化の課題
- Pipeline中にひとつでも永続化出来ないものが含まれる場合、全体を永続化出来ない
- 永続化に対応していないモデルが含まれていないか注意する
- SparkRのMLlib対応
- PySparkに比べると遅れている
SparkによるGISデータを題材とした時系列データ処理
鈴木 由宇（IHI） 土橋 昌（NTTデータ）
IHIの鈴木さんとNTTデータの土橋さんからはSparkによるGISデータを題材とした時系列データ処理ということで、ダミーの船舶データに関するお話でした。PySparkも検討しているため、非常に参考になる内容でした。
- 背景と目的
- センサーデータは予防保全
- 製品のライフサイクル全体にわたって、製品の状態を把握
- 製品から得られたセンサーデータを使ってリモートモニタリングしたい
- GISデータは新しいサービスの開発
- センサーデータもGISデータも多変量時系列データ
- Sparkで時系列データを扱えるか懸念していた
- shuffleでは順序不定でsortが必要になる
- Sparkを用いた時系列処理
- 港湾の混雑予測にGISデータを活用する
- 船舶ごとにデータを分けた
- 船舶ごとにnumpy.arrayに入れる
- 船舶単位のデータはソートできる
- 検証
- レコード長の比較→レコード長と処理時間は比例する結果となった
- レコード長の偏りの有無の比較→ボトルネックにはならなかったが、データセットの偏りが小さかったのかもしれない
- RDDとDataFrameの比較（Spark1.5.1）→DataFrameによる処理時間の方が短くなった
- Spark1.5.1だとPySparkの場合にメモリパラーメータのチューニングに手間がかかった
- 結果の詳細
- 今回のアプリケーションのワークロード
- CPUインテンシブ
- NumPyなどのPythonライブラリとの連携
- 元々のアプリケーションがPythonで書かれていたので
- 行指向、列指向の計算
- 両アプローチの主な特徴
- アプローチ1 PySpark+RDD
- NumPyなどのPythonのライブラリを使いやすい
- アプローチ2 PySpark+DataFrame（列指向）
- PythonがJVM上で実行されるので高速
- Tungstenを利用できる
- 新しい機能を使っていてバグに当たることもあった
- PySparkを利用する場合、Pythonのデーモンが起動するのでメモリのチューニングが必要
- Skewが発生していないかSparkのUIで確認した方がよい
- ポイント
- RDDとDataFrameは、プログラムや分析者から見ると異なる使用感を得る
- experimentalが付いているのは注意が必要
-
- まとめ
- 一言で言うとSparkは使えそうだが、注意が必要
Hive on Sparkを活用した高速データ分析
加嵜 長門 （DMM.comラボ）
DMM.comラボの加嵜さんからはHive on Sparkについてのお話でした。HiveとSparkさえ知っていればそのまま利用できるというのは、既に両方を利用しているユーザーからすると移行しやすいのだと思いました。そういう意味ではHive on Tezよりも広がるのかもなーと思いました。
- 既にSlideShareにアップ済み
- 103ページあるので飛ばしつつ
- Hiveが遅い
- クエリのデバッグに時間がかかる
- 定期バッチはサービスの追加ととともに実行時間が肥大化
- 新規の学習コストを避けてHive on Sparkにした
- 3時間かかっていたHiveバッチが1時間まで短縮
- Hiveクエリの書き換えが不要
- CDH or Apacheコミュニティ版
- CDHはプロダクションでは非推奨と書かれている
- Hueからでも利用できるが実行中はAMが残り続けるのが注意点
- 初期設定ではあまりパフォーマンスは期待できない。ジョブ自体が失敗するっことも多い
- チューニングはHiveだからということはなく、普通のSparkのチューニングと変わらない
- ファイルのマージ関連の設定値がMRに合わせてあるのでメモリ不足になることがあった
- 圧縮☓ファイルマージの落とし穴
- マージ処理の前に圧縮されるので、テキストファイルはマージできない
- SequenceFileはテータの中身を圧縮するのでマージできる
- まとめ
- 導入〜運用コストが低い
- 動かないSQLがあればそれだけMRに戻せばいい
- パラメータ1つだけで高速化
- 残りはHiveで役立つSQLなのでSlideShareで見てください
関連記事
最後に
Hadoop ConferenceはHadoop Conference Japan 2011 Fallの頃から参加させてもらっていますが、毎回とても勉強させてもらっていて、企画/運営/登壇者の皆さまには本当に感謝しております。ありがとうございました！！
