Apache Kylin:Materialized View for BigData

Apache Kylin:Materialized View for BigData
Hadoop Source Code Reading #20
http://www.yahoo.co.jp/
ヤフー株式会社古山慎悟
2016年3月24日

この資料について（2018/8追記）
• この資料は、「Hadoopソースコードリーディング第20回」の発表内
容からout-of-dateな内容を削除して公開するものです
• 発表と資料公開にタイムラグがあることに深遠な理由はなく、単に古
山が忘れていたからです
• この時点で使用していたバージョンと最新バージョンには機能・非機
能共に大きな差がありますが、基本的なコンセプトの説明資料として
は役に立つものと思います
Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 2

自己紹介
• 2014/4 ~
– Yahoo! JAPANで金融やデータまわりのいろい
ろ
– 2016/4からはストリーム処理に注力します
• 2011/10 ~
– ノーチラステクノロジーズでAsakusa
Frameworkとか
– ←はノーチラスのときに書いてもらったもの
• 2007/4 ~
– Simplex Technologyで金融まわりのいろいろ
ご参考 https://www.linkedin.com/in/shingofuruyama

この発表のスコープ
• 含まれているもの
– アーキテクチャの概要
– Kylinに適するユースケースについての分析
– Yahoo! JAPANにおける 1.1-incubating の性能検証結果
• 含まれていないもの
– キューブの物理的なデータ構造についての詳細
– クエリ実行時のKylin ServerやHBaseの挙動についての詳細
– 1.5（最新安定版）についての詳細な情報

1. Apache Kylin概観
2. Kylinのつかいどころ
3. キューブの効率化についての工夫
4. Yahoo! JAPANにおける性能検証結果
5. その他トピックス

Apache Kylin概観
• 機能の概要
• アーキテクチャの概要
• バージョニング
• 内部構造の概要

Apache Kylin概観
• 機能の概要

機能の概要
• OLAPの実行エンジンで、アナリスト向け・管理者向けのWebイン
ターフェイスを備えている
• キューブをプレビルドしてHBaseに配置することにより、オンライン
のクエリのレイテンシを下げる戦略
• 標準のSQLが話せるので、OJDBC経由でTableauなどのBIツールと接
続することもできる
• （1.5~）Kakfaに配置されているストリームデータを入力として
キューブをビルドすることができる

Apache Kylin概観
• 機能の概要

アーキテクチャの概要(1/2) – キューブのビルドとクエリの実行
Hiveテーブル
Hiveテーブル
File
File
キューブ
キューブ
• Kylinが入力としてとるのは
Hiveテーブル（Hiveテーブル
をつくるのまでは各自で）
• 1つのキューブが1つのHTable
にロードされる
• Joinした結果もキューブとし
てビルドできる
Hadoopクラスタ HBase
• Kylinは、Hiveテーブルから
データを抽出してキューブをビ
ルドしHBaseへロードする一連
のジョブの実行を制御する
• ジョブはWebUIやREST APIか
らキックできる
• クエリする際はSQLをキューブ
のスキャンに変換してデータを
返す
Kylin Server
①キューブビルドのジョブを発行
②クエリの結果はHBaseをScanして生成

アーキテクチャの概要(2/2) – キューブの論理的な構造
• 売上明細的なものから、性別
{男、女}と場所{東京、京都、
大阪}のディメンジョンで生成
したキューブの論理的な構造の
例示
• 全体をキューブ、キューブのう
ち一つの組み合わせをキューボ
イドと呼ぶ
• HBase上には、論理的には
キューブの組み合わせ分のkey
と、組み合わせごとに算出した
い値(measure)をvalueとした
一連のペアが配置される
• Keyの物理配置は図示するのが
困難だが、Coprocessorが活き
るように配置されている模様
男
男
男
東京
京都
大阪
女
女
女
東京
京都
大阪
売上合計:200 UC:約20cuboid
売上合計:100 UC:約10
cube
HTableのKey
※物理的にはだいぶ異なる
HTableのValue

Apache Kylin概観
• 機能の概要

