大規模データ活用向けストレージレイヤソフトのこれまでとこれから（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05）
- 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本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。