サイバーエージェント社内の論文輪読会の資料です 2014/07/25

1. CAジャーナルクラブ
Dremel: Interactive Analysis
of Web-Scale Datasets
2014/07/25
山田 直行

2. 今回とりあげる論文・資料
Dremel: Interactive Analysis of Web-Scale Datasets
http://research.google.com/pubs/pub36632.html
2010年発表。それまでGoogle社内で使われてきた理論と実装を論文
にまとめて公開したもの。オープンソースの世界にデータ分析フレーム
ワークの新しいコンセプトを提示した
参考：
An Inside Look at Google BigQuery
https://cloud.google.com/files/BigQueryTechnicalWP.pdf

3. 目次
- 要約（+自分なりの要点）
- 1. Introduction
- 2. Background
- 3. Data Model
- 4. Nested Columnar Storage
- 5. Query Language
- 6. Query Executio
- 7. Experiments
- 8. Observations
- 9. Related Work
- 10. Conclusions
- MapReduceとの違い：
An Inside Look at Google BigQuery より

4. 要約（＋自分なりの要点）
Dremelとは
ネストされたデータ構造（ただし各データの構造と型は固定）に最
適化された列指向のデータストレージにより、最も少量でのディス
クのフルスキャンを行う（つまりインメモリを前提としていない）
多重の木構造からなる処理エンジン。中間にあるディスパッチャが
バランシングと再実行を行うことにより、並列数を増やすことによ
り線形にスケールする
SQLでの処理ができ、シンプルなクエリをアドホックに短時間に何
度も実行することに向く。非構造なデータや複雑なデータ処理には
向いていないという点で、MapReduceなどと補完関係にある

5. Dremelがカバーする範囲
100ミリ秒台から数分までのイ
ンタラクティブなクエリ実行に
適する
Read-Onlyが前提
100ミリ秒以下のものは全てを
インメモリで処理可能なものが
適する（MySQLやRedis）
20分以上の大規模な集計は
MapReduceやHiveなど
出典：
http://incubator.apache.org/drill/

6. Dremelと周辺技術
Dremelの実装
Apache Drill - オープンソース実装
Google BigQuery - by Google社
一部実装しているもの、参考にしているもの
Impala, Parquet, Prestoなど
MapReduce(2004年)
http://research.google.com/archive/mapreduce.html
列指向データベース(Columnar Database) 10年以上前から商用化はされている
http://en.wikipedia.org/wiki/Column-oriented_DBMS
BigTable(2006年)
BigTableはGoogleの開発したデータストレージの名前。HBaseなどと同等のレイヤー
(HBaseはBigTableをモデルとする)。
DremelはMapReduce等と同列の、データ処理フレームワークを指す

7. 1. Introduction
ネスト化されたデータ構造に列指向データストレージを適用することに
ついて（第４セクション）
Dremelのクエリ言語と実行方法について述べる。どちらも列指向の
ネスト化されたデータの処理に向いている（第５セクション）
ウェブの検索システムで使われている木構造の処理がデータベースにど
う適用できるかを述べ、データの集約における利点と効率性について述
べる（第６セクション）
数兆のレコード、数テラバイトのデータセットに対して1000 4000
のノードを使ってDremelのクエリを実行した結果について示す
（第７セクション）

8. 2. Background
具体的なユースケースを仮定してみる：
Google社のエンジニアのAliceはウェブページの新しい徴候(new
signals)を抽出するアイデアをデータを使って検証しようとしている
MapReduceジョブ→DremelでSELECTクエリ→FlumeJavaで
深堀りして分析、といった一連のフロー
これらをパイプライン処理化してダッシュボードに表示
データセットカタログに登録して他のエンジニアが閲覧する
以上のようなシナリオでは、処理システム自体とデータ管理ツールとの
相互運用をうまく回すことが求められる

9. まず第一の要素として重要なのは、汎用のストレージ層( common
storage layer )
例えばGoogle File System(他にHDFSなど)
分散処理が可能で、読み出しが高速であり、ツールを使ってデータの操
作が簡単にできること

