kiy271の日記

インフラエンジニアの備忘録

Tokyo Impala Meetup 2014.10に参加してきました

Tokyo Impala Meetup 2014.10に参加してきました。

Impala辺りはClouderaのHadoop管理者向けトレーニングにで軽く動かした程度で、実際に運用しているわけではないが、最近、Tezあたりも盛り上がってきているので、技術情報キャッチアップなどを目的として参加してきました。

やはりこのような場に参加すると、当たり前だが、今の自分の社内とは異なる環境で努力されている方々の話を聞くことでとても刺激なり、また2時間という短い時間にもかかわらず、とても濃度の高いプレゼンを聞くことが出来ました。

また、自分はImpalaをプロダクション環境で運用していないのでまだ実感はないことが多かったが、実際の運用者の工夫や、プロダクト評価者の鋭い視点をこのような場でシェアしていただくことで、自分の記憶の一部残り、とても有意義な勉強会でした。

以下、備忘のため各セッションのメモを記します。

@shiumachi Impala の最新バージョンの情報(仮)

かなり駆け足だったが、Impala2.0の機能改善の紹介。大幅に変わっているみたい。 2.0というメジャーバージョンアップということだが、Disk Spillが大きいのではないかとのこと。 詳細はスライド参照。

・Impala1.4の機能 　HDFS cashing UTF-8対応 ・Impala2.0 　Diskに大きいテーブルをSpillできるようになった。

・パフォーマンス改善 　HDFS cashing 　Partition Pruning 3000 => 30000へ

　DiskへのSpill機能がある。2.0の目玉かな。 　 → Swapよりはマシな管理をしてくれる。メモリ容量以上をつかってもデーモンが落ちなくなった。

　Subqueryがかけるようになった。 　分析関数うが増えた。集約関数ももろもある。

　APPX_COUNT_DISTINCT　正確さを犠牲にしつつ高速化をする。大体の値が欲しいなど。

　CREATE TABLE ...　LIKE PARQUIET

　new data types 　DECIMAL（Impala1.4） VARCHAR , CHAR

　SHOW PARTITIONS

　SUMMARY コマンド　簡単に処理を確認できる。

・RESOURCE MANAGEMENT Admission Control(Impala1.3)

　YARN and Llama Llama; Low Latency AM HA 機能もある。 → クエリーが最後まで終わるか？ 　　Llama単体で、失敗した時にはクエリーはキャンセルする。 　　Llama自体はリソース管理しかしていない。 　YARN上で動かせる。

・Security 　Sentryで実装。Hive,Impala用のもの。 　GRANT REVOKEができる。 　Kerberosもあり。どの程度か。

・Text + Gzipがサポート

・Gluster Sizing Guidelines for Impala。

@sudabon Impala のいい話(仮)

Impalaを利用するにあたっての、苦労話や、システム上での工夫を惜しげも無くプレゼンしてくれました。 とくに"wimpy"の話は面白かった。

Impalaのハードウェア要件　128GBなど "wimpy"　もともと古いサーバを大量に並べていた。 　 → 一台のノードは4GBで8台ぐらい。

Web行動履歴の検索用データベース → 管理画面からアドホッククエリを投げている。

マルチテナントで運用している。お客さん用のデータ。 　 → パーティションで分けている。

クエリーの対象のデータサイズはそれほど多くない。 　サマライズしているし、圧縮もしているので少ない。1TBぐらいのデータ。

課題 ・メモリ以上のデータを使うとクラッシュ、失敗する。 　 → 定常バッチでは使わない、アドホックのみ。 ・行単位の更新ができないなど、 　 → データ更新はRDBMSから変更して、Sqoopからやった。 　　HiveとImpala用のクラスタを分けた。 　　RDBMSからHDFSへのデータコピーで工夫している。 ・フォーマット変換 　 → HiveクラスタとImplaraクラスタで異なる。

Impala2.0でパフォーマンス劣化？

Cloudera Manager で管理しているが、勝手に再起動してくれるので、あまり障害に気づかない。 データ依存や、クエリー依存での障害の方がどちらかというと多い。 データフォーマットは気をつけている。（データベースでクレンジングなど）