Kylinのつかいどころ
• Kylinの強みと弱み
• よさそうなつかいどころ
– ファクトについての分析サイクルを高速化する
– レポーティングの“BigAccount”問題を回避する
• だめそうなつかいどころ
– データ量がちいさい
– アドホックなクエリを発行する分析

Kylinの強みと弱み
強み
弱み
• キューブをプレビルドするので、“BigAccount”的なファクトの
多重度の歪みに強い
• ファクトの多重度の歪み:特定の顧客IDが大量の取引を行って
おり、極端にレコード数が多い
• キューブをプレビルドするので、ディメンションの多重度の歪
みに弱い
• ディメンションの多重度の歪み:特定のカラムのdistinct count
が極端に多い

強み(1/2) – イメージ図
• トランザクションデータが大量にある集計キーがあっても、プレビル
ドしているのでレイテンシがデータボリュームに依存しない
女
ひゃくおくまん行
男
100行
トランザクションデータ
普通にやると
こっちの集計がつらい
Kylinだとどっちも
事前集計するので
ボリュームは関係ない

強み(2/2) – 解説
• Kylinのアーキテクチャだと、ファクトの歪みがクエリのレイテンシに影響し
ない
• たとえば、顧客IDに対する集計をプレビルドしておけば、顧客別の集計結果
を返すために必要なワークロードは、論理的には、どの顧客でも1件のlookup
になる
• さらに、アプリケーションからは、SQLを介してプレビルドしたキューブが透
過的にみえるので、パフォーマンスチューニングのためにデータを再設計する
必要がない

弱み(1/3) – イメージ図
• 多重度が高い（種類が多い）ディメンジョンが存在すると、キューブ
のビルドに極端に時間がかかり、キューブのサイズも大きくなる
店舗ID1:10行
トランザクションデータ
ROLAPスタイルだと、
全店舗IDが必要でなければ、
そんなにつらくない
KylinだとCuboidの数が
極端に増えてしまうこと
があるためつらい
…
店舗ID2:5行
店舗ID1,000,000:1行
店舗ID999,999:3行

弱み(2/3) – 解説
• ディメンション表に多重度が多いカラムがあると、キューブのビルド
が遅くなり、クエリのレイテンシにも悪影響がある
• 組み合わせを素直につくらない仕組みや(Aggregation Group)、組み
合わせをなるべく減らす仕組み(Mandatory Dimension, Hierarchy
Dimension, Derived Dimension)が実装されている
• ご参考: http://www.slideshare.net/YangLi43/design-cube-in-
apache-kylin

弱み(3/3) – 参考情報
• 多重度が100万を超えてくると辛みが高まる
Why Kylin calculate the HIVE table cardinality?
The cardinality of dimensions is an important measure of cube complexity. The higher the
cardinality, the bigger the cube, and thus the longer to build and the slower to query.
Cardinality > 1,000 is worth attention and > 1,000,000 should be avoided at best effort.
For optimal cube performance, try reduce high cardinality by categorize values or derive
features.
出所:http://kylin.incubator.apache.org/docs/gettingstarted/faq.html

ファクトについての分析サイクルを高速化する
• TableauなどのBIツールと組み合わせることによって、SQLをつかう
のが辛い人むけの（データに対する）インターフェイスとして機能す
る
• オンラインのクエリレイテンシは低いので、ユーザーはさまざまな観
点でデータをみることができるようになる（≒単位時間当たりの、
ユーザーの分析量が高まる）
• 副次的なメリットとして、既存EDWやHadoopのアドホックなワーク
ロードをKylinに移すことによって、既存EDWやHadoopのワークロー
ドを調節できる

“BigAccount”問題を回避する
• ROLAPスタイルのクエリエンジンではクエリするときにデータに対す
る計算を行うので、データ量が大きい≒取引をたくさんしてくれてい
る上客(BigAccount)であればあるほどUXが損なわれる
• Kylinの場合、レコード数がクエリのレイテンシに影響しないので、こ
の問題を回避できる

