分析指向データレイク実現の次の一手 ～Delta Lake、なにそれおいしいの？～（NTTデータ テクノロジーカンファレンス 2020 発表資料）

Editor's Notes

• #5: そもそもDelta Lakeとは何か、そして基本的な使い方はどのようなものか、とった概要をお話します。 その後、Delta Lakeの今の実力値について、マイクロベンチを取った結果のご紹介を通じてお話します。 実際の動かしたときの特徴を一部紹介・。
• #7: Delta Lake とは、についてお話する前に、似たような名前を持つ「データレイク」について少し触れたいと思います。 そもそもデータレイクとは、大量のデータを扱うデータの貯蔵庫のような概念であって、厳密な定義は存在しません。少なくとも、ある特定のプロダクトやソリューションのことではありません。データレイクとは、の解釈には様々な議論があると思いますので、この講演では「データを永続的に扱う分散ストレージ」と読み替えさせて頂きます。 ・・・とした時に、データを永続的に扱う分散ストレージが抱える課題感とはいったい何でしょうか。データ活用基盤はこういうアーキテクチャになることが多いと思うのですが、ここで、トレージを軸としたデータの入りと出に着目しますと、例えばこのような課題があると考えられます。そしてこの講演では、データの出の部分、「データの活用のしやすさ」について注目いたします。 この部分の課題として、データ分析や機械学習をやろうとした時に素の分散ストレージをそのまま使おうとすると、機能がシンプル過ぎて、周辺系機能の作り込みが発生しがちで処理全体が煩雑になってしまう、という点が挙げられます。その背景には、近年では要件の複雑化により、次のような特徴が求められているためです。【Next】
• #8: 例えば、データの操作や処理について。テーブルデータ等の構造データのみならず、自然言語で書かれた文書ファイルや、動画像ファイル等、非構造データを取り扱うシーンが増えてきています。 また、データ操作そのものではなく、その周辺系・補助という点についてはどうでしょうか。例えば、機械学習ではモデル開発の際にあらゆるデータを活用して試行錯誤しながらその時々でのベストなモデルをアウトプットしますけれども、いつ、どんなデータの、どのバージョンを使ってどのモデルを作ったのか。そういったデータやモデルの再現性の担保が求められることがあるでしょう。他には非機能面でも、大量データを扱う上で前提となるスケーラビリティですとか、可用性といったこともポイントになるでしょう。 このように、分散ストレージに向けられる期待値は多岐に渡り、ストレージ単体でこれらに応えるのは難しくなってきています。従って、分散ストレージの高度化が求められています。【Next】
• #9: そして、分散ストレージの高度化をどうやるか、についてですが、大まかにはこちらの３種類のアプローチがあるかと思います。 １つ目は、ストレージにデータを投入する側で工夫する ２つ目は、ストレージを上手く使う技術を入れて工夫する ３つ目は、ストレージそのものに手をいれて工夫する 以上３点が挙げられると思いますが、【Next】
• #10: 今回は真ん中にフォーカスを当てたアプローチ、具体的には、ストレージレイヤ・ソフトウェアを活用する方法について紹介します。【Next】
• #11: ストレージレイヤソフトウェアは、ストレージを上手く使う技術、とお話しましたが、どのような使われ方になるでしょうか。イメージ図を用いて簡単にご紹介いたします。 こちらのイメージ図の下部あるストレージ。HDFS等の分散ファイルシステムやOpenStack Swift等のオブジェクトストレージ等がありますけども、一般的にはデータの読み書き、削除などの素朴な機能のみをAPIとして提供しています。ここにストレージレイヤソフトウェアをかますことで、論理的なデータセットやテーブルの操作が可能になります。例えば、HDFS等はWrite at Once, 一度書いたらデータの更新は行えませんが、ストレージレイヤソフトウェアが提供する論理的なデータセットやテーブルを操作することで、あたかもデータの更新を行えたような結果を得られます。 このように、データ操作のためのアプリケーションに便利な特徴を提供するのが、このストレージレイヤソフトウェアであり、その１実装例がDelta Lakeです。
• #12: メタデータファイルを使って、『データの実体を保持する物理的なファイル』と『論理的なテーブル』を紐づけるような仕組みになっています。つまりメタデータを見れば、目的とする論理的なテーブル内のデータを読み取るために、どの物理ファイルを読めばよいかが分かるようになっています。この仕組みを利用することで、論理的なテーブルを更新するような処理も簡潔に実現できます。
• #13: さて、Delta Lake の基本的な使い方として、Delta Lake が提供する論理的なテーブルを操作するイメージについてご紹介しましたが、今後はもう少しマクロな視点、データ活用基盤のアーキテクチャの中でどのように使われるかについて見ていきます。 Delta Lake の最も基本的でシンプルな使い方は、ストレージと組み合わせてデータの読み書きを行うことです。 しかしそれではなんとも味気ない、ということで、Delta Lakeが提供するいくつかのライブラリおよびインターフェイスを活用して、データ処理パイプラインの一部に組み込んで活用することが出来ます。たとえば、SparkからDelta Lakeに対してデータ操作を行うことが可能です。
• #14: そして、Delta Lakeのうまみ、つまり強みとなるポイントですが、一言で申し上げますと「楽観ロックに基づく排他制御の仕組みを提供する」というポイントになります。つまり、アプリケーションから見れば、分散ストレージにトランザクションのような便利な機能が入った、ということになります。これまで、大量のデータを扱う分散ストレージが不得手としてた部分が補われたことになります。すごくざっくり言い換えますと、信頼性高い読み書きができるようになった、ということです。 したがって、ストレージをそのまま使うケースと比べて、何らかの処理が挟まる（挟まるから、機能が提供されるんだけど）ので、それを踏まえてどのくらい性能影響があるのか気になりますよね？ということで、読み書きの仕方やパターンに基づいて色々動作検証していますが、その一部を紹介します。今回は、まさにこの絵の中に掛かれている「更新」と「スキャン」についてのベンチマーク実行例についてご紹介したいと思います。 --- トランザクションのような便利な機能が入った　->　それまでのストレージ単体になかった機能が入ってきた　->　性能どんなもんじゃい？ 一部ご紹介。 普通データレイクにおいては、普遍のデータとして扱う・ Delta Lakeを介することで、論理的なテーブルの更新を実現できる.
• #15: さて、ベンチマーク実行例をご紹介する前に、講演の冒頭で質問させて頂いた結果についてご紹介します。
• #17: ■必ず言う あくまで特定データを使った基本特性を知るためのベンチマークなので実際のワークロードでどのくらい出るのか？は個別に検証必要 ・・・ということで、マイクロベンチマークについての実施概要についてお話します。 今回のベンチで使ったソフトウェア群としてはこちらの表に記載しているものでして、Delta Lakeは0.7.0を、これに対応するApache Sparkのバージョンとして3.0.0を利用しています。また、マイクロベンチマークといえば、使ったデータとしては、装置が気になるところですが、こちらには、TPC-DSをSpark対応させたOSSのspark-tpcds-datagenというものを使っております。 負荷がけ方法としては独自に・・・ さて、先程申し上げました通り、Delta Lakeにはデータの読み書きに関するいくつかのAPIが備わっておりますが、本日ご紹介するマイクロベンチマーク結果は、ReadとUpsertに関するものです。次のスライドより、早速ご紹介したいと思います。
• #18: ■必ず言う あくまで特定データを使った基本特性を知るためのベンチマークなので実際のワークロードでどのくらい出るのか？は個別に検証必要 ・・・ということで、マイクロベンチマークについての実施概要についてお話します。 今回のベンチで使ったソフトウェア群としてはこちらの表に記載しているものでして、Delta Lakeは0.7.0を、これに対応するApache Sparkのバージョンとして3.0.0を利用しています。また、マイクロベンチマークといえば、使ったデータとしては、装置が気になるところですが、こちらには、TPC-DSをSpark対応させたOSSのspark-tpcds-datagenというものを使っております。 負荷がけ方法としては独自に・・・ さて、先程申し上げました通り、Delta Lakeにはデータの読み書きに関するいくつかのAPIが備わっておりますが、本日ご紹介するマイクロベンチマーク結果は、ReadとUpsertに関するものです。次のスライドより、早速ご紹介したいと思います。
• #19: まずはReadについてです。 Readは、予めHDFS上に配置されたデータを、Delta Lake越しにリードするか、HDFSから直接リードするかを相対比較することで、Delta Lakeの実力値を見て行こう、というものです。 さて、いきなりグラフが出ていますけれども、こちらが結果になります。黄色の線がHDFS直読み、青がDelta Lake越しのリードです。 やはり、HDFS直読みの方が速い、という結果が表れておりますが、
• #20: まずはReadについてです。 Readは、予めHDFS上に配置されたデータを、Delta Lake越しにリードするか、HDFSから直接リードするかを相対比較することで、Delta Lakeの実力値を見て行こう、というものです。 さて、いきなりグラフが出ていますけれども、こちらが結果になります。黄色の線がHDFS直読み、青がDelta Lake越しのリードです。 やはり、HDFS直読みの方が速い、という結果が表れておりますが、 Readではdelta logファイルやそのチェックポイントファイルから読み込み対象のファイルを得る
• #21: まずはReadについてです。 Readは、予めHDFS上に配置されたデータを、Delta Lake越しにリードするか、HDFSから直接リードするかを相対比較することで、Delta Lakeの実力値を見て行こう、というものです。 さて、いきなりグラフが出ていますけれども、こちらが結果になります。黄色の線がHDFS直読み、青がDelta Lake越しのリードです。 やはり、HDFS直読みの方が速い、という結果が表れておりますが、
• #22: 続きまして、Upsertについてです。
• #23: 続きまして、Upsertについてです。
• #26: --- Insert50%Update50%、およびUpdate100%のときのデータ出力サイズもほぼ変わらないため、Update50%の時点で全ファイルに更新が入るようなデータであったと推察される。 更新データは`spark.read.format("parquet").load("TPCDSのデータ").limit(件数)`で抽出していた scale-factorが2000以下の場合、ファイル数は69。（Partition無しのケース） PartitionKeyありの場合、更新対象のレコードがないファイルは更新処理実施にスルーされる。（データサイズ変化ない） Parquet ・・・すべて書き直し Delta ・・・・更新対象のファイルだけを書き直しできる
• #27: したがって、大きなデータをバッチ処理的に扱う際には、テーブルや更新データの状態によって処理時間が変わってくるケースがあります。そのため、これらの状態を予想しきれない場合は、最悪値、つまり全てのデータが更新される実行時間で見積もっておくのが安全です。【Next】
• #28: 続きまして、Upsertについてです。
• #30: 各々のデータサイズにおいて「どれくらい」速くなるのかについては更なる調査が必要。（どなたかご存知の方がいたら教えて）
• #32: ストリーム処理併用などのユースケースで細かなデータをUpsertする場合は、最適化オプション付けないほうがいいケースもあるよ。データ流量から計算してね。
• #33: 1: Delta Lake では設定に応じて、こういう仕組みで動く。 2: Sparkは、扱うデータサイズによって内部で挙動が変わるしくみになっている。 → この２つが合わさると、Delta Lake(&Spark)の設定と、Delta Lakeに与えるデータ量によって、動き方が場合分けされる。場合分けされた個々を見ると、ものによっては設定(パラメータ名)から直感的に感じる効果と、逆転がするケースがあるので、そこは注意。 本来ここはDelta Lakeのマイクロベンチマークですので、Sparkの話が入ってくるのは違和感があるかもしれません。 実はDelta Lakeは内部でSparkのAPIを多分に利用しておりまして、密結合な状態です。これをどう捉えるかは多分に議論の余地があると思いますけども、Delta Lakeのオプションを変えるとSparkの最適化技法選択にも影響を与えるので、Delta Lakeの設定を変更する際には注意が必要です。今回はUpsertの最適化オプションを一つの題材としてご紹介しましたけども、Delta Lakeを使いこなす上では、どうやらSparkの理解も求められそうだ、と言って差し支えないでしょう。