竹をマサカリで叩き割っていくような豪快進行の Tokyo Impala Meetup に参加してきました #impalajp

f:id:garage-kid:20141031232637p:plain

今年熱いトピックのひとつである MPP Query Engine （Rebuild: 52: TLDR Driven Development (Naoya Ito)でも取り上げられてたし）の一角、 Impala を実際に使っている方が一堂に会するという素晴らしい会が開かれるということで、今日は Tokyo Impala Meetup 2014.10 - connpass に参加してきました。

ちなみにわたし自身は Impala を運用はしていないのだけれども、やはりトレンドは追っておきたいというモチベーションで参加してきました。

Cloudera World Tokyo 2014 | Cloudera Japanが来週開催される前哨戦のようなとても熱い、内容の濃い会でした。というわけで来週のそのCloudera World Tokyo 2014 | Cloudera Japanも当然楽しみだ！（主催者の @shiumachi 氏による竹を割ったような、いや竹をマサカリで叩き割っていくような司会進行は圧巻でした。）

結構意外*1だったのは参加者が少なかった（定員内に収まってた）こと、、、、
もっと集まってもいい内容だと思ったんですが、今日は他になんかすごいイベントでもあったんですかね・・・（ハロウィーン？？？んなアホな・・・）行かなかった人は損してると個人的には思いました、よ？

ちなみにイベントの概要は以下のとおり、

開催の経緯: https://twitter.com/sudabon/status/516764981379858432

Impala もユーザが増えてきたことですし、一度ユーザ同士で色々議論するのもいいかと思ったので開催することにします。

Impala って何？って人はこちらのスライドを見てください。 http://www.slideshare.net/Cloudera_jp/evolution-of-impala-hcj2014

日時

10/31(金) 19:00 〜 21:00

場所

AP東京八重洲通り Fルーム

Agenda は以下のような感じでした。

@sudabon Impala のいい話(仮)

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

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

@kuni_nakaji USERDIVEのimpala導入へのミチ

adachij SQL on Hadoop の比較検証

それでは以降にわたしがとってきたメモを公開しておきます。
※とりあえずは公開を優先で、のちほど資料やリンクなど修正追加していきます。

@sudabon Impala のいい話(仮)

Cloudera Impalaをサービスに組み込むときに苦労した話 from Yukinori Suda

Cloudera Impala をサービスに組み込むときに苦労した話
HW requirement
- 推奨は庶民なんで無理
Cloudera Impala の評価
- In English
- 0.6 のときに server が winpy だっていわれた
- しょぼいサーバで評価すんな、、
- 1.0 のとき
  - winpy なサーバですよ、といって資料公開した
  - Mike Olson からは winpy じゃないっていわれた
セランの事業紹介
- MOBYLOG
- xross data
  - Hive, MR (CDH4.6)
    - Gzip 圧縮
  - Impala 1.4 (CDH5.1)
    - Snappy 圧縮の RCFile
      - 高速性のみを重視
      - parquet + 正規表現での検索
        
        クエリで様々な問題発生したから (クラッシュ、ノーレス、エラー)
Impala の活用方法と課題
- Web の行動履歴と検索用DB
- 課題
  - メモリ量以上のデータ量を処理するとクエリ失敗
    - ビッグデータをスモールデータに変換して利用
    - 集計時は利用しない
  - 行単位での更新削除できない
  - クエリ高速化のためにはフォーマット変換が必要
    - 顧客のデータを分離するときにフォーマットを変換
      - 大きなデータを小さくするときについでにフォーマットを変換
  - EXIST, IN 句内のサブクエリ、 get_json_object がない
  - ここだけの話、最初は prod で使う気はなかった（欲求水準を満たすものがこれしかなかった）
当初のイメージ
- 1つのクラスタに共通のテーブルをやりたい放題
実際は
- 2つのクラスタを作成し、用途に応じてクラスタを選択
  - accesslog (bigdata)
  - summarized accesslog (smalldata)
RDBMS から HDFS へコピー
- Sqoop import --direct
- 差分コピー
  - horton works のブログを参考に
  - Four-step Strategy for Incremental Updates in Apache Hive
顧客データ分離 + フォーマット変換
- パーティションが異なる 2 つのテーブル
- 2 つのテーブル間でデータ移設
Impala 2.0
- EXIST, IN の SubQuery Support
- RANK, LAG, LEAD function support
- spill to disk メカニズムの導入
- USER ML をみてると
  - Regexp_Replace/Extract に bug
  - 2.0 に移行するとパフォーマンス劣化？
