Taste of Tech Topics

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた

最近ソーダストリームを買い、炭酸水を飲むのにはまってます。機械学習エンジニアの@yktm31です。

以前に「AWS Lake Formationでデータレイク体験!」という記事を書いてみて、データ基盤アーキテクチャに興味が湧いてきました。

データレイクハウスは、「データウェアハウス」と「データレイク」を統合したようなアーキテクチャで、 2020年にDatabricks社により提唱され、新しいデータ基盤アーキテクチャとして注目されているようです。

www.databricks.com

そこで今回、「データレイクハウス」について調べてみたことをまとめてみたいと思います。

なぜデータレイクハウスが注目されているのか?

データ基盤アーキテクチャは、以下のような変遷をたどっていて、データレイクハウスが最新のアーキテクチャという流れのようです。 それぞれの登場時期、利用用途を以下にまとめて見ました。

アーキテクチャ 登場時期 利用用途
データウェアハウス 1980年代 ビジネス意思決定のためのデータ分析 (BI)
データレイク 2000年代 非構造化データを使う機械学習 (ML)
データレイクハウス 2020年 BIとMLの両立

最新のデータ基盤アーキテクチャであるデータレイクハウスの必要性を理解するために、 まず、データウェアハウスとデータレイクそれぞれの特徴・課題を見ていきたいと思います。

データウェアハウスの特徴・課題

データウェアハウスのアーキテクチャ

データウェアハウスは、ビジネス意思決定のためにデータを一つの場所に集約・保管し、分析に利用するためのデータ基盤アーキテクチャで、1980年代に考案されたそうです。 (私が生まれたのは1997年なので、生まれる前からこうしたデータ基盤アーキテクチャが考えられていたのは驚きでした。) 例えば、「Amazon Redshift」はデータウェアハウスを提供しているサービスとして有名だと思います。

データウェアハウスの特徴として、以下のような点が挙げられていることが多かったです。

  • 複数のソースから取得したデータにETL処理を施し、構造化データを蓄積する。
  • スキーマが決まっていて、トランザクションもサポートされることでデータ一貫性が担保されている。
  • 権限管理が行え、データへのアクセスコントロールが効く。

しかし反面、ビジネスで扱うデータの多様化により、データウェアハウスだけでは新たなニーズに応えられなくなっていったそうです。 とくに、非構造化データを使う機械学習の発展に、データウェアハウスのスキーマが決まっているという点が大きな制約となったようです。

データレイクの特徴・課題

データレイク + データウェアハウスのアーキテクチャ

画像やテキストなど非構造化データの分析という新たなニーズに合わせ、データレイクというデータ基盤アーキテクチャが2000年代に入り誕生したそうです。

例えば、「Amazon S3」や「Azure Data Lake Storage」といったクラウドストレージシステムと周辺サービスを組わせるとデータレイクとなります。

データレイクの特徴として、以下のような点がよく挙げられています。

  • 未加工のデータが格納され、主にデータ分析や機械学習で利用されることが多い。
  • データの形式に制限がなく、テキストデータやセンサーデータ、画像、テキストなど、構造化データ以外のデータも格納できる。

他方、以下の2点がリスク・課題としてもよく挙がります。

  • データレイクはトランザクションはサポートされないためデータ品質が保証されない。
  • 自由にデータが配置できる反面、本当に必要なデータが見つかりづらくなる、データスワンプとなるリスクがある。

トランザクションがサポートされないというデータレイクの欠点を補う必要がある場合は、データレイクとデータウェアハウスを併用するようです。

データレイクのデータを直接扱うだけでなく、ETL処理を施しデータウェアハウスにデータを登録することで、トランザクションを実現する試みです。 しかしその方式では、データ一貫性を保つのが難しいなど、デメリットも残っている現状のようです。

ここまでで、データウェアハウス、データレイクの比較をまとめてみました。

特徴 データウェアハウス データレイク
扱えるデータ形式 構造化データのみ、加工・整形済みデータ 構造化データ、半構造化データ、非構造化データ、生データ
代表的な利用用途 BI (過去データの分析) ML (将来予測)
データ一貫性 ×
データの自由度 ×
コスト データ保持・構築ともにコストがかかる データサイズに対して比較的安価
主な利用者 ビジネスアナリスト データサイエンティスト

データレイクハウスの特徴

データレイクハウスが登場したのは、データウェアハウス・データレイクそれぞれの特徴を活かしつつ、 課題をうまく解決するためでした。