データ量がちいさいとき
• RDBMSをつかいましょう
• HadoopやHBaseクラスタの維持管理にまつわるあらゆるコストは
データ量が大きくないとペイしない

アドホックなクエリを発行する分析
• Kylinには事前にキューブの設定を定義したうえで、ビルドしないとク
エリできない
• 可視化ツールやアプリケーションから定型データを取る感じにしま
しょう

キューブの効率化についての工夫
• キューブの概要
– キューブとは
– キューブの登録
– キューブをビルドする際のジョブの流れ
– キューブのセグメントとインクリメンタルビルド
• キューブについての工夫
– Partial Cubing/Aggregation Group
– Mandatory Dimension
– Hierarchy Dimension
– Derived Dimension
– Joint Dimension
– Dictionaryによる符号化

– Joint Dimension

キューブとは(1/2) – 用語の定義
• キューブとは、元データをいい感じにしたデータ構造一般の名称
• 図は商品、場所、時間ごとの集計を行うことができるキューブの例
• 集計軸そのものをディメンジョンと呼ぶ
• ディメンジョンの要素の集合の数を多重度と呼ぶ
出所:http://www.slideshare.net/lukehan/1-apache-kylin-deep-dive-streaming-and-plugin-
architecture-apache-kylin-meetup-shanghai

キューブとは(2/2) – 用語の定義その2
• 四次元のキューブ、キューボイドを図示したもの
• 全体がキューブでキューボイドはひとつのnode
出所:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin

キューブの登録
• Web UIで登録する
• APIでKylinサーバーに投げることもできる

キューブをビルドする際のジョブの流れ
• 対象テーブルのデータをコピーする
• ファクトテーブルをdistinctして各ディメンジョンを抽出する
• ディメンションからDictionaryを生成する
• 各ディメンジョンからCuboidを計算する
• n次元のキューブから順に、n-1, n-1, … 2, 1次元のキューブをビルドし
ていく(k次元のビルドを行うときに、k+1次元のビルド結果を元ネタにす
ることが出来るので効率的)
• HTableのスプリットを計算
• ロード先のHTableを作成
• 各々のCuboidのビルド結果をHFileに変換
• HFileをバルクロード
• キューブのメタデータを更新（applyっぽい感じでこれが終わると検索可
能になる）
• 中間データの削除

キューブのセグメントとインクリメンタルビルド
• キューブのビルドはセグメントに対してインクリメンタルに行うこと
が出来る
– セグメント=1.3以前では日付、1.5以降では日付またはタイムスタ
ンプのこと
– どのカラムの値をセグメントの分割に使用するかはキューブの登録
の際に決められる
– セグメントに対してリテンションを持たせることが出来る
• インクリメンタルビルド≠ストリームビルド
– インクリメンタルビルドは前回ビルドしたセグメント以降のセグメ
ントをビルドすること
– ストリームビルドはストリームデータをビルドすること

– Joint Dimension

Partial Cubing/Aggregation Group
• ディメンジョンすべての組み合わせをとらないようなキューブの指定
の仕方
• ユーザーのデータ{年齢、性別、郵便番号、生年、生年月日}があると
きに、 {年齢、生年、生年月日}と{性別、郵便番号}の組み合わせだ
けでクエリするなら、それぞれ内部的に別のキューブ扱いにしてしま
えばトータルの組み合わせ数は減らせる
• 年齢×性別 ×郵便番号×生年×生年月日> (年齢×生年×生年月日) +
(性別×郵便番号)
• だいぶきく（なるべくつかいたい）

Mandatory Dimension
• 必須のディメンジョンを指定する機能
• 以下の例でtimeをmandatoryにすると、timeが指定されていない
キューボイドは計算しなくて良くなる
• めっちゃきく（つかえれば）
出所:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin

Hierarchy Dimension
• 論理的にありえる派生関係の組み合わせだけをつくらせるようなして
いをする機能
• {国->県->市}みたいな関係のあるカラム群があるときに、{県->国-
>市}など意味のない組み合わせを枝刈する
• だいぶきく（つかえれば）
ご参考:http://kylin.incubator.apache.org/docs/howto/howto_optimize_cubes.html

