スケールアウト・インメモリ分析の標準フォーマットを目指す Apache Arrow と Value Vectors - Tokyo Apache Drill Meetup 2016/03/22
20 likes4,701 views
Apache Drill でも使われているインメモリデータ形式 Value Vectors の発展型として 2016年2月に登場した Apache Arrow プロジェクト。その背景とプロジェクトが目指すゴール、データ構造などをご紹介します。2016年3月22日に開催されたTokyo Apache Drill Meetupでの講演資料です。
![© 2016 MapR Technologies 17© 2016 MapR Technologies 17
データレイアウト: List 型
• 同じ型を持つ、各要素が可変長の連
続した値を持つネストされた配列
– 違う型を持つ場合は Union 型で
• 値の配列とオフセット配列からなる
– オフセットは先頭からの要素数
– すべての要素に O(1) で到達可能
• ネストデータは階層を n とすると O(n)
[
[‘j’, ‘o’, ‘e’],
null,
[‘m’, ‘a’, ‘r’, ‘k’]
]](https://image.slidesharecdn.com/apachearrow20160322-160322153539/85/Apache-Arrow-Value-Vectors-Tokyo-Apache-Drill-Meetup-2016-03-22-17-320.jpg){kind=icon}
![© 2016 MapR Technologies 19© 2016 MapR Technologies 19
データレイアウト: Struct 型
• 順序と型を持つ「フィールド」要素
から構成されるネストデータ型
• フィールドは通常名前を持つが、
名前や型は物理メモリレイアウト
とは別のメタデータとして管理
• Struct 全体の Null ビットマスクを
持つことも可能
Struct [nullable] <
name: String (= List<char>) [nullable],
age: Int32 [not-nullable]
>](https://image.slidesharecdn.com/apachearrow20160322-160322153539/85/Apache-Arrow-Value-Vectors-Tokyo-Apache-Drill-Meetup-2016-03-22-19-320.jpg){kind=icon}
スケールアウト・インメモリ分析の標準フォーマットを目指す Apache Arrow と Value Vectors - Tokyo Apache Drill Meetup 2016/03/22
- 1. © 2016 MapR Technologies 1© 2016 MapR Technologies 1© 2016 MapR Technologies スケールアウト・インメモリ分析の標準フォーマット を目指す Apache Arrow と Value Vectors 草薙 昭彦 – Data Engineer, MapR Technologies 2016 年 3 月 22 日
- 2. © 2016 MapR Technologies 2© 2016 MapR Technologies 2 自己紹介 • 草薙 昭彦 (@nagix) • MapR Technologies データエンジニア NS-SHAFT 無料!
- 3. © 2016 MapR Technologies 3© 2016 MapR Technologies 3 Apache Arrow プロジェクト • カラム型インメモリ分析のデファクト標準を目指す Apache プロジェク ト • 2016年2月にトッププロジェクトとして登場 • Apache Drill のスタートアップ Dremio がプロジェクトの中心となって おり、Arrow は Drill の Value Vectors フォーマットが発祥 “Apache Arrowプロジェクトは、これらの協力プロジェクトのコミュニティ や専門家集団の存在を理由として、通常は必要とされるプロジェクトの 有効性を検証するためのインキュベーターフェーズを省略し、...” インメモリビッグデータシステムをつなぐ「Apache Arrow」 http://japan.zdnet.com/article/35078163/
- 4. © 2016 MapR Technologies 4© 2016 MapR Technologies 4 課題：インメモリ分析の流行 ビッグデータ初期の課題: • バッチ処理に特化された 処理エンジンの非効率性 • 高速な分析レスポンスの ニーズに対するディスクア クセスの遅さ 新たな課題: • 各製品が独自のインメ モリデータ表現を採用す ることによる非効率性 インメモリ処理を最大限活用 する製品の登場 • Impala, Drill, SAP HANA のような SQL エンジン • Spark, Flink のような実行 フレームワーク • Storm, Kafka, Apex のよう なストリーム処理エンジン
- 5. © 2016 MapR Technologies 5© 2016 MapR Technologies 5 これは非効率性だわ・・・ • 各システムは独自の内部メモリ 形式を持つ • 70〜80%のCPUはシリアライズ・ デシリアライズに使われる • 似たような機能が複数のプロジェ クトで実装される Thrift, Avro, Protobuf,…
- 6. © 2016 MapR Technologies 6© 2016 MapR Technologies 6 ならばこうだ • すべてのシステムは共通のメモリ 形式を持つ • システム間のやりとりにオーバー ヘッドがない • プロジェクト間で機能を共有できる (例: Parquet-to-Arrow リーダー)
- 7. © 2016 MapR Technologies 7© 2016 MapR Technologies 7 分析テクノロジーのトレンドとビジネス要件 インメモリ 複合データと動的スキーマカラム型 分析に適した、Apache Parquet を始めとするカラム 型データフォーマットの普及 データ格納に必要なストレー ジ容量の削減と分析ワーク ロードの性能向上 メモリ上にデータを保持 することによる、分析処理 レスポンスの大幅な短縮 もはやデータのアクセス 待ちをしたい人はいな い・・・ 現実のデータは階層構造、ネス ト構造を使うことでより簡潔に表 現できる場合がある JSONやドキュメントデータベー スの普及に伴い、分析システム はこれらを直接扱える必要があ る 3つの要件を満たし、性能面のメリットと同時に分析の柔軟性を得ることが求められる
- 8. © 2016 MapR Technologies 8© 2016 MapR Technologies 8 Arrow とは • SQL、JSON で定義済みの型を含む基本 データ型 • 基本データ型を用いた任意の複合レコード 構造をサポートするための、カラム型インメ モリデータ表現形式 • Pick-List、Hash Table、Queue のような補 助データ構造 • 共有メモリ、TCP/IP、RDMA を介したプロ セス間通信 データ構造 アルゴリズム クロス言語バインディング のコンビネーション • Java、C、C++、Python 等の言語向けの データアクセスライブラリ • ビットマップ選択、ハッシュ、フィルタリング、 バケッティング、ソート、マッチング等の操 作のための、パイプライン化された SIMD アルゴリズム • カラム型インメモリ圧縮 • 不揮発性メモリ、SSD、HDD への短期的 なデータ格納のためのツール
- 9. © 2016 MapR Technologies 9© 2016 MapR Technologies 9 Arrow とは • ストレージや実行エンジンではない • Arrow は次のようなタイプのシステムの共有基盤になることを目指す データ分析システム ストリーミング・ キューイング ストレージSQL 実行エンジン pandas� heron�
- 10. © 2016 MapR Technologies 10© 2016 MapR Technologies 10 Arrow とは • 前述のプロジェクトとは競合しない • 各プロジェクトと協調し、より良い性能と相互運用性の提供をゴールと する – 似たような機能を持つプロジェクトの乱立による非効率性が課題であったため
- 11. © 2016 MapR Technologies 11© 2016 MapR Technologies 11 Arrow を支持するプロジェクト • Calcite (データ処理エンジン) • Cassandra (NoSQLデータストア) • Drill (SQL-on-Hadoop) • Hadoop (ビッグデータ基盤) • HBase (NoSQLデータストア) • Ibis (データ分析フレームワーク) • Impala (SQL-on-Hadoop) • Kudu (分析用ストレージ) • Pandas (データ分析ライブラリ) • Parquet (データフォーマット) • Phoenix (SQL-on-HBase) • Spark (データ分析フレームワーク) • Storm (ストリーミング処理)
- 12. © 2016 MapR Technologies 12© 2016 MapR Technologies 12 カラム型フォーマット c2 c3c1 v12 v13v11 v22 v23v21 v32 v33v31 v42 v43v41 v52 v53v51 c2 c3c1 v12 v13v11 v22 v23v21 v32 v33v31 v42 v43v41 v52 v53v51 Row-oriented フォーマット (CSV, 従来のRDB, …) Column-oriented フォーマット (Parquet, ORC, …)
- 13. © 2016 MapR Technologies 13© 2016 MapR Technologies 13 カラム型フォーマット • 分析ワークロードの性能向上 – 一部のカラムの射影 – 特定カラムの値の条件によるフィルタリング – 特定カラムの値の集計 – すべてのデータをスキャンする必要がないケースが多い • ストレージ容量の削減 – カラム内のデータは似たデータが並ぶため圧縮効率が高い – 例: ID、日付、性別 • ・・・ただしここまではディスク上のフォーマットの話
- 14. © 2016 MapR Technologies 14© 2016 MapR Technologies 14 カラム型フォーマット: メモリ上のフォーマットの場合 • 最新の CPU の機能を最大限に使いきることが 最大の目標 – キャッシュ局所性を最大化 – パイプライン実行 – SIMD 命令の活用 – これらにより10〜100倍の実行性能向上も • メモリ利用の効率化 – ベクトル化されたデータは Record Batch という単位 （最大64kレコード）でグループ化 – メモリ上に載り切らないサイズのデータの扱いが可 能 Record Batch VV VV VV VV Record Batch VV VV VV VV Record Batch VV VV VV VV VV: Value Vector
- 15. © 2016 MapR Technologies 15© 2016 MapR Technologies 15 カラム型フォーマット: メモリ上のフォーマットの場合
- 16. © 2016 MapR Technologies 16© 2016 MapR Technologies 16 データレイアウト: プリミティブデータ配列型 • 同じサイズを持つ値の固定長配列 • 全体がメモリの連続領域に配置される – キャッシュ局所性が向上 • Nullable 型の場合、配列とは別に Null ビットマスク配列が用意される – 高速に Null チェックが可能
- 17. © 2016 MapR Technologies 17© 2016 MapR Technologies 17 データレイアウト: List 型 • 同じ型を持つ、各要素が可変長の連 続した値を持つネストされた配列 – 違う型を持つ場合は Union 型で • 値の配列とオフセット配列からなる – オフセットは先頭からの要素数 – すべての要素に O(1) で到達可能 • ネストデータは階層を n とすると O(n) [ [‘j’, ‘o’, ‘e’], null, [‘m’, ‘a’, ‘r’, ‘k’] ]
- 18. © 2016 MapR Technologies 18© 2016 MapR Technologies 18 データレイアウト: List 型のネスト
- 19. © 2016 MapR Technologies 19© 2016 MapR Technologies 19 データレイアウト: Struct 型 • 順序と型を持つ「フィールド」要素 から構成されるネストデータ型 • フィールドは通常名前を持つが、 名前や型は物理メモリレイアウト とは別のメタデータとして管理 • Struct 全体の Null ビットマスクを 持つことも可能 Struct [nullable] < name: String (= List<char>) [nullable], age: Int32 [not-nullable] >
- 20. © 2016 MapR Technologies 20© 2016 MapR Technologies 20 データレイアウト: Dense Union 型 • 各要素が異なる型を持つ配列 • 次のメモリレイアウトを持つ – 型ごとの子配列 – 各要素の型を格納するタイプ配列 – 各要素の子配列におけるオフセットを格納 するオフセット配列
- 21. © 2016 MapR Technologies 21© 2016 MapR Technologies 21 データレイアウト: Sparse Union 型 • Dense Union 型からオフセット配 列を除いたもの – 各子配列の長さは Union の長さと一 致する • Dense Union 型と比べると大幅に メモリを必要とするが利点もある – 例: 同じ長さの複数の配列がある時、 タイプ配列を定義するだけでUnion型 に変換可能
- 22. © 2016 MapR Technologies 22© 2016 MapR Technologies 22 Intel の SIMD 技術（SSE/AVX） SSE AVX Nehalem世代 以前 128bit幅 SIMDレジスタ 8単精度FP演算/クロック 4倍精度FP演算/クロック 128bit整数演算 AVX2 AVX-512 201520132011〜2010 Sandy Bridge世代 256bit幅 SIMDレジスタ 16単精度FP演算/クロック 8倍精度FP演算/クロック Haswell世代 256bit幅 SIMDレジスタ 32単精度FP演算/クロック 16倍精度FP演算/クロック 256bit整数演算 Skylake世代 512bit幅 SIMDレジスタ 64単精度FP演算/クロック 32倍精度FP演算/クロック 512bit整数演算
- 23. © 2016 MapR Technologies 23© 2016 MapR Technologies 23 ベクトル化 • 一般の RDBMS では 1 レコード単位の処理 • Arrow では同時に複数レコードの処理を実行 – 複数のレコードから取り出されたカラムのセット • Record Batch という – 最新の CPU の機能を考慮 • 最新の CPU アーキテクチャに最適化 • SIMD (Single Input Multiple Data) インストラクション – AVX インストラクションの利用により時に 100 倍の性能向上も • CPU パイプライン高速化のためブランチングを回避 – 処理ループをなるべく小さく、単純化 • すべてのパイプラインが埋まっている状態にすることで効率を最大化
- 24. © 2016 MapR Technologies 24© 2016 MapR Technologies 24 ベクトル化 同時に複数のレコードに対し 操作を行う Id Name Age 101 abc 22 102 def 37 104 ghi 45 105 jkl 25 108 mno 31 112 pqr 27 114 owx 35 リレーション ベクトル化された Record Batch Id 101 102 104 105 Name abc def ghi jkl Age 22 37 45 25 108 112 114 mno pqr owx 31 27 35
- 25. © 2016 MapR Technologies 25© 2016 MapR Technologies 25 ロードマップ • 2016年内に Drill, Impala, Kudu, Ibis, Spark が Arrow に対応予定 • R, Julia, JavaScript の言語バインディングも開発進行中 • Strata + Hadoop World San Jose の次の講演 (3/30) にも注目 – Faster conclusions using in-memory columnar SQL and machine learning Wes McKinney (Cloudera), Jacques Nadeau (Dremio)
- 26. © 2016 MapR Technologies 26© 2016 MapR Technologies 26 Q&A @mapr_japan sales-jp@mapr.com ありがとうございました maprjapan