大規模データ活用向けストレージレイヤソフトのこれまでとこれから （NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05） NTTデータ システム技術本部 OSSプロフェッショナルサービス 吉田 耕陽, 福久 琢也

1. © 2019 NTT DATA Corporation 1 © 2019 NTT DATA
Corporation
NTTデータ テクノロジーカンファレンス 2019
大規模データ活用向けストレージレイヤソフトの
これまでとこれから
2019年9月5日
株式会社NTTデータ システム技術本部 吉田 耕陽 福久 琢也

2. © 2019 NTT DATA Corporation 2
※Deepな話題に興味がある方は当チームメンバによる過去のカンファレンスでの発表資料もご参照ください。
( で検索)
本セッションでお伝えしたいこと
Hadoop誕生(2006年ごろ)からのストレージ系OSSを中心と
した技術の発展と、残存する技術課題に対する近年出現して
きたプロダクトのアプローチを若干寄り道しながら紹介します。
• お話ししない内容
• 個別の技術/ミドルウェアの”Deepな”話題(※)
• セキュリティ、コストなど直接データ蓄積・分析とは直接関係しない領域
• クラウド・オンプレミスについての話題
NTTデータ OSS SlideShare

3. © 2019 NTT DATA Corporation 3
本セッションで扱う“ストレージレイヤ”について(データ活用基盤の中での位置づけ)
データ
ソース
連携
データストア
データベース
データ処理
ストリーム処理技術
データ
活用
セキュリティ / ガバナンス
開発・運用補助機能
RDBMS
非構造データ有効活用 / インフォメーション化
データソース ユーザ
大量データ活用基盤では様々な技術要素で構成されますが、本セッションでは
「溜める」「処理する」部分について紹介します。

4. © 2019 NTT DATA Corporation 4
本セッションで扱う“ストレージレイヤ”について(技術スタック上での位置づけ)
一口にストレージ(レイヤ)といっても、昨今の分散ストレージ技術はさまざま
な技術要素の組み合わせで構成されます。本セッションでは特定の技術ではな
くストレージ関連の広範囲を扱い、ハードウェア・デバイスよりちょっと上位、
SQLにも少し触れつつその下位レイヤあたりをメインターゲットとします。
Hardware / Device
Distributed Storage
Data Format
Execution Engine
Access Interface (SQL/KVS)
Business Application
このあたりのレイヤ全般をターゲットとします。

5. © 2019 NTT DATA Corporation 5
これまで : 大量データ処理OSSの変遷

6. © 2019 NTT DATA Corporation 6
Hadoop関連エコシステムのふりかえり
2006
2008
2010
2013
2013
2013
2013
2011
2011
2006 2015
2008

7. © 2019 NTT DATA Corporation 7
Hadoop関連エコシステムのふりかえり
2006
2008
2010
2013
2013
2013
2013
2011
2011
2006 2015
2008
上記のプロダクト群を、4つの特徴的な技術要素出現に合わせて
20分程度でふりかえります
①
②
③ ④

8. © 2019 NTT DATA Corporation 8
①Hadoop誕生 Before After
2008
2013
2013
2013
2013
2011
2011
2006 2015
2006
2008
2010
①

9. © 2019 NTT DATA Corporation 9
Hadoop誕生 Before After
RDBMSなど サーバ単体での処理(当時は32bitOS、メモリ2G程度、2TB程度のHDDが
主流)で、大量のデータが、そもそも蓄積できない！現実的な時間で
処理できない！！半年かかる！！
HDFS
MapReduce 多数のサーバ(計算リソース)を透過的に1つのシステムに見せる。
ペタバイト級のストレージや、多数の計算リソースを活用した並
列分散データ処理アプリ実装を可能に。
サーバーを足せば足すほど大きく、早くなる
「Hadoopを利用することで6時間かかっていた処理が5分になった」「26日かかった処理
が20分になった」といったセンセーショナルな事例が多発。すぐに大量データ蓄積・バッ
チ処理のOSS実装のデファクトスタンダードに。
…
膨大なデータを「溜める」「処理する」際の課題を
並列分散処理で切り開く

10. © 2019 NTT DATA Corporation 10
Hadoop(MapReduce)を素で使うとちょっと大変なので…
スケーラビリティや耐障害性などの面倒な部分をHadoop(MapReduce)がよしなに扱ってくれ
るので、MapReduce上のライブラリが増えた時期。
HDFS
MapReduce
PigHive CascadingMahout Giraph
機械学習ライブラリ
グラフ処理 DSL
Twitter発
SQLライクな言語で
MapReduceを記述。
Facebookで開発され、
Apache Projectに寄贈。
Pig Latinと呼ばれる独
自言語で記述。
Yahoo!inc開発がス
タート。
…
MapReduceによる分散データ処理アプリを抽象化、
アプリ生産性を高めるためのエコシステムが数多く出現