- CDH 5.2 への upgrade もネックだなぁ
  - NN の Update
QA.
- 4GB memory x 8 node でやってる
- Impala 自体の安定性は？
  - Cloudera Manager から運用してると氏んでると自動であげてくれる
  - 長期間落ちてると Cloudera Manager がアラート飛ばしてくれる、が、そのアラートは受けたことない
- Impala のデータは
  - Summarized and Compressed so that few hundreds GB.

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

Impala 2.0 Update #impalajp from Cloudera Japan

impala 2.0 update
- 前回の Cloudera Tokyo では 1.3 だったので 1.4 の内容も含む
What is Impala
- Impala 分からない人いないですよね！
Impala 1.4 うれしいものを列挙してみる
- HDFS cashing DDL
- order by without LIMIT
- impala shell support UTF-8
Impala 2.0
- Hash table can spill to disk
  - ただふつーに遅くなる
- SubQuery
- Analytic function support
HDFS cashing
- New HDFS API become available CDH5
Partition Pruning improvement
- up to approximately 3,000 partitions
Spilling to Disk SQL Operation
- In PROFILE, ... will show the reports
SubQuery
Analytic Functions
- e.g. lag
- all examples you can see from the manual.
Approximation features
- APP_COUNT_DISTINCT
  - ざっくりどんくらいか、正確さは犠牲
- APP_MEDIAN
  - ざっくり中央値
CREATE TABLE ... LIKE PARQUET
ORDER BY without LIMIT
DECODE()
ANTI JOIN
- 例をみたほうが分かるよ
new data types
- DECIMAL
- VARCHAR
  - STRING with a max length
- CHAR
  - STRING with a precise length
new built in functions
- 詳細説明しないからみておけい！
SHOW PARTITIONS
SUMMARY
- impala-shell command
SET statement
- before 2.0 only in impala-shell
- enable to use from client app
Admission Control (Impala 1.3)
- Fast and lightweight resource management
- こちらを Cloudera としては使うことを進めている
- 簡単な仕組みの代わりに厳密な管理はできない
- 過信は禁物
YARN and Llama
- Llama: Application Master
- 詳しくはスライドに書いてある
- Impala1.4: GA, Llama HA support
Query Timeout
- 結果を Client が受け取ってくれないときに Timeout する
Security
- Sentry をつかっている
- RDBMS でお馴染みのコマンドが使える
- host A は Kerberos, host B は LDAP みたいなこともできるようになった
Others
- Text + gzip が使えるようになった
- impala-shell
  - UTF-8
  - .impalarc file
- Documentation
  - Cluster sizing Guildline があるので目を通しておきたまえ
QA.
- Approximate はサンプリングしてる感じ？
  - code 読み切れてないのでなんとも
- Timeout
  - Timeout になるまでは値をもちっぱなし (option)
- Resource Manager
  - Llama の HA
  - FO したあとにクエリが引き継がれるかはわからない (むずかしいんじゃないか)
- Impala 2.0 はなんで 2.0 なの？
  - なんで 1.5 じゃないの？
  - Diskspill のためじゃないの？
- 2.1 の目玉は？
  - 現時点では回答できませぬ
- JSON の field の対応は？
  - 少なくとも今は対応してない、いつになるかもわからない

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

Impala Tuning Point Best Practices
- Cloudera World Tokyo で同じ内容はなすつもり
Speaker @tosugiya
- Hadoop の経験は from 2012
Agenda
- 単一クエリがどのくらい速いか
- 並列クエリがどれくらい処理できるか
- その他
Impala
- HDFS を直接 read する低レイテンシな SQL engine
単一クエリがどのくらい速いか
- 検証データ
  - 1.1 B records
  - 12 GB(gz)/day
  - tsv file
  - total 430 B records
  - 日付＞ID＞属性でユニーク
- 検証環境
  - 30nodes
  - 6 core x 2
  - 64G RAM
  - 3T x 4
- Storage Format
  - optimized with HDFS
    - RCFILE
    - SEQUENCE FILE
    - AVRO
    - PARQUET
  - default では text の gzip 等サポートされないからストレージフォーマット選ばないといけない
  - 検討の結果、 PARQUET を採用
    - 正規表現とか複雑なことはしていないので、エラーはでてないが、、、
