Apache Kylin:Materialized View for BigData

1.

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

http://www.yahoo.co.jp/

2.

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

3.

自己紹介 • • • 2014/4 ~ – Yahoo! JAPANで金融やデータまわりのいろいろ – 2016/4からはストリーム処理に注力します 2011/10 ~ – ノーチラステクノロジーズでAsakusa Frameworkとか – ←はノーチラスのときに書いてもらったもの 2007/4 ~ – Simplex Technologyで金融まわりのいろいろご参考 https://www.linkedin.com/in/shingofuruyama Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 3

4.

この発表のスコープ • • 含まれているもの – アーキテクチャの概要 – Kylinに適するユースケースについての分析 – Yahoo! JAPANにおける 1.1-incubating の性能検証結果含まれていないもの – キューブの物理的なデータ構造についての詳細 – クエリ実行時のKylin ServerやHBaseの挙動についての詳細 – 1.5（最新安定版）についての詳細な情報 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 4

5.

6.

7.

8.

9.

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

10.

11.

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

12.

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

13.

14.

15.

16.

Kylinのつかいどころ • • • Kylinの強みと弱みよさそうなつかいどころ – ファクトについての分析サイクルを高速化する – レポーティングの“BigAccount”問題を回避するだめそうなつかいどころ – データ量がちいさい – アドホックなクエリを発行する分析 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 16

17.

Kylinの強みと弱み • 強み • • 弱み • キューブをプレビルドするので、“BigAccount”的なファクトの多重度の歪みに強いファクトの多重度の歪み:特定の顧客IDが大量の取引を行っており、極端にレコード数が多いキューブをプレビルドするので、ディメンションの多重度の歪みに弱いディメンションの多重度の歪み:特定のカラムのdistinct count が極端に多い Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 17

18.

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

19.

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

20.

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

21.

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

22.

弱み(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 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 22

23.

Kylinのつかいどころ • • • Kylinの強みと弱みよさそうなつかいどころ – ファクトについての分析サイクルを高速化する – レポーティングの“BigAccount”問題を回避するだめそうなつかいどころ – データ量がちいさい – アドホックなクエリを発行する分析 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 23

24.

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

25.

“BigAccount”問題を回避する • • ROLAPスタイルのクエリエンジンではクエリするときにデータに対する計算を行うので、データ量が大きい≒取引をたくさんしてくれている上客(BigAccount)であればあるほどUXが損なわれる Kylinの場合、レコード数がクエリのレイテンシに影響しないので、この問題を回避できる Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 25

26.

Kylinのつかいどころ • • • Kylinの強みと弱みよさそうなつかいどころ – ファクトについての分析サイクルを高速化する – レポーティングの“BigAccount”問題を回避するだめそうなつかいどころ – データ量がちいさい – アドホックなクエリを発行する分析 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 26

27.

28.

29.

30.

キューブの効率化についての工夫 • • キューブの概要 – キューブとは – キューブの登録 – キューブをビルドする際のジョブの流れ – キューブのセグメントとインクリメンタルビルドキューブについての工夫 – Partial Cubing/Aggregation Group – Mandatory Dimension – Hierarchy Dimension – Derived Dimension – Joint Dimension – Dictionaryによる符号化 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 30

31.

キューブの効率化についての工夫 • • キューブの概要 – キューブとは – キューブの登録 – キューブをビルドする際のジョブの流れ – キューブのセグメントとインクリメンタルビルドキューブについての工夫 – Partial Cubing/Aggregation Group – Mandatory Dimension – Hierarchy Dimension – Derived Dimension – Joint Dimension – Dictionaryによる符号化 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 31

32.

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

33.

キューブとは(2/2) – 用語の定義その2 • • 四次元のキューブ、キューボイドを図示したもの全体がキューブでキューボイドはひとつのnode 出所:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 33

34.

35.

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

36.

キューブのセグメントとインクリメンタルビルド • • キューブのビルドはセグメントに対してインクリメンタルに行うことが出来る – セグメント=1.3以前では日付、1.5以降では日付またはタイムスタンプのこと – どのカラムの値をセグメントの分割に使用するかはキューブの登録の際に決められる – セグメントに対してリテンションを持たせることが出来るインクリメンタルビルド≠ストリームビルド – インクリメンタルビルドは前回ビルドしたセグメント以降のセグメントをビルドすること – ストリームビルドはストリームデータをビルドすること Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 36

37.

キューブの効率化についての工夫 • • キューブの概要 – キューブとは – キューブの登録 – キューブをビルドする際のジョブの流れ – キューブのセグメントとインクリメンタルビルドキューブについての工夫 – Partial Cubing/Aggregation Group – Mandatory Dimension – Hierarchy Dimension – Derived Dimension – Joint Dimension – Dictionaryによる符号化 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 37

38.

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

39.

Mandatory Dimension • • • 必須のディメンジョンを指定する機能以下の例でtimeをmandatoryにすると、timeが指定されていないキューボイドは計算しなくて良くなるめっちゃきく（つかえれば）出所:http://www.slideshare.net/YangLi43/design-cube-in-apache-kylin Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 39

40.

Hierarchy Dimension • • • 論理的にありえる派生関係の組み合わせだけをつくらせるようなしていをする機能 {国->県->市}みたいな関係のあるカラム群があるときに、{県->国>市}など意味のない組み合わせを枝刈するだいぶきく（つかえれば）ご参考:http://kylin.incubator.apache.org/docs/howto/howto_optimize_cubes.html Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 40

41.

Derived Dimension • • • 一つのディメンジョン表の属性について、ディメンジョン表を結合しに行くFKがPKであると仮定して、PKだけをディメンジョンとして採用する機能 {ID、名前、生年月日}みたいなディメンジョンがあるときに、IDだけをキューブに参加させて、クエリするときに名前や生年月日を指定されたら、インメモリにディメンジョン表をもってきて結果を生成するききそう（つかってない） Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 41

42.

Joint Dimension • • • 1.5で追加されたっぽい Aggregation Groupとおなじっぽいけど概念的に整理された模様ご参考: http://kylin.apache.org/blog/2016/02/18/newaggregation-group/ Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 42

43.

Dictionaryによる符号化 • • Cubeのデータを短めの値に対応付けすることによって、HBaseに保持されるデータを削減トライ木で実装していて検索時の計算量がO(最大の文字列長) 出所:http://kylin.incubator.apache.org/blog/2015/08/13/kylin-dictionary/ Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 43

44.

45.

46.

47.

48.

49.

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

50.

Druid • • • • • • OLAP的な意味でキャラがかぶっている論文もあるしドキュメントがしっかりしていて、アーキテクチャもきれいっぽいただしただようMesos感ストリーム処理周りも独自のつくりこみがされていて、他のOSSが進化してきたときに追従するのが困難であるように見える機械学習周りのライブラリがKylinより先行しているところつらいといううわさをきいた Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 50

51.

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

52.

53.

54.

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

55.

EOP

Apache Kylin:Materialized View for BigData

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

関連スライド

深層学習による自然言語処理入門: word2vecからBERT, GPT-3まで

ゼロから始める転移学習

ヤフーにおける WebAuthn と Passkey の UX の紹介と考察 #idcon #fidcon

OpenID Connectとネイティブアプリを取り巻く仕様と動向 Yahoo! JAPANの取り組み #openid #openid_tokyo

運用業務とスクラムは本当に組み合わせにくいのか︖運用業務が大半を占めるプロダクト開発での試行錯誤

ヤフーのオンプレ機械学習基盤AIPFについて #ml_kubernetes

各ページのテキスト