11. © 2019 NTT DATA Corporation 11
Hadoop(HDFS + MapReduce +α)では苦手なこと
細かなデータの扱い
巨大なデータを大きな塊で扱うアーキテクチャで、シーケンシャルリード/ライトに最適化。細
かなデータの削除や更新には不向き。
細かなファイルを大量に保存した場合、メタ情報が肥大化。マスターサーバが高負荷となる。
• 例えば同じ1PBの容量をHDFSを用意する場合…
– 全ファイル1GBで10０万ファイル … マスターサーバの観点では好ましい
– 全ファイル1KBで1兆ファイル … マスターサーバ―がメモリひっ迫で問題化する
低レイテンシな処理
高スループットで大量データのバッチ処理に向くが、ミリ秒～秒単位の処理を求められるオンラ
イン処理向けではない。

12. © 2019 NTT DATA Corporation 12
②HBase : Hadoop Data Base
2006
2010
2013
2013
2013
2013
2011
2011
2006 2015
2008
2008②

13. © 2019 NTT DATA Corporation 13
HBase : Hadoop Data Base
Get、Put、Scan、Deleteのようなシンプルなデータ操作APIしか提供されないが、特にPutのス
ループット(TPS)は強力。Hadoopのスケーラビリティを受け継ぎ、ノードを追加することで
データベースの容量やRandom READ/WRITEのスループットが増強される。
HBase出現当時のユースケースとしては、Facebook MessengerのバックエンドDBとしての
利用が有名
HDFS
HBase
レコード単位のデータをそのまま低レ
イテンシ(数ミリ秒)で入出力できる。
データ取得のAPIは限定的で、Get()
かScan()のみ。
Hadoopの苦手な”細かなデータのやりとり”を補完する機能として
HBaseが登場

14. © 2019 NTT DATA Corporation 14
③分散ストリーム処理…については割愛させていただきますが
2006
2008
2010
2013
2013
2013
2013
2008
2006 2015
2011
2011
③

15. © 2019 NTT DATA Corporation 15
分散ストリーム処理
時々刻々と発生する大量データを準リアルタイムで処理したい…というユースケースに分散スト
リーム処理フレームワークのApache Stormが登場。ストリーム処理の前段のメッセージング
システムとしては、LinkedInで開発されていたApache KafkaがOSS化。
Apache Stormの初期開発者は当時Twitterのエンジニア。Tweet分析としての利用などが分か
りやすいユースケース。(例 : 今バズっているトピックの分析はバッチ処理ベースでは難しい。)
Kafka
大量のストリームデータを
「受け止める」「連携する」
データを受け取って、すぐに処理
Storm
ストリーム
処理

16. © 2019 NTT DATA Corporation 16
④SQL on Hadoop戦国時代とカラムナフォーマットの台頭
2006
2008
2010
2011
2011
2008
2006 2015
2013
2013
2013
2013
④

17. © 2019 NTT DATA Corporation 17
SQL on Hadoopの出現
2013年ごろから、低レイテンシクエリ向けのSQL on Hadoopプロダクトが複数登場。
(Impala,Presto)違いは多数あるが…後発のプロダクトとHiveとの大きな違いの一つは、
MapReduceへの依存がないこと。
MapReduceの制約から解放されメモリを積極的に活用するアーキテクチャ等で、
得意なワークロードではMR+Hiveに対して圧倒的に早い。
HDFS
MapReduce
Hive
HDFS
Presto
HDFS
Impala
大規模データ処理が浸透するにつれて、よりエンドユーザ(分析者)が使いやすくなるための
アドホッククエリ向けSQL on Hadoop製品が多数出現
HDD指向
Hadoop出現時は2G～4G/1サー
バーが主流
メモリ指向
2013年ごろになると、64G～256G/1サーバーも普及

18. © 2019 NTT DATA Corporation 18
行指向フォーマット(CSVやSequenceFile)と比べて、効率的なエンコーディング/圧縮や、(特に分析系の
クエリに対して有効な)READ処理最適化が可能になる。
• カラム型特有の最適化手法
• Column Pruning
 出力対象の特定のカラムのみREADする
• Predicate Pushdown(PPD)
 カラム毎のメタデータ(統計情報)を駆使したREADの削減