Derived Dimension
• 一つのディメンジョン表の属性について、ディメンジョン表を結合し
に行くFKがPKであると仮定して、PKだけをディメンジョンとして採
用する機能
• {ID、名前、生年月日}みたいなディメンジョンがあるときに、IDだ
けをキューブに参加させて、クエリするときに名前や生年月日を指定
されたら、インメモリにディメンジョン表をもってきて結果を生成す
る
• ききそう（つかってない）

Joint Dimension
• 1.5で追加されたっぽい
• Aggregation Groupとおなじっぽいけど概念的に整理された模様
• ご参考: http://kylin.apache.org/blog/2016/02/18/new-
aggregation-group/

Dictionaryによる符号化
• Cubeのデータを短めの値に対応付けすることによって、HBaseに保持
されるデータを削減
• トライ木で実装していて検索時の計算量がO(最大の文字列長)
出所:http://kylin.incubator.apache.org/blog/2015/08/13/kylin-dictionary/

その他トピックス
• 関連プロダクト
• Kylinの改善ポイント
• 運用まわりの役割設計について

関連プロダクト
• 低レイテンシクエリ実行エンジン勢
• Druid
• Kudu

低レイテンシクエリ実行エンジン勢
• Presto, Impala, Phoenixとか
• 基本的に問い合わせのあとにデータをあつめるので、データ量が大き
いとつらい傾向（当然と言えば当然）
• データ量を減らすためにPre-Aggregationすると、Pre-Aggregatedな
データを意識してアプリケーションをつくる必要が出てくる
– Kylinの場合は複雑なJoinがあってもアプリケーション的には元の
データだけ意識してクエリすればよい
– キューブの設定をかえることによって、アプリケーションに対して
透過的にパフォーマンスチューニングができる的な
• OLAP業界的にはMOLAPにあたる

Druid
• OLAP的な意味でキャラがかぶっている
• 論文もあるしドキュメントがしっかりしていて、アーキテクチャもき
れいっぽい
• ただしただようMesos感
• ストリーム処理周りも独自のつくりこみがされていて、他のOSSが進
化してきたときに追従するのが困難であるように見える
• 機械学習周りのライブラリがKylinより先行しているところ
• つらいといううわさをきいた

Kudu
• 競合として
– Kuduならデータを突っ込んだ瞬間クエリできるので、キューブビル
ドが必要なKylinよりも筋が良い可能性がある
– アドホックなクエリもImpala + Kuduで食えるはずだけど、writeを
うけてるストレージにランダムなワークロードが追加で加わるのが
どうなのかみたいな懸念はある
• ストレージとして
– KuduはHBaseよりもレンジスキャンに強く、Kylinのワークロードに
は適しているのでプラグインがあってもいいかも
– いまのところKuduではバルクロード的なものをサポートしていない
ので、バッチでビルドしたキューブをロードする際のパフォーマン
スは懸念

運用まわりの役割設計について
• Hadoopエコシステム/Kylin Serverのシステム運用管理者
– HadoopとHBaseがある程度わかっていればトラブルシュートできると思う
– ストリームビルドもするならKafka + Spark Streamingも
• キューブの設計をするアナリスト
– 要件やBIツールに合わせてキューブの設計をする
– このひとにKylinのキューブに関する知識が必要なのがつらい（展開するプラ
ンが立てづらい）
• BIツールからクエリを発行するアナリスト
– 技術的観点では、BIツールが使えさえすればよい
– 任意のSQLが発行できるようなオペレーションにしてしまうとKylinの制約に
関する知識が必要になってしまう

Apache Kylin:Materialized View for BigData

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache Kylin:Materialized View for BigData

Similar to Apache Kylin:Materialized View for BigData (20)

More from Yahoo!デベロッパーネットワーク

More from Yahoo!デベロッパーネットワーク (20)

Recently uploaded

Recently uploaded (16)

Apache Kylin:Materialized View for BigData