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

今回とりあげる論文・資料

Dremel: Interactive Analysis of Web-Scale Datasets http://research.google.com/pubs/pub36632.html

2010年発表。それまでGoogle社内で使われてきた理論と実装を論文にまとめて公開したもの。オープンソースの世界にデータ分析フレームワークの新しいコンセプトを提示した

参考：An Inside Look at Google BigQueryhttps://cloud.google.com/files/BigQueryTechnicalWP.pdf

目次

- 要約（+自分なりの要点）

- 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’より

要約（＋自分なりの要点）

Dremelとは

ネストされたデータ構造（ただし各データの構造と型は固定）に最適化された列指向のデータストレージにより、最も少量でのディスクのフルスキャンを行う（つまりインメモリを前提としていない）

多重の木構造からなる処理エンジン。中間にあるディスパッチャがバランシングと再実行を行うことにより、並列数を増やすことにより線形にスケールする

SQLでの処理ができ、シンプルなクエリをアドホックに短時間に何度も実行することに向く。非構造なデータや複雑なデータ処理には向いていないという点で、MapReduceなどと補完関係にある

Dremelがカバーする範囲

100ミリ秒台から数分までのインタラクティブなクエリ実行に適する

Read-Onlyが前提

100ミリ秒以下のものは全てをインメモリで処理可能なものが適する（MySQLやRedis）

20分以上の大規模な集計はMapReduceやHiveなど

出典： http://incubator.apache.org/drill/

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等と同列の、データ処理フレームワークを指す

1. Introduction

ネスト化されたデータ構造に列指向データストレージを適用することについて（第４セクション）

Dremelのクエリ言語と実行方法について述べる。どちらも列指向のネスト化されたデータの処理に向いている（第５セクション）

ウェブの検索システムで使われている木構造の処理がデータベースにどう適用できるかを述べ、データの集約における利点と効率性について述べる（第６セクション）

数兆のレコード、数テラバイトのデータセットに対して1000~4000のノードを使ってDremelのクエリを実行した結果について示す（第７セクション）

2. Background

具体的なユースケースを仮定してみる：Google社のエンジニアのAliceはウェブページの新しい徴候(new signals)を抽出するアイデアをデータを使って検証しようとしている

MapReduceジョブ→DremelでSELECTクエリ→FlumeJavaで深堀りして分析、といった一連のフロー

これらをパイプライン処理化してダッシュボードに表示 データセットカタログに登録して他のエンジニアが閲覧する

以上のようなシナリオでは、処理システム自体とデータ管理ツールとの相互運用をうまく回すことが求められる

まず第一の要素として重要なのは、汎用のストレージ層(“common storage layer”)

例えばGoogle File System(他にHDFSなど)

分散処理が可能で、読み出しが高速であり、ツールを使ってデータの操作が簡単にできること

第二の要素として重要なのは、共通のストレージ形式(“shared storage format”)。いわゆるカラム型ストレージは、フラットなリレーショナルデータについてはすでに利用されているが、Googleはこれをネストされたデータ形式にも適用したいという要件があった

