Your SlideShare is downloading. ×
CAジャーナルクラブ Dremel: Interactive Analysis of Web-Scale Datasets
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CAジャーナルクラブ Dremel: Interactive Analysis of Web-Scale Datasets

633
views

Published on

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

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

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
633
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 ネスト化されたデータ構造に列指向データストレージを適用することに ついて(第4セクション) Dremelのクエリ言語と実行方法について述べる。どちらも列指向の ネスト化されたデータの処理に向いている(第5セクション) ウェブの検索システムで使われている木構造の処理がデータベースにど う適用できるかを述べ、データの集約における利点と効率性について述 べる(第6セクション) 数兆のレコード、数テラバイトのデータセットに対して1000 4000 のノードを使ってDremelのクエリを実行した結果について示す
 (第7セクション)
  • 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する場合
 既存のデータの更新
 


×