スケールアウト・インメモリ分析の標準フォーマットを目指す Apache Arrow と Value Vectors - Tokyo Apache Drill Meetup 2016/03/22

© 2016 MapR Technologies 1 © 2016 MapR Technologies 1 © 2016 MapR Technologies

スケールアウト・インメモリ分析の標準フォーマットを目指す Apache Arrow と Value Vectors 草薙昭彦 – Data Engineer, MapR Technologies 2016 年 3 月 22 日

© 2016 MapR Technologies 2 © 2016 MapR Technologies 2

自己紹介 •  草薙昭彦 (@nagix) •  MapR Technologies

データエンジニア

NS-SHAFT

無料!


Apache Arrow プロジェクト •  カラム型インメモリ分析のデファクト標準を目指す Apache プロジェク

ト •  2016年2月にトッププロジェクトとして登場

•  Apache Drill のスタートアップ Dremio がプロジェクトの中心となっており、Arrow は Drill の Value Vectors フォーマットが発祥

“Apache Arrowプロジェクトは、これらの協力プロジェクトのコミュニティや専門家集団の存在を理由として、通常は必要とされるプロジェクトの

有効性を検証するためのインキュベーターフェーズを省略し、...” インメモリビッグデータシステムをつなぐ「Apache Arrow」 http://japan.zdnet.com/article/35078163/


課題：インメモリ分析の流行

ビッグデータ初期の課題:

•  バッチ処理に特化された

処理エンジンの非効率性

•  高速な分析レスポンスの

ニーズに対するディスクア

クセスの遅さ

新たな課題:

•  各製品が独自のインメ

モリデータ表現を採用す

ることによる非効率性

インメモリ処理を最大限活用

する製品の登場

•  Impala, Drill, SAP HANA のような SQL エンジン

•  Spark, Flink のような実行

フレームワーク

•  Storm, Kafka, Apex のよう

なストリーム処理エンジン


これは非効率性だわ・・・

•  各システムは独自の内部メモリ形式を持つ

•  70〜80%のCPUはシリアライズ・デシリアライズに使われる

•  似たような機能が複数のプロジェクトで実装される

Thrift, Avro, Protobuf,…


ならばこうだ

•  すべてのシステムは共通のメモリ形式を持つ

•  システム間のやりとりにオーバーヘッドがない

•  プロジェクト間で機能を共有できる (例: Parquet-to-Arrow リーダー)


分析テクノロジーのトレンドとビジネス要件

インメモリ複合データと動的スキーマカラム型

分析に適した、Apache Parquet を始めとするカラム型データフォーマットの普及データ格納に必要なストレージ容量の削減と分析ワークロードの性能向上

メモリ上にデータを保持することによる、分析処理レスポンスの大幅な短縮もはやデータのアクセス待ちをしたい人はいない・・・

現実のデータは階層構造、ネスト構造を使うことでより簡潔に表現できる場合がある JSONやドキュメントデータベースの普及に伴い、分析システムはこれらを直接扱える必要がある

3つの要件を満たし、性能面のメリットと同時に分析の柔軟性を得ることが求められる


Arrow とは

•  SQL、JSON で定義済みの型を含む基本データ型

•  基本データ型を用いた任意の複合レコード構造をサポートするための、カラム型インメモリデータ表現形式

•  Pick-List、Hash Table、Queue のような補助データ構造

•  共有メモリ、TCP/IP、RDMA を介したプロセス間通信

データ構造アルゴリズムクロス言語バインディング

のコンビネーション

•  Java、C、C++、Python 等の言語向けのデータアクセスライブラリ

•  ビットマップ選択、ハッシュ、フィルタリング、バケッティング、ソート、マッチング等の操作のための、パイプライン化された SIMD アルゴリズム

•  カラム型インメモリ圧縮 •  不揮発性メモリ、SSD、HDD への短期的

なデータ格納のためのツール


Arrow とは •  ストレージや実行エンジンではない •  Arrow は次のようなタイプのシステムの共有基盤になることを目指す

データ分析システムストリーミング・キューイングストレージ SQL 実行エンジン

pandas � heron �


Arrow とは •  前述のプロジェクトとは競合しない •  各プロジェクトと協調し、より良い性能と相互運用性の提供をゴールと