カラム型フォーマット 超概略
このファイルには2019/1/1～
2017/6/30のデータが含まれています
2019/5/15 の情報を探してい
るので、データ1と3のReadはス
キップして良さそう。
行指向の場合 列指向の場合
特定のカラムのみ必要な場合も
一旦全てリードする必要がある。
読みたいカラムのみリードしス
キャンの削減が可能
2019/10/1 ～
2019/12/31 プログラム
… …
2017/04/01 ～
2017/06/30
PPDの動作イメージ
アドホッククエリを下支えする機能として、DWH等でも利用される技術である
カラム型フォーマットをHadoop上で利用する実装が出現

19. © 2019 NTT DATA Corporation 19
カラム型フォーマットも銀の弾丸ではない(1/2)
カラム型変換処理(書き込み)や更新が高コスト
横持ちのレコード群をある程度まとめてカラムナ化するため、データの作成処理の計算コストが
高い。一度作成したら何度もREADされるようなデータに対しては有効だが、データ処理フロー
中のテンポラリな中間データ等に用いる積極的な理由はない。
メモリ上
HDD/SSD
カラム型の書き込み動作イメージ
統計情報
統計情報
書き込み

20. © 2019 NTT DATA Corporation 20
カラム型フォーマットも銀の弾丸ではない(2/2)
最適化のポテンシャルを引き出そうとすると、難しい
例えばPPDは、検索条件になるカラムで程よくソートされていないと効かない。カラムナの性質
に加えて、データの性質、アクセスパターンに対する理解と適切な設計が無ければカラムナの利
点が享受できない。
2019/5/15の情報を探しているけ
ど…どこにあるかわからないので結
局全部READするしか無さそう。
このファイルには作成者氏名が「あ～
う」から始まるデータが含まれています
作成者氏名が「き～
く」から始まる
… …
作成者氏名が「え
～か」から始まる
プログラム
前の例で、日付でソートされていない場合(例:作成者名50音順でソート)

21. © 2019 NTT DATA Corporation 21
大量データ向けストレージについて
おさえておきたいその他の要素

22. © 2019 NTT DATA Corporation 22
オブジェクトストレージ超概略
データをオブジェクト単位で管理する分散ストレージのアーキテクチャ。
近年はデータレイク(生データ、長期データ置き場)の構成要素としての利用が浸透。
 Hadoop(HDFS)に似ている点
• スケーラビリティに優れ、ペタバイト級のストレージも構築可能
 Hadoopと異なる点
• 細かなファイル保管についてはHDFSに対して有利
• 元々はデータの保管を指向していることもあり、データ処理の観点で都合の悪い特徴がある。
(例: ストレージ内のデータ移動が高コスト、Eventual Consistency、等)
AWS S3(2006年～)が歴史が長くユーザーが多い。S3以外にも多数の製品が出現しているがほ
ぼ全ての製品がS3とのAPI互換を謳い、事実上はS3(のAPI)がデファクトスタンダード
HadoopそのものもS3をストレージとして使う機能が古くからあり、Hadoopそのものにオブ
ジェクトストレージ機能の追加が始まった。2019年現在最新版であるHadoop3系から、
Hadoopのサブ機能としてApache Hadoop Ozoneが登場。

23. © 2019 NTT DATA Corporation 23
紹介したOSSはそれぞれ進化を続けるが、中にはリリース当初に比べて、メンテナンス頻度が鈍
化したり、(外部環境の変化により)方向性が変わったと思われるプロダクトも…
• 特定のプロダクトに強く依存するプロダクトは、依存先プロダクトの衰退に大きく影響を受けがち。上
記の例は、Spark等の登場によりMapReduceが劣勢になった影響も大きい。
• SQL(のような標準的な言語/API)はビッグデータ活用の広がりに合わせて、ユーザーも広がる。(独自
色の強いAPIや言語は一部の腕利きエンジニアより開発が始まったものの、長期的にはSQLに飲み込ま
れた。)
• HadoopやHBaseなど低レイヤ部分は、今でも開発は活発。アーキテクチャの進化や挑戦的機能も追
加しつつ進化を続けている
並列分散処理OSSの栄枯盛衰
HDFS
MapReduce
PigHive CascadingMahout Giraph
機械学習ライブラリではなく、
分散線形代数ライブラリに。
リリース頻度は鈍化。
リリース鈍化
最終リリースが
2017年の0.17.0
…
TezSpark
ライバルも増えたが、
バッチ処理向け基盤とし
てはまだまだ主力。開発
も機能追加も活発。
Presto Impala

24. © 2019 NTT DATA Corporation 24
後編の前に : ここまでで一旦まとめ
～なにができるようになったのか？～

25. © 2019 NTT DATA Corporation 25
ここまでの技術要素を組み合わせた典型的なアーキテクチャ
バッチ連携
ストリーム
連携
他システム
連携
データ活用
ストリーム
処理
行指向
(WRITE向き)
データ
列指向
(READ向き)
データ
データ加工・
変換処理
データ分析
やオブジェクトストレージ

