[レポート]  データレイクエンジニアリングにおける “醜い配管” を排除する – Subsurface LIVE Summer 2021

[レポート] データレイクエンジニアリングにおける “醜い配管” を排除する – Subsurface LIVE Summer 2021

Clock Icon2021.08.15 14:42

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

米国時間2021年07月21日〜22日の計2日間、オンラインで開催された「Subsurface LIVE Summer 2021」では、主催となるDremio社のサービスやクラウドデータレイクに関する各種サービスやプロダクトのセッションが展開されていました。

当エントリでは、その中から「Eliminating the Ugly Plumbing of Data Lake Engineering」(データレイクエンジニアリングにおける "醜い配管" を排除する)というセッションについてレポートします。

目次

 

セッション概要

セッション概要は以下の通り。

<セッションタイトル>
Eliminating the Ugly Plumbing of Data Lake Engineering
(データレイクエンジニアリングにおける "醜い配管" を排除する)

<登壇者>
Ori Rafael - CEO @ Upsolver
Yoni Eini - Co-founder and CT

<発表内容>
Dive into four areas of data lake engineering and hear about the technical details of how Upsolver eliminated its ugly plumbing.

For decades Oracle dominated the database landscape. It was an expensive monolith, but it did make things easy and familiar for the database user, since it provided a standard SQL interface and handled burdensome technical functions under the covers.

Data lakes upended the monolithic database, separating ingestion, storage and processing into independently scalable components. While this has provided tremendous flexibility and affordable infrastructure at scale, it has required scarce and expensive big data engineering talent to glue products together into solutions, via hand-coding and hundreds of configurations using distributed systems like Hadoop and Spark.

The challenge at hand is this: How do you make the data lake as easy to use as the traditional Oracle database, so that citizen data practitioners and not just big data engineers can take advantage of the wealth of data it holds.

In this talk, Ori Rafael, a long-time Oracle veteran while working in Israeli intelligence, and now CEO of Upsolver, will dive into each of the following areas of data lake engineering complexity and discuss the novel approaches Upsolver took to eliminate the ugly plumbing and democratize the data lake:
・Automated file systems management – addressing the small files problem, serialization, file formats and compression
・Joins, updates and deletes – enacting standard database operations on an immutable object store
・Orchestration – determining the best path to a desired table without burdening the user with data pipelines overhead
・Consistency – providing strongly consistent datasets on top of an eventually consistent object store

(データレイクエンジニアリングの4つの分野に分けて、Upsolverがどのようにして醜い配管を排除したか、技術的な詳細をご紹介します。

何十年もの間、Oracleはデータベースの世界を支配してきました。Oracleは高価なモノリス型データベースでしたが、標準的なSQLインターフェースを提供し、煩わしい技術的機能をカバーしていたため、データベースユーザーにとっては簡単で親しみやすいものでした。

データレイクはモノリシックなデータベースを覆し、取り込み、保存、処理を独立したスケーラブルなコンポーネントに分離しました。これにより、非常に高い柔軟性と手頃な価格のインフラが実現しましたが、その一方で、希少で高価なビッグデータエンジニアリングの人材が、ハンドコーディングやHadoopやSparkなどの分散システムを使った何百もの設定によって、製品をソリューションにまとめ上げる必要がありました。

現在の課題は次の通りです。ビッグデータエンジニアだけでなく、市民のデータ実務者がデータレイクが持つ豊富なデータを活用できるように、データレイクを従来のOracleデータベースのように使いやすくするにはどうすればよいか。

本講演では、イスラエルの諜報機関に勤務していた時にオラクルに長く在籍し、現在はUpsolver社のCEOを務めるOri Rafael氏が、データレイクエンジニアリングの複雑さを示す以下の各分野に踏み込み、醜い配管を排除してデータレイクを民主化するためにUpsolver社がとった斬新なアプローチについて説明します。
・自動化されたファイルシステムの管理 - スモールファイル問題、シリアライゼーション、ファイルフォーマット、圧縮への対応
・結合、更新、削除 - 不変のオブジェクトストア上での標準的なデータベース操作の実行
・オーケストレーション - データパイプラインのオーバーヘッドをユーザに負担させることなく、目的のテーブルへの最適なパスを決定
・一貫性 - 最終的に一貫性のあるオブジェクトストアの上に、強く一貫性のあるデータセットを提供)

 

セッションレポート

ここからはセッションレポートとなります。それぞれのトピックに関して要点をまとめる形で紹介。

Upsolver概要

  • データレイクのためのビジュアルアナリティクスエンジニアリングプラットフォーム
  • オブジェクト・ストレージ上でのデータ・エンジニアリングを可能にするための社内スタートアップ・プロジェクトからインスピレーションを得た
  • AWSによって繰り返し検証、推奨されている
  • トランザクション:テラバイト〜ペタバイト級の規模本番ワークロードが多数
  • データレイクで自動化されていない/データエンジニアがカスタムメイドで構築する必要があるような以下の機能に対応
    • ファイルシステム管理
    • 強力な一貫性
    • 宣言型データ標準言語(SQL)
    • UPSERT