まず、データレイクハウスはどのような特徴を持ち、既存の課題をどう解決したのかをまとめてみたいと思います。

  • ACID トランザクションサポート
  • データレイクの問題点として、トランザクションサポートが無いことで、データ一貫性が保てないことがありました。 その原因の一つとして、トランザクションがサポートされていないという点がありました。 データレイクハウスでは、データレイクをメタデータを扱うレイヤーを重ねることで、 データレイク内のデータを直接扱うのではなく、メタデータを操作する事で扱っていきます。 この機構により、ACIDトランザクションを実現し、データ一貫性の欠如という課題を克服できたようです。
  • データのアクセス権限管理
  • データウェアハウスでは実現でき、データレイクでは実現できなかった、データのアクセス制御を行えます。 テーブル単位のみならず、列/行単位でのきめ細やかな権限管理をサポートします。
  • parquetなどのオープンなファイルフォーマットを利用
  • Apache Parquet, Delta Lake, Apache Hudiなどのオープンソースのデータフォーマットを利用することで、データアクセスの方法を標準化できるというメリットがあるようです。
  • 安価なストレージ
  • データレイクのメリットとして、様々なデータ形式を、安価なストレージで扱えるという点がありました。 データレイクハウスでは、データレイクのこの良い面を受け継いでいます。
  • BI・データ分析・機械学習をサポート
  • データレイクハウスでは、BIはデータウェアハウス、機械学習はデータレイク、という区別なくデータを扱うことができるようになります。

    データレイクハウスのアーキテクチャ

    ここからは、データレイクハウスのアーキテクチャについて具体的に見ていきます。 データレイクハウスのアーキテクチャは、概ね以下のようなレイヤー構造からなっているようです。

  • Data Ingestion Layer
  • Storage Layerにデータを取り込む役割を担う。
  • Storage Layer
  • 高い耐久性とスケーラビリティを持ち、コストの安いデータ保管を担う。構造化/非構造化データを格納する。 データの加工度に応じて、データ格納のレイヤーを分ける、メダリオンアーキテクチャ(※1)を採用するケースが多い。
  • Metadata Layer
  • Storage Layerに存在するデータのメタデータを扱う役割を担う。 データカタログを作成したり、トランザクション・権限管理を実現する。Catalog Layerと表現されることもある。
  • Processing Layer
  • データ分析や機械学習などで利用可能な形にするための、データの検証・変換を担う。
  • Data Consumption Layer
  • SQLやBI、機械学習など、データを利用する層。Serve Layerと表現されることもある。

    データレイクハウスアーキテクチャ

    ※1 メダリオンアーキテクチャ

    メダリオンアーキテクチャとは、データレイクのデータ配置を、データの質によって3つのレイヤーに分けるアーキテクチャということらしいです。 3つのレイヤーはそれぞれ、Bronze、Silver、Goldとなっています。

  • Bronze Layer
  • あらゆるデータソースからデータを取り込み、未加工の生データを配置。
  • Silver Layer
  • Bronze Layerのデータから、ジョイン、フィルターなどの処理を施し、マスターテーブルなどのクレンジングされた中間データを配置。
  • Gold Layer
  • レポート作成などに必要なレベルで集約されたデータを配置。プロジェクトのユースケースごとに専用のデータベースとなり、データマートとも呼ばれる。

    メダリオンアーキテクチャ

    Azure

    Azureでドキュメントで提示されているデータレイクハウスアーキテクチャを見ていきます。

    https://learn.microsoft.com/ja-jp/azure/architecture/example-scenario/data/synapse-exploratory-data-analytics

    Azureのこのレファレンスアーキテクチャのポイントを3つ挙げてみました。

    • Azure Synapse Analyticsを中心としたアーキテクチャ
    • Azure Synapse サーバーレス SQL プールとPowerBIによるデータ可視化
    • Azure Machine Learningを利用した機械学習利用

    Azure Synapse Analyticsを中心としたアーキテクチャ

    Azure Synapse Analyticsとは、データウェアハウス・ビッグデータ解析を統合したデータ分析プラットフォームです。 Azure Synapse Analyticsを利用することで、SQL / Apache Sparkによるデータ分析が用意に実現できるようになります。

    Azure Synapse サーバーレス SQL プールとPowerBIによるデータ可視化

    Azure Synapse サーバーレス SQL プールを利用し、Azure Data Lake Storageに保存されたParquetファイルに対し、 SQLベースでデータ探索を行い、Power BIに結果を可視化します。

    Power BIとSynapseを連携する際、Power BI Linked Serviceで直接連携することも可能ですが、 その方式では、ワークスペースが1つのみに制限されてしまいます。 そのため、サーバーレス SQL プールを利用することが一つのポイントになります。

    Azure Machine Learningを利用した機械学習利用

    Azure Machine Learningを利用し、推論した結果をデータレイクに保存し、PowerBIで可視化することが出来ます。 学習するデータの取得、整形のためにはAzure Synapse サーバーレス Apache Spark プールが利用できます。 Azure Machine Learningによる推論結果は、データレイク中のゴールドレイヤーに保存されることになります。

    参考

    learn.microsoft.com

    Azure Databricksを利用した代替案

    ここまで、Azure Synapse Analyticsを利用したデータレイクハウスアーキテクチャを見てきましたが、 代替アーキテクチャとして、Azure Databricksを利用する方法もあるようです。

    Azure Databricksは、SQL / ML / データ分析をするためのプラットフォームです。 Azure Databricksを利用したデータレイクハウスのアーキテクチャは以下のドキュメントが参考になりそうでした。 learn.microsoft.com

    AWS

    次に、AWSにおけるデータレイクハウスのアーキテクチャを見ていきます。ここでは、AWS Big Data Blogで提示されているアーキテクチャを参考にしていきます。

    https://aws.amazon.com/jp/blogs/big-data/build-a-lake-house-architecture-on-aws/

    AWSのこのレファレンスアーキテクチャのポイントをまとめると、以下のような点が分かりました。

    • メタデータレイヤーとして、AWS Lake Formationを利用
    • Amazon S3Amazon Redshiftのネイティブな連携
    • Amazon Athena / Amazon QuickSight / Amazon SageMakerなどのサービスから、統一されたインターフェースでデータ利用できる

    メタデータレイヤーとして、AWS Lake Formationを利用

    AWS Lake Formationは、データの行/列レベルの権限管理や、ACIDトランザクションを提供しています。 Amazon S3Amazon Redshiftに格納されているデータ本体と、メタデータをレイヤーとして分離することで、スキーマオンリードを実現します。

    データレイク単体では、データのスキーマが変更されても、変更を検知することは難しいです。 そのため、読み込むデータがどのようなスキーマか確認することが必要になり、このスキーマオンリードの考え方が重要になってくるようです。

    また、データレイクは、データのスキーマが変わることが考えられますが、 AWS Glueを通じて、中央データカタログは更新されていくので、変更に追従できるということのようです。

    Amazon S3Amazon Redshiftのネイティブな連携

    データをBIで利用する場合、整理された構造化データが分析パフォーマンスの上で重要になります。他方、機械学習では非構造化データを扱うことになります。

    例えば、大量の履歴データがデータレイク(Amazon S3)に保管され、BIでの分析対象分のデータは、データウェアハウス(Amazon Redshift)にAmazon Redshift Spectrumを通じて展開、 そして、逆にデータウェアハウス(Amazon Redshift)で不要になったデータは、データレイク(S3)にオフロードするという使い方ができるらしいです。 データウェアハウス(Amazon Redshift)からデータレイク(Amazon S3)にオフロードされたデータも同じクエリでアクセスすることができるようです。

    Amazon Athena / Amazon QuickSight / Amazon SageMakerなどのサービスから、統一されたインターフェースでデータ利用できる

    以下のようなサービスから、データレイクハウスのデータを扱うことができます。

    サービス 用途
    Amazon Athena SQL
    Amazon QuickSight BI
    Amazon SageMaker ML
    Amazon Redshift Spectrum データ分析

    まとめ

    機械学習ビッグデータ系のプロジェクトをやっているとき、データをどうやって管理する?という課題がよく出てくる実感があります。 今回見てきたデータレイクハウスは、ぜひデータ管理アーキテクチャの設計に活かしていきたいと感じました。

    ただ、データレイクハウスは、自前で0から構築するとなると、かなり大変そうな印象を受けました。 なので、クラウドサービスで簡単に構築できそうなところは、有難いなと思いました。

    Acroquest Technologyでは、キャリア採用を行っています。
    • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
    • Elasticsearch等を使ったデータ収集/分析/可視化
    • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
    • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長
      少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。 www.wantedly.com