26. © 2019 NTT DATA Corporation 26
ここまでの技術要素を組み合わせた典型的なアーキテクチャ
バッチ連携
ストリーム
連携
他システム
連携
データ活用
ストリーム
処理
行指向
(WRITE向き)
データ
列指向
(READ向き)
データ
データ加工・
変換処理
データ分析
やオブジェクトストレージ
①大量データが
溜められる
①大量データが
バッチ処理できる
③大量の細かなデータが
受け止められる
③大量の細かなデータが
準リアルタイムで処理できる
④前処理済みのデータに対して
分析向けアドホッククエリが実
行できる
②高スループット、低レイテンシな
レコード単位の入出力ができる
※大量データ…数百TB～PB級 高スループット…数十万～数百万TPS

27. © 2019 NTT DATA Corporation 27
ここまでのまとめと、後半への布石
理想のストレージ(スケーラビリティ、ACID準拠、低レイテンシ、高スループット、シーケン
シャルアクセスとランダムアクセス、低いコスト…)に対して、各種特化型プロダクトの組み合
わせで、トレードオフを補完しつつバランスを追い求めている。
CSV/SequenceFileなど
様々なトレードオフの例
HDD指向
メモリ指向
高スループット
(バッチ処理)
低レイテンシ
(オンライン処理)
書き込み最適
読み込み最適
準リアルタイム処理
アドホック分析

28. © 2019 NTT DATA Corporation 28
CSV/SequenceFileなど
ここまでのまとめと、後半への布石
理想のストレージ(スケーラビリティ、ACID準拠、低レイテンシ、高スループット、シーケン
シャルアクセスとランダムアクセス、低いコスト…)に対して、各種特化型プロダクトの組み合
わせで、トレードオフを補完しつつバランスを追い求めている。
様々なトレードオフの例
HDD指向
メモリ指向
高スループット
(バッチ処理)
低レイテンシ
(オンライン処理)
書き込み最適
読み込み最適
準リアルタイム処理
アドホック分析
例えば大量のデータを書き込みつつ直近データに対してSQLで柔軟に分析する
ことはこれまでの技術の組み合わせのみでは難しい…

29. © 2019 NTT DATA Corporation 29
これから：ストレージレイヤにおける課題とモダンなアプローチ
～課題と今後のアーキテクチャ～

30. © 2019 NTT DATA Corporation 30
従来からストレージレイヤに求められていること
スケーラビリティ
データ蓄積量や処理量に応じて、リソースを拡張しやすいこと
使い勝手のよさ
ユーザが利用しやすいインタフェースがあること
リーズナブルさ
特殊なHWを使わず、コモディティな製品を並べて、実現できること
耐障害性
サーバ故障が発生してもデータを失わないこと
従来からHadoopに求められてきたことは今後も求められる

31. © 2019 NTT DATA Corporation 31
近年ストレージレイヤに求められていること
ストレージレイヤ
ストリーム処理
・リアルタイムな入力
・大量かつ小粒なデータ
多様な分析
・リアルタイムな分析
・過去データも含む分析
・低レイテンシでの分析
・試行錯誤可能な分析
これからのパートではこれらの要求を踏まえた、「リアルタイム※分析」について考えていく
さらに近年では、ストリーム処理の普及や多様な分析の要求を意識した、
「リアルタイム分析」が求められてきている
※これ以降、リアルタイムとはデータが発生してから、分析などのデータ活用するまでの期間が短いことと定義します

32. © 2019 NTT DATA Corporation 32
リアルタイム分析が求められるユースケース例
1. バッチ、ストリームからの入力により、予めデータを蓄積
2. 機械学習を行い、扱いやすいモデルを作成しておく
3. 直近のアクティビティや過去履歴をもとに、リアルタイムな顧客の傾向を分析・可視化
4. 問い合わせや対応歴をもとに、有益な情報を利用者にPush通知
直近のアクティビ
ティ、問い合わせ
問い合わせに基
づくPush情報
リアルタイムな顧客
の傾向
基幹系から取得
されるトランザ
クションなど
ストレージレイヤ
バッチ
ストリーム
使用履歴
対応歴
アクティビティ、
問い合わせを説明
変数としたモデル
分析・可視化
通知
機械学習
直近のアクティビティや蓄積した過去履歴を利用した分析を行うことで、
リアルタイムに利用者や店舗に有益な情報を連携することができる
利用者
店舗