このセッションでは、課題となるポイントに対してUpsolverが対応していった4つの「課題」について説明されていきました。

課題その1:ファイルシステム管理の自動化

  • 目的:生のファイルではなく、論理テーブルをエンドユーザに公開する
  • 課題:ファイルシステムを抽象化したデータベースとは異なり、データレイクではクエリのパフォーマンスを上げるためにファイルシステムのエンジニアリングが必要
    • 小さなファイルのコンパクト化(ストリーミング、遅延イベント、アップデートが必要なため)
    • 遅延イベントに対応したテーブルパーティショニングの実装
    • 適切なファイルフォーマットと圧縮方法の選択
    • ディレクトリの構造化
  • 解決策:レコードロックのない"コンパクション"
    1. 処理時間、ファイル数、平均ファイル・サイズに基づいて、コンパクションが可能なパーティションを検出
    2. 新しいパーティションを作成し、古いパーティションを圧縮しながら新しいデータを両方のパーティションに並行して送信することで、古いパーティションと同期させる
    3. メタデータ・ストアのパーティションを自動的に切り替える
    4. クエリの実行が終了したら、古いパーティションを削除

課題その2:正確に一致することを保証

  • 目的:データ処理における損失や重複がないこと
  • 課題:強固な一貫性を持つデータベースとは異なり、データレイクは最終的に一貫性のあるオブジェクトストレージに依存しているため、強固な一貫性を実現するためにはエンジニアリングが必要となる
  • 解決策:強く定義された時間ベースのディレクトリ
    • 1つの処理タスク=1つのファイル=1つの時間帯
      • 一定期間、ファイルが存在しない場合、タスクが作成される
    • 冪等性:各処理は決定論的であるため、特定のサーバに縛られることなく、いつでも同じ結果で実行できる
    • 各出力ファイル内の適切な順序を確保するために、タスクごとに1つのスレッドを使用する
  • 例) どのサーバで実行しても、どの時間に実行しても、同じ結果が得られる1つのタスク
    • 時間ベースのディレクトリにある入力ファイル →→→ [無駄のない操作] →→→ 同じディレクトリ構造の出力ファイル

課題その3:低レベルのコード化されたトランスフォーム

  • 目的:パイプラインエンジニアリングのオーバーヘッドをなくす
  • 課題:実行計画を自動的に作成するデータベースとは異なり、データレイクでは中間データ構造を含めた実行計画をユーザが構築する必要がある
  • 解決策:宣言型言語+非結合型インデックス
    • 実行計画が自動生成される宣言型言語
    • データベースでは、結合や集約などの中間構造にインデックスを使用しています。Upsolverも同様に、オブジェクトストレージ上のインデックスを使用

課題その4:「データの追記」以外のユースケースに対応

  • 目的:update や delete などの操作でデータベースの機能と一致させる
  • 課題:データベースとは異なり、データレイクでは時系列のパーティショニングに依存しておりキーによるランダムアクセスが出来ない(パーティショニングは"貧乏人のインデックス")
    • IcebergやDelta Lakeのようなデータレイクのテーブルソリューションは、コミッターが1人に限られており(コンパクション中の更新はどうなるのか)、Vanilla Parquetのようにすべてのクエリエンジンと互換性があるわけではない
  • 解決策 バニラParquetファイルへのUPSERTに対応
    • Hiveビューでは、完全にコミットされたパーティションと書き込み先行のログ(追加パーティション)を結合することで、一貫したデータを提供
    • 継続的にコンパクションを行うことで、先読みログを小さくすることができる

セッションまとめ

  • データベースは、生のファイルを操作するための醜い仕組みを自動化した
  • データレイクは、ビッグデータを処理するためのオープンソースコンポーネントのエコロジーとして発展し、カスタムメイドのデータエンジニアリングの必要性を生み出した
  • Upsolverはデータベースを復活させましたが、クラウドデータレイク上でオープンフォーマットになっている
  • その結果、使いやすさ(SQL)、パワーアットスケール(自動最適化)、手頃な価格での運用(データレイクの経済性)を実現した

 

まとめ

という訳で、クラウドデータレイクイベント『Subsurface LIVE Summer 2021』のセッション「Eliminating the Ugly Plumbing of Data Lake Engineering」(データレイクエンジニアリングにおける "醜い配管" を排除する)のレポートでした。

データレイクの諸問題に対して解決策を提示しているUpsolverというサービスの紹介的な内容でしたが、データ分析環境に関する諸々を取り扱う我々としても参考になる部分があるなぁと感じました。色々参考にさせて頂こうと思います。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.