Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,180 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. CAジャーナルクラブ Dremel: Interactive Analysis of Web-Scale Datasets 2014/07/25 山田 直行
  2. 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. 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. 4. 要約(+自分なりの要点) Dremelとは ネストされたデータ構造(ただし各データの構造と型は固定)に最 適化された列指向のデータストレージにより、最も少量でのディス クのフルスキャンを行う(つまりインメモリを前提としていない) 多重の木構造からなる処理エンジン。中間にあるディスパッチャが バランシングと再実行を行うことにより、並列数を増やすことによ り線形にスケールする SQLでの処理ができ、シンプルなクエリをアドホックに短時間に何 度も実行することに向く。非構造なデータや複雑なデータ処理には 向いていないという点で、MapReduceなどと補完関係にある
  5. 5. Dremelがカバーする範囲 100ミリ秒台から数分までのイ ンタラクティブなクエリ実行に 適する Read-Onlyが前提 100ミリ秒以下のものは全てを インメモリで処理可能なものが 適する(MySQLやRedis) 20分以上の大規模な集計は MapReduceやHiveなど 出典: http://incubator.apache.org/drill/
  6. 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. 7. 1. Introduction ネスト化されたデータ構造に列指向データストレージを適用することに ついて(第4セクション) Dremelのクエリ言語と実行方法について述べる。どちらも列指向の ネスト化されたデータの処理に向いている(第5セクション) ウェブの検索システムで使われている木構造の処理がデータベースにど う適用できるかを述べ、データの集約における利点と効率性について述 べる(第6セクション) 数兆のレコード、数テラバイトのデータセットに対して1000 4000 のノードを使ってDremelのクエリを実行した結果について示す
 (第7セクション)
  8. 8. 2. Background 具体的なユースケースを仮定してみる:
 Google社のエンジニアのAliceはウェブページの新しい徴候(new signals)を抽出するアイデアをデータを使って検証しようとしている MapReduceジョブ→DremelでSELECTクエリ→FlumeJavaで 深堀りして分析、といった一連のフロー これらをパイプライン処理化してダッシュボードに表示
 データセットカタログに登録して他のエンジニアが閲覧する 以上のようなシナリオでは、処理システム自体とデータ管理ツールとの 相互運用をうまく回すことが求められる
  9. 9. まず第一の要素として重要なのは、汎用のストレージ層( common storage layer ) 例えばGoogle File System(他にHDFSなど) 分散処理が可能で、読み出しが高速であり、ツールを使ってデータの操 作が簡単にできること
  10. 10. 第二の要素として重要なのは、共通のストレージ形式( shared storage format )。いわゆるカラム型ストレージは、フラットなリ レーショナルデータについてはすでに利用されているが、Googleはこ れをネストされたデータ形式にも適用したいという要件があった doc{:a=>{:b =>{:c =>x, :d=>y}, :e=>z}みたいなデータについても カラム型データとして表現できるようにする
  11. 11. 3. Data Model ここで説明するデータモデルはProtocol Buffersで、Google社内 だけでなくオープンソースで公開されている 強く定型化されたネスト型データとして表現される τ(タウ): データ型またはレコード型
 dom: document object model
 *: 繰り返し出現するフィールドであることを示す
 ?: オプショナルなフィールドであることを示す
  12. 12. 具体的には例えばこういうデータ:
  13. 13. 4. Nested Columnar Storage 私たちにとっての目的は、検索効率を改善するため、あるフィールドの 全てのデータをできるだけ隣接して保存すること その取り組みは下記3点に集約される: カラム型形式における無劣化の(可逆な)レコード形式
 (4.1 Repetition and Definition Level) 高速なエンコーディング
 (4.2 Splitting Records into Columns) 効率的なレコードの組み立て
 (4.3 Record Assembly)
  14. 14. 4.1 Repetition and Definition Level 単一の値は、それ自体ではデータ構造を表現できない。レコード間の境 界や、繰り返しフィールドやオプショナルフィールドを表現する要素が 必要 Repetition Levels(繰り返しレベル) どのフィールドパスにある繰り返しフィールドの値が繰り返しされて いるのか、をnull値の付与および0以上の整数のレベルで表す Definition Levels(定義レベル) あるパスにあるどれだけの(未定義になりうる)フィールドが実際 に存在するのか、をnull値の付与および0以上の整数のレベルで表す
  15. 15. Encoding できるだけ少ないビット列でこれらを表現する。省略できるものは 入れない 言葉で表現しづらいので下記のようなイメージ
  16. 16. 4.2 Splitting Records into Columns あるレコードのデータを、どう効率的に各カラムに格納していくかにつ いて Googleで扱うデータの多くは非常に疎(sparse)であるため、出現す る頻度が未定なフィールドを全て走査するのは効率が悪い field writer を木構造で持ち、親子間でレベルを同期して必要なと きにだけ更新をかけるようにする
  17. 17. 4.3 Record Assembly カラム型データ構造から、いかに効率的にレコード型のデータ処理 (MapReduceなど)を行えるようにデータを取り出すかについて FSM(finite state machine) 必要なカラムを順に渡り歩きながら各フィールドの値とレベルを読 み出してレコードとして出力する FSMの状態=各フィールドリーダー Repetition Levelに沿ってFSMが順々に処理していき、次の フィールドの読み取り、と進んでいく
  18. 18. Figure4(上図)はレコード 全体を処理する例 Figure5(下図)は2つの フィールドだけを読み取る例
  19. 19. 5. Query Language Dremelのクエリ言語はSQLを基礎として、ネスト化されたカラム型 ストレージのデータに適した実装になっている 正確な言語仕様は割愛 ネスト化されたカラム型データのレコードをラベルの付いた木構造とし て表現している
  20. 20. 6. Query Execution Tree architecture 多重階層の木構造でクエリを実行している
  21. 21. 上記のようなクエリは、下記のようなクエリに変換され、 それぞれのRは下記のようなクエリに分割されて実行されて集約される
  22. 22. Query dispatcher Dremelはマルチユーザーで実行することができ、複数のクエリを 同時に実行可能 Slot = 末端のサーバーの数 スレッド数、として、各Slotに均等 に処理がいくように配分される。レスポンスが遅い処理があれば別 の処理へと再配分される 結果を返すのに必要なデータの割合(%)を指定することで、全ての データを集約する前に結果を返すことで、実行時間を短縮できる
  23. 23. 7. Experiments Local diskでの検証 レコード型とカラム型のデータの読み取りパフォーマンスの比較
  24. 24. MR(MapReduce) and Dremel あるフィールドにある語句の数の平均を求める処理をMRと Dremelで比較 Dremel MapReduce(Sawzall) numWords numRecs = 結果
  25. 25. MR-record → MR-Columnsと、MR-Columns→Dremelでそ れぞれ一桁ずつ実行時間が短縮している
  26. 26. Serving tree topology 2段階(root-leaf)から4段階(root-mid-mid-leaf)と階層化を 深めていくことでパフォーマンスが上がっている
  27. 27. Per-tablet histograms 各tablet(1つの処理単位)は99%以上が1 2秒以内に完了している
  28. 28. Within-record aggregation 下記では、a.b.c.d(ネスト数4)およびa.b.p.q.r(ネスト数5)とい うようにネスト階層の違ったフィールドの集計をしているが、ネス ト型をサポートしているDremelの特性により、読み出すデータは 最小(13GB/70GB)で済むため、効率よく処理ができる
  29. 29. Scalability leaf server数を増やすことで線形にスケールする
  30. 30. Stragglers(はぐれ者) 1%に満たないごく一部のtabletsは処理に長時間を要する
  31. 31. 8. Observations GoogleにおいてDremelは1000兆レコードを毎月処理している 共有サーバーでも秒間1000億レコードを処理、専有サーバーならもっ とパフォーマンスがでる Scan-based(read-only)なクエリであれば1兆レコードまでは インタラクティブといえる速度で処理できる 数千ノードのサーバーで処理すれば、線形にスケールする DBMSと同様に、MapReduceもカラム型ストレージの効果がある レコードの組み立てとパースは重い処理であるため、ソフトウェアレイ ヤ(クエリの実行前)に最適化しておく必要がある
  32. 32. MRとクエリ処理は補完関係にできる。あるレイヤーの出力を次のレイ ヤーの入力に渡す、ということが可能 複数ユーザーの環境下では、大規模なシステムのほうが規模の経済の恩 恵を受けやすい スピードのために正確性を少し犠牲にできるのならば、クエリは途中で 停止させることができ、短い実行時間で結果を返すことができる Web-scaleのデータはほとんどは高速にスキャンできるが、残りのご く一部の割合の処理時間を短縮するのが難しい
  33. 33. 9. Related Work MapReduce, Hadoop関係 並列処理について カラムナーデータベースについて(XMLを使ったもの含む) データモデルについて SQLやその関連技術について
  34. 34. 10. Conclusions Dremelという、大規模データをインタラクティブに分析できる分散 システムについて述べた Dremelはシンプルな部品から構成されるデータ管理ソリューション MapReduce的パラダイムを補完する 兆単位のレコード、数TBのデータにおけるパフォーマンスを検証した Dremelのストレージ形式、クエリ言語、実行モデルについて述べた 今後、正式な代数的な仕様やJOINクエリ、拡張の仕組みなどについて 取り上げる予定
  35. 35. MapReduceとの違い: An Inside Look at Google BigQuery より ! BigQueryはインタラクティブな、数秒で終わる処理
 アドホックでTry-and-errorを繰り返すような処理 MapReduceはバッチ処理、時間のかかる処理
 大規模データの変換や集計で多くの時間がかかるもの
 複雑なデータ処理やロジックの適用が可能
 非構造化されたデータの処理が可能
 多量の結果を返すケース
 大きいテーブル同士JOINする場合
 既存のデータの更新
 


×