33. © 2019 NTT DATA Corporation 33
リアルタイム分析のアーキテクチャは何が課題か？
バッチ処理アーキテクチャだと
• 処理に時間がかかり、リアルタイムなデータを扱うことが困難
データレイク
ETL
データウェア
ハウス/
データマート
加工（バッチ） 分析・可視化
ストリーム処理アーキテクチャだと
• 過去データを扱うことが困難
• アドホックな分析クエリは困難
収集
加工（ストリーム）
データハブ
データマート 可視化
通知（ストリーム）
バッチ処理、ストリーム処理に特化したアーキテクチャでは、
リアルタイム性や多様な分析要求への対応が難しい

34. © 2019 NTT DATA Corporation 34
リアルタイム分析可能なアーキテクチャをどう考えるか？
ETL・加工（バッチ）
収集
加工
（ストリーム）
データハブ
リアルタイム分析
ストレージ
分析・可視化
機械学習
通知
リアルタイム分析を実現するためには、多様な要求に耐えられる、
シンプルなパイプラインを実現するストレージレイヤが必要
過去データ
リアルタイ
ムデータ
バッチ処理とストリーム処理、
両方の入力が可能
リアルタイムデータ、過去
データともに活用可能 多様な分析を実行可能
シンプルなパイプラインを実現

35. © 2019 NTT DATA Corporation 35
これから：ストレージレイヤにおける課題とモダンなアプローチ
～近年登場したOSSプロダクトとそのアプローチ～

36. © 2019 NTT DATA Corporation 36
世の中のストレージレイヤソフト
現在様々な大量データ処理に関連するプロダクトがあふれている
※ここに載せられていないプロダクトも多々あります

37. © 2019 NTT DATA Corporation 37
リアルタイム分析向けのストレージレイヤソフト
2008
2013
2013
2013
2013
2011
2011
2006
2008
2010
2019
2019
今回は近年登場してきた、リアルタイム分析に利用可能な
OSSストレージレイヤソフトをご紹介
2015

38. © 2019 NTT DATA Corporation 38
Apache Kuduの概要
誕生
• 2015年 ClouderaがApache Software Foundationに寄贈
特徴
• OLTP(OnLine Transactional Processing) とOLAP(OnLine Analytical Processing) の両立を実現
• Hadoop(HDFS)で苦手としていた、リアルタイムなデータを利用した分析処理に対応
• HBaseが苦手としていた、大量データに対する分析処理に対応
OLTPとOLAPの両立によりリアルタイム分析を可能にするストレージ
HBase HDFS
Kudu
OLTP OLAP 大量データを
リアルタイム
に分析可能
Impala, …
Impala, …
時間がかかる
分析は苦手
大量データを
リアルタイム
に分析可能

39. © 2019 NTT DATA Corporation 39
Apache Hudi (Hadoop Upserts anD Incrementals) の概要
誕生
• 2019年1月 UberがApache Incubator 加入を発表
特徴
• ニアリアルタイムな処理※により、幅広いデータ活用を実現
• 用途に応じた3種類のビュー
– Read Optimized View：リアルタイム性を落とし、読み込みのレイテンシを重視したビュー
– Realtime View：書き込んだデータをリアルタイムに読み込むことを重視したビュー
– Incremental View：変更や増分の活用向けビュー
用途に応じた3種類のビューを実現するストレージ
Hudi
※ストリーム処理より長く、バッチ処理より短い周期での処理
Read Optimized
Realtime
Incremental
低レイテンシな
分析
リアルタイムな
データを分析
増分データを連
携
Hive, Presto, …

40. © 2019 NTT DATA Corporation 40
Delta Lakeの概要
誕生
• 2019年 4月 DatabricksがOSSとして発表
特徴
• テーブル単位のACIDトランザクション実現により、整合性のとれたデータの読取りが可能
• データのバージョン管理により、分析結果の再現や同一データセットの反復利用が可能
トランザクション管理とバージョン管理を実現するストレージ
Delta Lake
整合性が取れた
状態の分析
過去と同じ分析
を再現
過去と同じデータ
セットで異なる分析
Spark