10. 第二の要素として重要なのは、共通のストレージ形式( shared
storage format )。いわゆるカラム型ストレージは、フラットなリ
レーショナルデータについてはすでに利用されているが、Googleはこ
れをネストされたデータ形式にも適用したいという要件があった
doc{:a=>{:b =>{:c =>x, :d=>y}, :e=>z}みたいなデータについても
カラム型データとして表現できるようにする

11. 3. Data Model
ここで説明するデータモデルはProtocol Buffersで、Google社内
だけでなくオープンソースで公開されている
強く定型化されたネスト型データとして表現される
τ(タウ): データ型またはレコード型
dom: document object model
*: 繰り返し出現するフィールドであることを示す
?: オプショナルなフィールドであることを示す

12. 具体的には例えばこういうデータ:

13. 4. Nested Columnar Storage
私たちにとっての目的は、検索効率を改善するため、あるフィールドの
全てのデータをできるだけ隣接して保存すること
その取り組みは下記3点に集約される:
カラム型形式における無劣化の（可逆な）レコード形式
（4.1 Repetition and Definition Level）
高速なエンコーディング
（4.2 Splitting Records into Columns）
効率的なレコードの組み立て
（4.3 Record Assembly）

14. 4.1 Repetition and Definition Level
単一の値は、それ自体ではデータ構造を表現できない。レコード間の境
界や、繰り返しフィールドやオプショナルフィールドを表現する要素が
必要
Repetition Levels（繰り返しレベル）
どのフィールドパスにある繰り返しフィールドの値が繰り返しされて
いるのか、をnull値の付与および0以上の整数のレベルで表す
Definition Levels（定義レベル）
あるパスにあるどれだけの（未定義になりうる）フィールドが実際
に存在するのか、をnull値の付与および0以上の整数のレベルで表す

15. Encoding
できるだけ少ないビット列でこれらを表現する。省略できるものは
入れない
言葉で表現しづらいので下記のようなイメージ

16. 4.2 Splitting Records into Columns
あるレコードのデータを、どう効率的に各カラムに格納していくかにつ
いて
Googleで扱うデータの多くは非常に疎(sparse)であるため、出現す
る頻度が未定なフィールドを全て走査するのは効率が悪い
field writer を木構造で持ち、親子間でレベルを同期して必要なと
きにだけ更新をかけるようにする

17. 4.3 Record Assembly
カラム型データ構造から、いかに効率的にレコード型のデータ処理
（MapReduceなど）を行えるようにデータを取り出すかについて
FSM(finite state machine)
必要なカラムを順に渡り歩きながら各フィールドの値とレベルを読
み出してレコードとして出力する
FSMの状態＝各フィールドリーダー
Repetition Levelに沿ってFSMが順々に処理していき、次の
フィールドの読み取り、と進んでいく

18. Figure4（上図）はレコード
全体を処理する例
Figure5（下図）は2つの
フィールドだけを読み取る例

19. 5. Query Language
Dremelのクエリ言語はSQLを基礎として、ネスト化されたカラム型
ストレージのデータに適した実装になっている
正確な言語仕様は割愛
ネスト化されたカラム型データのレコードをラベルの付いた木構造とし
て表現している

20. 6. Query Execution
Tree architecture
多重階層の木構造でクエリを実行している

21. 上記のようなクエリは、下記のようなクエリに変換され、
それぞれのRは下記のようなクエリに分割されて実行されて集約される

22. Query dispatcher
Dremelはマルチユーザーで実行することができ、複数のクエリを
同時に実行可能
Slot = 末端のサーバーの数 スレッド数、として、各Slotに均等
に処理がいくように配分される。レスポンスが遅い処理があれば別
の処理へと再配分される
結果を返すのに必要なデータの割合(%)を指定することで、全ての
データを集約する前に結果を返すことで、実行時間を短縮できる

23. 7. Experiments
Local diskでの検証
レコード型とカラム型のデータの読み取りパフォーマンスの比較

24. MR(MapReduce) and Dremel
あるフィールドにある語句の数の平均を求める処理をMRと
Dremelで比較
Dremel
MapReduce(Sawzall)
numWords numRecs = 結果

25. MR-record → MR-Columnsと、MR-Columns→Dremelでそ
れぞれ一桁ずつ実行時間が短縮している

26. Serving tree topology
2段階(root-leaf)から4段階(root-mid-mid-leaf)と階層化を
深めていくことでパフォーマンスが上がっている

27. Per-tablet histograms
各tablet(1つの処理単位)は99%以上が1 2秒以内に完了している

28. Within-record aggregation
下記では、a.b.c.d(ネスト数4)およびa.b.p.q.r(ネスト数5)とい
うようにネスト階層の違ったフィールドの集計をしているが、ネス
ト型をサポートしているDremelの特性により、読み出すデータは
最小(13GB/70GB)で済むため、効率よく処理ができる

29. Scalability
leaf server数を増やすことで線形にスケールする

30. Stragglers(はぐれ者)
1%に満たないごく一部のtabletsは処理に長時間を要する

31. 8. Observations
GoogleにおいてDremelは1000兆レコードを毎月処理している
共有サーバーでも秒間1000億レコードを処理、専有サーバーならもっ
とパフォーマンスがでる
Scan-based（read-only）なクエリであれば1兆レコードまでは
インタラクティブといえる速度で処理できる
数千ノードのサーバーで処理すれば、線形にスケールする
DBMSと同様に、MapReduceもカラム型ストレージの効果がある
レコードの組み立てとパースは重い処理であるため、ソフトウェアレイ
ヤ（クエリの実行前）に最適化しておく必要がある

32. MRとクエリ処理は補完関係にできる。あるレイヤーの出力を次のレイ
ヤーの入力に渡す、ということが可能
複数ユーザーの環境下では、大規模なシステムのほうが規模の経済の恩
恵を受けやすい
スピードのために正確性を少し犠牲にできるのならば、クエリは途中で
停止させることができ、短い実行時間で結果を返すことができる
Web-scaleのデータはほとんどは高速にスキャンできるが、残りのご
く一部の割合の処理時間を短縮するのが難しい

33. 9. Related Work
MapReduce, Hadoop関係
並列処理について
カラムナーデータベースについて(XMLを使ったもの含む)
データモデルについて
SQLやその関連技術について

34. 10. Conclusions
Dremelという、大規模データをインタラクティブに分析できる分散
システムについて述べた
Dremelはシンプルな部品から構成されるデータ管理ソリューション
MapReduce的パラダイムを補完する
兆単位のレコード、数TBのデータにおけるパフォーマンスを検証した
Dremelのストレージ形式、クエリ言語、実行モデルについて述べた
今後、正式な代数的な仕様やJOINクエリ、拡張の仕組みなどについて
取り上げる予定

35. MapReduceとの違い：
An Inside Look at Google BigQuery より
!
BigQueryはインタラクティブな、数秒で終わる処理
アドホックでTry-and-errorを繰り返すような処理
MapReduceはバッチ処理、時間のかかる処理
大規模データの変換や集計で多くの時間がかかるもの
複雑なデータ処理やロジックの適用が可能
非構造化されたデータの処理が可能
多量の結果を返すケース
大きいテーブル同士JOINする場合
既存のデータの更新