Hadoopソースコードリーディング 第20回に行ってきた
久しぶりの参加。 www.eventbrite.com
本日のお品書き
- Apache Kylin: Materialized View for Big Data
- Apache Phoenix: Relational database layer over HBase
- Upgrading from HDP2.1 to HDP2.4
Kylin, Phoenixって何だろう、という動機で参加。どちらもHBaseをデータソースとして、ユーザにSQL I/Fを提供するソフトウェア。
KylinはOLAP on HBase, PhoenixはSQL on HBaseという感じ。 Kylinはアドホッククエリが苦手で定型レポートのDBに向く。 Phoenixはデータセットをクライアントでマージするので、結果が巨大だとつらい。
どちらも参考になったが、一番興味を惹かれたのは両者が使う/使う予定のSQL Parser「Apache Calsite」の存在。 Hiveでも、コストベース最適化として、これを利用している(Hiveのクエリを何倍も速くする4つの方法 - Qiita)
Apache Kylin: Materialized View for Big Data
Yahoo! Japan. 古山慎悟
Kylin概要
- Kylinの最初の開発元eBay
- OLAP on HBase
- キューブをpre-buildしてHBaseに配置しておくことで、高速なReadアクセスを実現
- ANSI SQL対応。TableauなどのBIツールをフロントに使える
- kafkaのストリームデータを入力にキューブ作成可能
- 入力は基本、Hive table。Hiveにデータストアするまではユーザが自分で行う
- 1つのキューブがHTableに対応
- データの物理配置はHBaseのCoprocessorを使って工夫している
Kylinの強み
- 多重度の歪み、ファクトの歪みに強い
- 例えば、特定顧客が8割の売りげを占めているような場合
- 事前にpre-buildでキューブを作っているので、レイテンシがデータボリュームに依存しない
Kylinの弱み
- 多重度が高いとキューブのpre-build時間が極端にかかり、サイズも大きくなる。クエリのレイテンシも大きくなる
- そのため、なるべく多重度や次元を減らして組み合わせ数を減らす設計が必要
- 例えば、多重度が100万を超えると厳しくなる
- 事前にキューブを作成する必要があるため、アドホックなクエリに対応できない
キューブのセグメントとインクリメンタルビルド
- キューブは複数のセグメントキューブで構成される
- キューブの運用において、前回以降の差分を更新できる
- インクリメンタルビルドはストリームビルドとは異なる概念
Mandatory Dimension
- クエリする際に常に使うキーを指定することで、指定しない場合のcuboidを計算しなくてよくなる
- ex) user_id
Hierarchy Dimension
- メモれず(名前からして、階層関係を定義してあげることで、不要なディメンジョンの組合せ数を減らすのだと思う)
Derived Dimension
- ID、名前、生年月日のディメンジョンがある場合に、IDだけをキューブに参加させて、名前でクエリされた場合に、インメモリで対応関係を処理する
- (なんで高速処理できるのか、わからなかったので講演者も使っていなかったので確認できず)
- (メモリ上でキューブに名前、生年月日をひも付けた状態で展開しておくということ?それならサーバのメモリ制約がありそう)
- この辺のDocumentは充実していないらしい
Benchmark performance
- 構成:21 slave nodes, 16cores-32threads, 128GB mem, 12disk/node, HDP2.2
- Data
- Record: 500 billion over
- Cardinality: Maxで5 million over
- Result
- pre-build time: 20h
- SELECT user, sum(a), sum(b), sum(c) FROM tableで、latency = 約4 sec
- これにGROUP BYや特定ユーザ指定、期間指定を追加して対象データ範囲を絞ることで、レイテンシは小さくなる。1 sec 以下
他の低レイテンシクエリ実行エンジン
- Presto, Impala, Phoenix, etc
- OLAPカテゴリとしてはROLAP
- Kylinとは違い、クエリ時にデータを集めるので、データ量が大きいとつらくなる
- Druid
- 機械学習ライブラリがKylinよりも先行
- 独自実装が多いので普及するかは不透明。Mesos感
- Kudu
- Kuduならデータを突っ込んだ瞬間にクエリできるので、Kylinよりも筋がいいかも
- アドホッククエリにもImpala+Kuduで対応できるが、色々なワークロードが走るところで、Kuduを使って大丈夫かは不明
Kylinを使うためには
- キューブの設計が出来るアナリストが必要
- ディメンジョンの組合せ数を減らして、キューブの作成負荷を軽くする
- アドホッククエリには対応できない
- 定型レポートを参照するためのOLAPとして使える
Apache Phoenix: Relational database layer over HBase
Hortonworks Japan. 今井雄太, @imai_factory
- Phoenixの最初の開発元はSalesforce
- SQL client libraryとして動作し、データソースとしてHBaseを利用。Region Serverに対して並列に実行
- Region serverにもPhoenixクエリ実行エンジンを配置
- ドキュメントが充実
- SQL parserのApache Calciteを導入予定。CalciteはKylinでも利用している
- Phoenix tableは裏でHBaseのtableとして作成される
- この時、カラムはHBaseのcolumnとしてマッピングされ、Column Familyは使われない
- 既存HBase tableをRead OnlyなPhoenix tableとして使える
- Multi-Tenancyに対応。詳細不明
- Salted Tables
- 32を設定すれば、自動的に32個のテーブルに分割される
- 実装上は、裏でPKの値にprefixとして値を追加することで実現している
- Skip scans
- BaseはRow keyでソートされているので、不要な部分はSkipする仕組み
- 取得したデータのマージはクライアントで行う
- 当然、検索結果が巨大な場合は厳しい
HBase Availability
- Timeline Consistency
- 同一Regionを異なるRegion Serverに保存
特性
- Pros
- SQLが使える
- パフォーマンスがリニアなスケーラビリティ
- Cons
- OUTER JOINできない
- 並列ワークロード
- 複雑なJOIN
- 巨大なデータ取得
- Use cases
Benchmark
- レイテンシを小さくするために、クエリに最適化したテーブルを作ることで、ImpalaやDrillと比較して、チューニングがやりやすい。Key-Value的にテーブルを作ることでHBaseの性能を活かせる
その他
- Hive + LLAP(Long Lived excecution)との対比
- Hive on TEZ のメリット
- YARNリソースがある限りは並列度をあげられるのがメリット
- ノードを追加すれば、リソース増強できる
Upgrading from HDP2.1 to HDP2.4
@wyukawa
今は亡き@tagomorisさんのHDPクラスタ(遺産)をHDP2.4にした話 ピザで手が空いていなかったので、内容は以下参照
www.slideshare.net
@tagomorisさんの過去資料はこちら
www.slideshare.netHDP2.1を2.2にした話から、2.2を2.4にした話でアレ?ってなるけど、そこは知らない。