41. © 2019 NTT DATA Corporation 41
リアルタイム分析に向けたアプローチの比較
各プロダクト、リアルタイム分析を実現するために様々なアプローチをとっている
項目 Apache Kudu Apache Hudi※ Delta Lake
誕生 2015年 AFSに寄贈 2019年 Apache Incubator加入 2019年 OSSとして発表
主な開発元 Cloudera Uber Databricks
概要 OLAPとOLTPの両立によりリアルタ
イム分析を可能にするストレージ
用途に応じた3種類のビューを実現す
るストレージ
トランザクション管理とバージョン管
理を実現するストレージ
リ
ア
ル
タ
イ
ム
分
析
へ
の
ア
プ
ロ
ー
チ
フォーマット 独自のカラムナー 基本的にParquetとAvro Parquet
パーティション レンジパーティション、ハッシュパー
ティション
キーと値によるパーティション キーと値によるパーティション
主な実ファイル ベースファイルとREDOログ ベースファイルとAppendログ 実ファイルとDeltaログ
書込み方式 挿入はベースデータファイルに、更新
はREDOログに追記
常にAppendログに追記 実ファイルとDeltaログを同時に新規
作成
読込み方式 ベースファイルとREDOログを同時に
読込
ベースファイルとAppendログを同時
に読込（Realtime View）
Deltaログを元に必要な実ファイルを
読み込み
ファイル統合 コンパクションによる、REDOログ、
ベースデータファイルのマージ
コンパクションによりAppendログを
ベースファイルにマージ
Deltaログを定期的にチェックポイン
トに集約
データストア層 独自のデータストア層 HDFS or クラウドストレージを利用 HDFS or クラウドストレージを利用
常駐サービス あり なし なし
※Hudiについては主にリアルタイム性を重視したMerge-On-Readについて記載

42. © 2019 NTT DATA Corporation 42
項目 Apache Kudu Apache Hudi※ Delta Lake
誕生 2015年 AFSに寄贈 2019年 Apache Incubator加入 2019年 OSSとして発表
主な開発元 Cloudera Uber Databricks
概要 OLAPとOLTPの両立によりリアルタ
イム分析を可能にするストレージ
用途に応じた3種類のビューを実現す
るストレージ
トランザクション管理とバージョン管
理を実現するストレージ
リ
ア
ル
タ
イ
ム
分
析
へ
の
ア
プ
ロ
ー
チ
フォーマット 独自のカラムナー 基本的にParquetとAvro Parquet
パーティション レンジパーティション、ハッシュパー
ティション
キーと値によるパーティション キーと値によるパーティション
主な実ファイル ベースファイルとREDOログ ベースファイルとAppendログ 実ファイルとDeltaログ
書込み方式 挿入はベースデータファイルに、更新
はREDOログに追記
常にAppendログに追記 実ファイルとDeltaログを同時に新規
作成
読込み方式 ベースファイルとREDOログを同時に
読込
ベースファイルとAppendログを同時
に読込（Realtime View）
Deltaログを元に必要な実ファイルを
読み込み
ファイル統合 コンパクションによる、REDOログ、
ベースデータファイルのマージ
コンパクションによりAppendログを
ベースファイルにマージ
Deltaログを定期的にチェックポイン
トに集約
データストア層 独自のデータストア層 HDFS or クラウドストレージを利用 HDFS or クラウドストレージを利用
常駐サービス あり なし なし
※Hudiについては主にリアルタイム性を重視したMerge-On-Readについて記載
リアルタイム分析に向けたアプローチの比較
各プロダクト、リアルタイム分析を実現するために様々なアプローチをとっている

43. © 2019 NTT DATA Corporation 43
フォーマット
• Apache Kuduは独自のカラムナーフォーマット
• Apache Hudiは分析のベースファイルは基本的にはparquet
• Delta Lakeのフォーマットはparquet
分析向けのストレージのフォーマットは、READ効率のよい共通してカラムナーで実現
読みたいカラムのみリードしスキャンの削減が可能

44. © 2019 NTT DATA Corporation 44
項目 Apache Kudu Apache Hudi※ Delta Lake
誕生 2015年 AFSに寄贈 2019年 Apache Incubator加入 2019年 OSSとして発表
主な開発元 Cloudera Uber Databricks
概要 OLAPとOLTPの両立によりリアルタ
イム分析を可能にするストレージ
用途に応じた3種類のビューを実現す
るストレージ
トランザクション管理とバージョン管
理を実現するストレージ
リ
ア
ル
タ
イ
ム
分
析
へ
の
ア
プ
ロ
ー
チ
フォーマット 独自のカラムナー 基本的にParquetとAvro Parquet
パーティション レンジパーティション、ハッシュパー
ティション
キーと値によるパーティション キーと値によるパーティション
主な実ファイル ベースファイルとREDOログ ベースファイルとAppendログ 実ファイルとDeltaログ
書込み方式 挿入はベースデータファイルに、更新
はREDOログに追記
常にAppendログに追記 実ファイルとDeltaログを同時に新規
作成
読込み方式 ベースファイルとREDOログを同時に
読込
ベースファイルとAppendログを同時
に読込（Realtime View）
Deltaログを元に必要な実ファイルを
読み込み
ファイル統合 コンパクションによる、REDOログ、
ベースデータファイルのマージ
コンパクションによりAppendログを
ベースファイルにマージ
Deltaログを定期的にチェックポイン
トに集約
データストア層 独自のデータストア層 HDFS or クラウドストレージを利用 HDFS or クラウドストレージを利用
常駐サービス あり なし なし
※Hudiについては主にリアルタイム性を重視したMerge-On-Readについて記載
リアルタイム分析に向けたアプローチの比較
各プロダクト、リアルタイム分析を実現するために様々なアプローチをとっている