する –  似たような機能を持つプロジェクトの乱立による非効率性が課題であったため


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 (ストリーミング処理)


カラム型フォーマット

c2 c3 c1

v12 v13 v11

v22 v23 v21

v32 v33 v31

v42 v43 v41

v52 v53 v51

c2 c3 c1

v12 v13 v11

v22 v23 v21

v32 v33 v31

v42 v43 v41

v52 v53 v51

Row-oriented フォーマット (CSV, 従来のRDB, …)

Column-oriented フォーマット (Parquet, ORC, …)


カラム型フォーマット •  分析ワークロードの性能向上

–  一部のカラムの射影 –  特定カラムの値の条件によるフィルタリング –  特定カラムの値の集計 –  すべてのデータをスキャンする必要がないケースが多い

•  ストレージ容量の削減 –  カラム内のデータは似たデータが並ぶため圧縮効率が高い –  例: ID、日付、性別

•  ・・・ただしここまではディスク上のフォーマットの話


カラム型フォーマット: メモリ上のフォーマットの場合 •  最新の 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


カラム型フォーマット: メモリ上のフォーマットの場合


データレイアウト: プリミティブデータ配列型 •  同じサイズを持つ値の固定長配列 •  全体がメモリの連続領域に配置される

–  キャッシュ局所性が向上

•  Nullable 型の場合、配列とは別に Null ビットマスク配列が用意される –  高速に Null チェックが可能


データレイアウト: List 型 •  同じ型を持つ、各要素が可変長の連

続した値を持つネストされた配列 –  違う型を持つ場合は Union 型で

•  値の配列とオフセット配列からなる

–  オフセットは先頭からの要素数 –  すべての要素に O(1) で到達可能

•  ネストデータは階層を n とすると O(n)

[　　[‘j’, ‘o’, ‘e’],　　null,　　[‘m’, ‘a’, ‘r’, ‘k’]]


データレイアウト: List 型のネスト


データレイアウト: Struct 型 •  順序と型を持つ「フィールド」要素

から構成されるネストデータ型 •  フィールドは通常名前を持つが、

名前や型は物理メモリレイアウトとは別のメタデータとして管理

•  Struct 全体の Null ビットマスクを持つことも可能

Struct [nullable] < name: String (= List<char>) [nullable], age: Int32 [not-nullable]>


データレイアウト: Dense Union 型 •  各要素が異なる型を持つ配列 •  次のメモリレイアウトを持つ

–  型ごとの子配列 –  各要素の型を格納するタイプ配列 –  各要素の子配列におけるオフセットを格納

するオフセット配列


データレイアウト: Sparse Union 型 •  Dense Union 型からオフセット配

列を除いたもの –  各子配列の長さは Union の長さと一

致する •  Dense Union 型と比べると大幅に

メモリを必要とするが利点もある –  例: 同じ長さの複数の配列がある時、

タイプ配列を定義するだけでUnion型に変換可能


Intel の SIMD 技術（SSE/AVX）

SSE AVX

Nehalem世代以前

128bit幅 SIMDレジスタ

8単精度FP演算/クロック4倍精度FP演算/クロック

128bit整数演算

AVX2 AVX-512

2015 2013 2011 〜2010

Sandy Bridge世代



Haswell世代



256bit整数演算

Skylake世代



512bit整数演算


ベクトル化 •  一般の RDBMS では 1 レコード単位の処理 •  Arrow では同時に複数レコードの処理を実行

–  複数のレコードから取り出されたカラムのセット •  Record Batch という

–  最新の CPU の機能を考慮 •  最新の CPU アーキテクチャに最適化 •  SIMD (Single Input Multiple Data) インストラクション

–  AVX インストラクションの利用により時に 100 倍の性能向上も

•  CPU パイプライン高速化のためブランチングを回避 –  処理ループをなるべく小さく、単純化

•  すべてのパイプラインが埋まっている状態にすることで効率を最大化


ベクトル化

同時に複数のレコードに対し操作を行う

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


ロードマップ •  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)


Q & A

@mapr_japan

[email protected]

ありがとうございました

maprjapan

Data & Analytics

スケールアウト・インメモリ分析の標準フォーマットを目指す Apache Arrow と Value Vectors - Tokyo Apache Drill Meetup 2016/03/22