doc{:a=>{:b =>{:c =>x, :d=>y}, :e=>z}みたいなデータについてもカラム型データとして表現できるようにする

3. Data Model

ここで説明するデータモデルはProtocol Buffersで、Google社内だけでなくオープンソースで公開されている

強く定型化されたネスト型データとして表現される

τ(タウ): データ型またはレコード型dom: document object model *: 繰り返し出現するフィールドであることを示す?: オプショナルなフィールドであることを示す

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

4. Nested Columnar Storage

私たちにとっての目的は、検索効率を改善するため、あるフィールドの全てのデータをできるだけ隣接して保存すること

その取り組みは下記3点に集約される:

カラム型形式における無劣化の（可逆な）レコード形式（4.1 Repetition and Definition Level）

高速なエンコーディング（4.2 Splitting Records into Columns）

効率的なレコードの組み立て（4.3 Record Assembly）

4.1 Repetition and Definition Level

単一の値は、それ自体ではデータ構造を表現できない。レコード間の境界や、繰り返しフィールドやオプショナルフィールドを表現する要素が必要

Repetition Levels（繰り返しレベル）

どのフィールドパスにある繰り返しフィールドの値が繰り返しされているのか、をnull値の付与および0以上の整数のレベルで表す

Definition Levels（定義レベル）

あるパスにあるどれだけの（未定義になりうる）フィールドが実際に存在するのか、をnull値の付与および0以上の整数のレベルで表す

Encoding

できるだけ少ないビット列でこれらを表現する。省略できるものは入れない

言葉で表現しづらいので下記のようなイメージ

4.2 Splitting Records into Columns

あるレコードのデータを、どう効率的に各カラムに格納していくかについて

Googleで扱うデータの多くは非常に疎(sparse)であるため、出現する頻度が未定なフィールドを全て走査するのは効率が悪い

“field writer”を木構造で持ち、親子間でレベルを同期して必要なときにだけ更新をかけるようにする

4.3 Record Assembly

カラム型データ構造から、いかに効率的にレコード型のデータ処理（MapReduceなど）を行えるようにデータを取り出すかについて

FSM(finite state machine)

必要なカラムを順に渡り歩きながら各フィールドの値とレベルを読み出してレコードとして出力する

FSMの状態＝各フィールドリーダー

Repetition Levelに沿ってFSMが順々に処理していき、次のフィールドの読み取り、と進んでいく

Figure4（上図）はレコード全体を処理する例

Figure5（下図）は2つのフィールドだけを読み取る例

5. Query Language

Dremelのクエリ言語はSQLを基礎として、ネスト化されたカラム型ストレージのデータに適した実装になっている

正確な言語仕様は割愛

ネスト化されたカラム型データのレコードをラベルの付いた木構造として表現している

6. Query Execution

Tree architecture

多重階層の木構造でクエリを実行している

上記のようなクエリは、下記のようなクエリに変換され、

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

Query dispatcher

Dremelはマルチユーザーで実行することができ、複数のクエリを同時に実行可能

Slot = 末端のサーバーの数×スレッド数、として、各Slotに均等に処理がいくように配分される。レスポンスが遅い処理があれば別の処理へと再配分される

結果を返すのに必要なデータの割合(%)を指定することで、全てのデータを集約する前に結果を返すことで、実行時間を短縮できる

7. Experiments

Local diskでの検証

レコード型とカラム型のデータの読み取りパフォーマンスの比較

MR(MapReduce) and Dremel

あるフィールドにある語句の数の平均を求める処理をMRとDremelで比較

Dremel

MapReduce(Sawzall)

numWords ÷ numRecs = 結果

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

Serving tree topology

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

Per-tablet histograms

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

Within-record aggregation

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

Scalability

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

Stragglers(はぐれ者)

1%に満たないごく一部のtabletsは処理に長時間を要する

8. Observations

GoogleにおいてDremelは1000兆レコードを毎月処理している

共有サーバーでも秒間1000億レコードを処理、専有サーバーならもっとパフォーマンスがでる

Scan-based（read-only）なクエリであれば1兆レコードまではインタラクティブといえる速度で処理できる

数千ノードのサーバーで処理すれば、線形にスケールする

DBMSと同様に、MapReduceもカラム型ストレージの効果がある

レコードの組み立てとパースは重い処理であるため、ソフトウェアレイヤ（クエリの実行前）に最適化しておく必要がある

MRとクエリ処理は補完関係にできる。あるレイヤーの出力を次のレイヤーの入力に渡す、ということが可能

複数ユーザーの環境下では、大規模なシステムのほうが規模の経済の恩恵を受けやすい

スピードのために正確性を少し犠牲にできるのならば、クエリは途中で停止させることができ、短い実行時間で結果を返すことができる

Web-scaleのデータはほとんどは高速にスキャンできるが、残りのごく一部の割合の処理時間を短縮するのが難しい

9. Related Work

MapReduce, Hadoop関係

並列処理について

カラムナーデータベースについて(XMLを使ったもの含む)

データモデルについて

SQLやその関連技術について

10. Conclusions

Dremelという、大規模データをインタラクティブに分析できる分散システムについて述べた

Dremelはシンプルな部品から構成されるデータ管理ソリューション

MapReduce的パラダイムを補完する

兆単位のレコード、数TBのデータにおけるパフォーマンスを検証した

Dremelのストレージ形式、クエリ言語、実行モデルについて述べた

今後、正式な代数的な仕様やJOINクエリ、拡張の仕組みなどについて取り上げる予定

MapReduceとの違い： “An Inside Look at Google BigQuery”より

!

BigQueryはインタラクティブな、数秒で終わる処理アドホックでTry-and-errorを繰り返すような処理

MapReduceはバッチ処理、時間のかかる処理大規模データの変換や集計で多くの時間がかかるもの複雑なデータ処理やロジックの適用が可能非構造化されたデータの処理が可能多量の結果を返すケース大きいテーブル同士JOINする場合既存のデータの更新