45. © 2019 NTT DATA Corporation 45
xx_table
2019-01-01 2019-01-02 2019-01-03
パーティション
• Apache Hudi、Delta Lakeはパーティションキーの値ベースのパーティションを実現
– 従来からあった、Hiveなどと同じ仕組み
• Apache Kuduにはレンジ、ハッシュを組み合わせてパーティション化できる
パーティションを利用することでスキャン範囲や処理範囲を限定することができる
Kuduはレンジパーティション、ハッシュパーティションを実現可能
Apache Hudi, Delta Lake のパーティションイメージ
…
Apache Kudu のマルチパーティションイメージ
xx_table
2019-01-01～07
ID:101,105,107..
2019-01-01～07
ID:102,103,108..
…
…
…
7日毎のレンジ
ID毎の
ハッシュ
2019-01-01～07
ID:104,106,109..
2019-01-08～14
ID:101,105,107..
2019-01-08～14
ID:102,103,108..
2019-01-08～14
ID:104,106,109..

46. © 2019 NTT DATA Corporation 46
項目 Apache Kudu Apache Hudi※ Delta Lake
誕生 2015年 AFSに寄贈 2019年 Apache Incubator加入 2019年 OSSとして発表
主な開発元 Cloudera Uber Databricks
概要 OLAPとOLTPの両立によりリアルタ
イム分析を可能にするストレージ
用途に応じた3種類のビューを実現す
るストレージ
トランザクション管理とバージョン管
理を実現するストレージ
リ
ア
ル
タ
イ
ム
分
析
へ
の
ア
プ
ロ
ー
チ
フォーマット 独自のカラムナー 基本的にParquetとAvro Parquet
パーティション レンジパーティション、ハッシュパー
ティション
キーと値によるパーティション キーと値によるパーティション
主な実ファイル ベースファイルとREDOログ ベースファイルとAppendログ 実ファイルとDeltaログ
書込み方式 挿入はベースデータファイルに、更新
はREDOログに追記
常にAppendログに追記 実ファイルとDeltaログを同時に新規
作成
読込み方式 ベースファイルとREDOログを同時に
読込
ベースファイルとAppendログを同時
に読込（Realtime View）
Deltaログを元に必要な実ファイルを
読み込み
ファイル統合 コンパクションによる、REDOログ、
ベースデータファイルのマージ
コンパクションによりAppendログを
ベースファイルにマージ
Deltaログを定期的にチェックポイン
トに集約
データストア層 独自のデータストア層 HDFS or クラウドストレージを利用 HDFS or クラウドストレージを利用
常駐サービス あり なし なし
※Hudiについては主にリアルタイム性を重視したMerge-On-Readについて記載
リアルタイム分析に向けたアプローチの比較
各プロダクト、リアルタイム分析を実現するために様々なアプローチをとっている

47. © 2019 NTT DATA Corporation 47
ファイルと読み書きの仕組み
各プロダクト、独自のアプローチで書込みの高速化を図っている
デルタファイル
Writer1 Writer2
REDO
ベースデータファ
イル
Reader
WAL
MemRowSet DeltaMemStore
REDO
INSERTS UPDATES
(FLUSH)(FLUSH)
ディスクメモリ
Appendログ
Writer1 Writer2
Reader
(Read Optimized View)
xxx
yyy
ベースファイル
ver. 1
Reader
(Realtime View)
Deltaログ（バー
ジョン情報）
実データ
Writer1 Writer2
Reader
x1.parquet
y1.parquet
1.json
2.json
• メモリ層への書込みと定期的なディ
スクフラッシュで実現
• INSERTとUPDATEは分けて管理
• 書込みは行指向のAppendログへ
• コンパクションで列指向のベース
ファイルへマージ
• 2種のビューを使い分け
• 書込み時は実データとDeltaログ同時
に新規作成
• Deltaログを元に必要な実データを読
込み
Apache Kudu Apache Hudi Delta Lake
※Hudiについては主にリアルタイム性を重視
したMerge-On-Readについて記載