@tosugiya YJでのImpala評価～導入（仮）

ClouderaWorldと同じ内容ということ。 検証レポートについて興味深い内容でした。パーティションとブロックサイズ（HDFS,PARQUEST）の組み合わせや、並列クエリによるレスポンス検証など。

（スライドがシェアされたらいいなぁ。。。）

データボリューム。何かの集計処理、ID処理。

・11億行/日 ・12GB/日

データ構造 30台ノードで検証 ストレージフォーマット　RCFILE,SEQUENCEFILE,AVRO,PARQUEST ストレージフォーマットはPARQUET。複雑な処理をしていないので、それほど問題がなかった。

パーティションとブロックサイズ PARQのブロックサイズも適切にする。

dfs.block.size > parquet.block.size　とのこと

・ブロックサイズ比較でのパフォーマンス評価 　ファイル数、HDFSブロックサイズ、PARQUESTブロックサイズでそれぞれ評価し、最適なところを探した。

・検証データ全量テストでは初回アクセスでは、数分かかっていたが、２回目以降は１０数秒でできた。

並列クエリによる検証 　２５並列だと4,5秒の性能劣化があった。 　 → 同じブロックへのアクセス集中が起こった。同じクエリだとかたよる。 　 → IDによってクエリを分けたが、並列度が上がった。

Metastoreの作成はHiveを使用して、Oozieアクションを実行。 → あるときからメモリ不足に陥った。M/Rのメモリチューニングを行なった。

処理時間のイメージ 　Impala：数秒～数10秒 　MapReduce：数分 　HBase：数ミリ秒

向いているサービス 　時系列のデータ参照、明細、履歴など

今後の課題・関心

どのくらいスケールするか。HBaseとの共存など。（クラウデらさんはあまりいい顔をしないらしい。。。）

@kuni_nakaji USERDIVEのimpala導入へのミチ

UNCOVER TRUTHの立ち上げメンバーということ。 UX解析ツール USERDIVE - 離脱ユーザーの全てが解るUX解析ツール「USERDIVE」、ヒートマップや動画分析でユーザー行動を可視化しUI改善します。

USERDIVEのデータ量推移　サイト内解析システムでImpalaを利用。 導入クライアント、現在は150社ぐらい。

ここでもセラン須田さんと同じく、メモリ要件（128GB推奨）が厳しく、スタートアップ企業にはクラウドを利用するにしても厳しいとのことだった。 また、MySQLを使わなかった理由は、データ量の心配からということ。

adachij SQL on Hadoop の比較検証

NTTデータ　安達さん 書籍「Hadoop徹底入門」の著者の方と同じチームに属しているらしい。

Impala、Presto（FaceBook）、Hive on Tez（HortonWorks）について、検証をしたレポート。 モチベーションは「ベンダーの検証は信用ならない」ということ。

（プレゼン資料公開してくれたら嬉しいなぁ。。。） →11/5公開していただけたようです。

パフォーマンス結果については、この界隈の人達は必見な内容だと思います。プレゼン資料を公開してくれたら嬉しいなぁ。。・ 　 → 対Hive速度比での比較でまあまあImpalaは良く、Tezもその次かな。 　 → 特にまとめは必見。

　 → Prestoは0.6でバージョンが異なるとまた違う結果があったかも。

感想

  • SQL on Hadoopはやはり人気がありますね。たしかDoug Cuttingさんが、将来的にHadoopでトランザクション処理などもできるようになり、できなくなることの方が少なくなる、オープンソースの力を信じていると語っていたと思いますが、そのアプローチのデファクトの一つとしてSQL on hadoopが担うのかもしれません。
  • ClouderaとしてImpalaをオープンソースにするとのことを言っていたと思いますが、今は企業としての商業的戦略が優先しているのでしょうか。
  • あとどうでもいい事かもしれませんが、プレゼンターの方々が楽しそうに取り組んでいて、やはり自分たちのシステムを見るのは楽しそうだなぁと感じました。

主催者の方々、プレゼンターの方々、どうもありがとうございました。

参考リンク

プログラミング Hive

プログラミング Hive