- パーティションとブロックサイズ
  - HDFS のブロックサイズと PARQUET のブロックサイズも適切にチューニングする
  - パーティションによる分割
    - 特定のルールでデータをグループ化
  - チューニング
    - パーティションによりファイルの分割度を調整
      - 64, 128, 256
    - dfs.block.size よりも PARQUET のブロックサイズは小さく
- 検証クエリ
  - 4,300 億行を 3,000 行に絞り込む、サイズは 300k
- ブロックサイズ比較
  - どういう設定でどういう分割をしてみたか
  - サイズが小さければ小さいほどスピードがでた
    - 256 パーティション分割
- 検証データ全量テスト
  - 最終的には 11s くらいで結果がかえるようになった
  - メタ情報のリフレッシュ直後だけは 5-6 min かかる
並列クエリがどれくらい処理できるか
- 最大 25 並列で、 5 秒程度の遅延
- 遅延の原因
  - 同一ブロックへのアクセス集中
  - 対策としては別々の並列クエリが別々のブロックにアクセスするようにする
    - 今回は ID によって分散させた
- 結果として
  - 25 並列での遅延を 3 秒ほど改善させた (2 秒の遅延ってこと)
Hive, MR のチューニング
- Hive の利用
  - MetaStore の作成は比較的長い
  - MR, Oozie で制御
  - ただし HiveMetaStore と ImpalaStateStore の同期オペレーションが必要
- Hive ジョブのエラー
  - java heap error
  - 原因はメモリ不足
    - parquet.block.size
    - パーティション数分のメモリが必要
      - 初期のメモリ設定が 1GB だった
  - 対処
    - mapreduce.xxx のパラメタチューニング
    - block size の引き下げでもおｋ
処理時間のイメージ
- Impala 数秒〜数十秒
  - リフレッシュのあとは数分
- MR: 数分〜数時間
- HBase: ミリ秒〜数秒
向いてるサービス
- 時系列データの参照系
- 明細
- 履歴情報
今後の課題・関心
- どんぐらいスケールするか
- Impala 2.0
- Impala + HBase
QA.
- PARQUET
  - block size がレコード長の半分だったのは？
    - NW のオーバーヘッドを嫌った

リンク等の追記

OOZIE-1591 / Oozie Impala Action の JIRA

@kuni_nakaji USERDIVEのimpala導入へのミチ

Userdiveによるimpala導入へのミチ from Kuni Nakaji

UNCOVER TRUSH の立ち上げメンバー
- UNSER DRIVE を開発
- Impala, Hadoop 1年半の経験
USERDIVE とは
- Web/SmartPhone 解析
  - 分析の課題解決
    - データ加工に時間かかる
    - ユーザビリティテストのコストが高い
    - 定量的な解析ができない etc...
- それらの課題を解決する 9 つの機能を提供する
  - 動画分析、マウスヒートマップ、スクロールヒートマップ、ルッキングヒートマップ、動線分析、フォーム分析、フィルター機能、ダッシュボード
USERDIVE のデータ量推移
- 去年(2013)の 5 月にローンチ
- 12 月に 100 user
- イベント量 201410 で 350,000,000 レコード
Impala を導入までの軌跡
- 第一次データ問題
  - 開発初期、ファイル DB をなぜか選んでしまった
  - inode の問題ももちろんおきた
- 第二次データ問題
  - Redis, Cassandra, MongoDB が候補に
  - トラッキングデータが JSON なので、 MongoDB を採用（パースにかかる時間を節約したかった）
  - DB lock と容量不足に悩まされる
    - トラッキングが増大すると更新が増えて DB ロックが発生し、レスポンスが劇的に低下
- そして、救世主あらわる
  - Impala
  - だけど推奨メモリ 128 GB
  - 最低 4 node
  - スタートアップにはツラい！
  - それでもメリットはあった
    - CDH によりノード管理の一元化
    - ノード拡張しやすい
    - ロックが気にならない
    - 推奨されてないのに
      - 25GB RAM を 10 個用意して 128GB を超えたようにみせかけてみた
      - VM でくんだ
- 第三次データ問題
  - CDH4.3 + Impala 1.0.1 - 1.1.1
  - データを日単位で sharding
    - バッチでデータ取得単位が大きくなり、いつまでも終了しない
    - データ増加により IO を減らす必要が
    - バグにより一定量のデータが増えてくると負荷が高騰 (IMPALA-592)