48. © 2019 NTT DATA Corporation 48
リアルタイム分析に向けたアプローチの比較
各プロダクト、リアルタイム分析を実現するために様々なアプローチをとっている
項目 Apache Kudu Apache Hudi※ Delta Lake
誕生 2015年 AFSに寄贈 2019年 Apache Incubator加入 2019年 OSSとして発表
主な開発元 Cloudera Uber Databricks
概要 OLAPとOLTPの両立によりリアルタ
イム分析を可能にするストレージ
用途に応じた3種類のビューを実現す
るストレージ
トランザクション管理とバージョン管
理を実現するストレージ
リ
ア
ル
タ
イ
ム
分
析
へ
の
ア
プ
ロ
ー
チ
フォーマット 独自のカラムナー 基本的にParquetとAvro Parquet
パーティション レンジパーティション、ハッシュパー
ティション
キーと値によるパーティション キーと値によるパーティション
主な実ファイル ベースファイルとREDOログ ベースファイルとAppendログ 実ファイルとDeltaログ
書込み方式 挿入はベースデータファイルに、更新
はREDOログに追記
常にAppendログに追記 実ファイルとDeltaログを同時に新規
作成
読込み方式 ベースファイルとREDOログを同時に
読込
ベースファイルとAppendログを同時
に読込（Realtime View）
Deltaログを元に必要な実ファイルを
読み込み
ファイル統合 コンパクションによる、REDOログ、
ベースデータファイルのマージ
コンパクションによりAppendログを
ベースファイルにマージ
Deltaログを定期的にチェックポイン
トに集約
データストア層 独自のデータストア層 HDFS or クラウドストレージを利用 HDFS or クラウドストレージを利用
常駐サービス あり なし なし
※Hudiについては主にリアルタイム性を重視したMerge-On-Readについて記載

49. © 2019 NTT DATA Corporation 49
トレードオフについての考察
近年登場したストレージソフトは、各トレードオフのバランスをとる方向で
様々なアプローチをとっている
CSV/SequenceFile/Avroなど
HDD指向
メモリ指向
高スループット
(バッチ処理)
低レイテンシ
(オンライン処理)
書き込み最適
読み込み最適
準リアルタイム処理
アドホック分析
分析最適化のため、カラムナーフォーマットを提供。さらに、
- Kuduはハッシュ、レンジパーティションを提供
- Hudiは用途ごとのビューを提供
- Delta Lakeは再現を可能にするバージョン管理機能を提供
Kuduはメモリ層と定期的なディスクへのフラッシュで実現
Hudiは書込みを行指向のフォーマットで実現
Delta Lakeはバージョンごとの新規ファイル作成で実現
いったん低レイテンシで書き込む仕組みを提供
- Kuduはメモリ層と定期的なディスクへのフラッシュで実現
- Hudiは書込みを行指向のフォーマットで実現
- Delta Lakeはバージョンごとの新規ファイル作成で実現
SSDも考慮した
アーキテクチャ
コンパクションなどの
バックグラウンドでの
ファイル統合
コンパクションなどの
バックグラウンドでの
ファイル統合
分析最適化のため、カラムナーフォーマットをベースにしつつ、
- Kuduはレンジとハッシュパーティションを提供
- Hudiは用途ごとのビューを提供
- Delta Lakeは再現を可能にするバージョン管理機能を提供

50. © 2019 NTT DATA Corporation 50
モダンなプロダクト選定の注意事項
本当にそのプロダクトを使うべきか、よく考えよう
モダンなプロダクトよりも、従来のプロダクトが最適な場合もある
• 扱うデータ量次第では、RDB（Postgresなど）で対応可能
• リアルタイム分析可能なプロダクトは、構造化データで格納することを前提としている。非構造化
データを格納する場合はHDFSやオブジェクトストレージの利用を推奨
モダンなプロダクトでは従来のプロダクトでできていた機能をまだ実現していない場合がある
• その場合、他プロダクトとの組合せで対応可能なことが多い
• ただし、複雑なアーキテクチャや運用にならないよう、常にシンプルさとのトレードオフを意識するこ
とが大事

51. © 2019 NTT DATA Corporation 51
まとめ
リアルタイムなデータへの分析を行うことで、データ活用の幅は広がっている
近年登場したプロダクトは、様々なアプローチで大量データのリアルタイム分析を実現
しており、他プロダクトの考え方や機能そのものを取込み、トレードオフのバランスをと
る方向で進化している
故に、プロダクトの内部構造は複雑になり、選定、効率的に使いこなすことは困難に
なってきている
我々は、過去Hadoop/Spark/Kafkaなどの大量データ処理に多く携わってきた知見や、
幅広くOSSを扱ってきた強みがある
この技術領域で困っていたら、ご相談ください

52. © 2019 NTT DATA Corporation本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。