- そしてちゃんとパーティションを使うために
  - Impala 1.2.4
  - Add partition にかかった時間
    - tsv 数が増えると非線形で時間がかかる
- 第四次データ問題 (イマココ)
  - CDH4.6 + impala 1.2.4
    - データ取得サイズをさげるためにパーティションでデータ分割を考えた
  - 20万パーティションをこえるとレスポンスが劇的に低下する問題
  - 導入クライアントが増加し、ディスク容量も格段に増加
今後 impala で解決したいこと
- parquet に変更 : implala 1.4 以降
- snappy, gzip or bzip : impala 2.0 以降
- partiton 分割速度の向上 : implala 2.0 以降
大量データを扱う場合の所感
- ファイル DB は氏ねるｗ
- 安定の MySQL
  - ただし拡張性で選ばなかった
- MongoDB
  - 排他制御が大変
結局どんな流れできたのか
- 図が面白い
まとめ
- CDH のアップデートの速度は早い
QA
- Partition が多いテーブル
  - どのくらい Partition があるとどのくらい負荷があるかっていうのはある？
    - 全体で 20 万パーティションとかあると問題があるのはわかってる
    - テーブルは 200 個くらい

リンク等の追記

IMPALA-592 / Impala 1.2 で直った、性能問題の話

adachij SQL on Hadoop の比較検証

Hadoop 徹底入門の著者たちと一緒にはたらいています
SQL on Hadoop
- 今回の定義
  - Hadoop 上で動作する SQL 実行基盤
  - 低レイテンシなクエリ処理
  - HDFS 上のデータを透過的に扱える
- たくさんの SQL on Hadoop
  - Impala
  - Presto
  - Hive on Tez (HortonWorks)
    - YARN 上で動作する FrameWork
    - Hive の後継というところが他と違う
    - CDH 最新には実はパッケージングされていない、、、
  - LinkedIn Tajo, MapR Drill
Impala, Presto, Tez で検証してみた
- Vender のいうことは信頼できぬ、が理由
- impala performance dbms class speed
- presto interacting with petabyte of data at facebook
単に追試するだけではなく
- データサイズ変更
- リソースの使用状況を取得
- 小規模クラスタ
- クエリの改修
  - Impala でしか動かないクエリを他でもうごくように
- 今回はノンチューニング
  - Cloudera Manager デフォ
  - Ambari のデフォ
  - ファイルフォーマットはおすすめを
    - Impala : PARQUET, snappy
    - Tez, Presto : ORC, zlib
TPC-DS を使用したベンチマーク (Online 処理のベンチマーク)
- データサイズは数 GB - 数 TB
- HW
  - master x 1, slave x 3, client x 1
- Version
  - Impala CDH5.0
  - Tez は HDP 2.1
諸注意とか
- HW 、 Impala のことを考えたらつめるだけメモリはつんだほうがいい
- SW バージョンはそれぞれ若干古い
ベンチマーク結果
- small
  - 全プロダクトの速度中央値（対Hive）
    - Implala x34, Presto x11, Tez x ?
- medium
  - Impala x 21.9, Presto x 3.3, Tez x 2.9
- large
  - impala x 12.7, Presto x 2.0, Tez x 2.6
- xlarge
  - impala x9.3 , Presto x 0.9 (Hive より遅くなってる) , Tez x 2.3
- 全体的にデータサイズを大きくするとどのプロダクトも右肩下がり (Tez 除く)
  - Tez だけは安定して、るみたい
リソース検証
- Impala が遅くなるパターン
  - スワップが発生してパフォーマンス劣化
    - large, xlarge でメモリにのりきらないときに発生する
    - HDD, NW は問題ない
- Presto が遅くなるパターン
  - 完全にリソースを使い切っった場合はクエリが失敗するが、遅くなりながら完走する
  - CPU 使用率 10-100% を上下、バグ？
  - スワップはおきてない
- Tez はデータサイズによらない
まとめ
- Impala もっとも良い結果
  - メモリに乗らないとパフォーマンスは落ちる
- Presto 今回は残念な結果
  - 頻繁なアップデートがあるのでそれに期待
- Tez は安定的なパフォーマンスを発揮
  - CBO を有効にするなど少しのチューニングで伸びるかも？
QA.
- Tez と CDH は同居できないので、同じデータを使っている
- バッファはクリアしてからやってる
- Presto は 0.69 は ORC と相性が悪いんだよね
  - 0.70 は動かないバージョンだったから 0.69 にした経緯はある