データ管理技術の違いを理解する ~データベース/データウェアハウス/データレイク/データマート/レイクハウス~

データ管理技術であるデータベース/データウェアハウス/データレイク/データマート/レイクハウスといった技術について整理します。
目次
データ管理技術の違いを理解する
近年、AI/機械学習といった技術領域の急激な発展によりデータ管理技術も発展し、重要になってきています。
データ活用の業務に関わっていると、データベース、データウェアハウス、データレイク、データマート、レイクハウスなどの似た用語が出てきます。これらの技術はそれぞれの特徴をしっかり理解して扱う必要があります。
企業で仕事をしていると、各企業のレベルにもよるかと思いますが、人により各用語に関する解釈が異なる場合があります。また、誤った技術を採用してしまうと後々で応答性などの色々な面で困る可能性もあります。
この記事では、これらのデータベース管理技術(データベース/データウェアハウス/データレイク/データマート/レイクハウス)の特徴や違いについて整理します。
また、近年注目のレイクハウスを提供するサービスである Databricks や Microsoft Fabric についても簡単に紹介します。
データベース(Database)
データベース(Database)は、構造化されたデータを効率的に保存、取得、管理することができるシステムです。データベースには、リレーショナルデータベース(RDB)とノンリレーショナルデータベース(NoSQL など)がありますが、主に広く使われている RDB を中心に説明します。
データベースの大きな特徴として、トランザクション処理によりデータの整合性を保持できるという点があります。銀行取引、販売、予約システム等の OLTP(Online Tranzaction Processing)という日々のトランザクションを処理する領域には非常に適します。業務システムの構築でデータベースを選択するのはよい選択です。
一方で、RDB は大規模なデータに対するスケーラビリティには制限があります。例えば、Oracle、SQL Serverといった代表的な RDB の管理システム(RDBMS: Relational DataBase Management System)は、1 つのサーバーで動作させることが多く、大規模なデータに対してサーバーを分散させて高速化することは一般的には不得意です。ただし、近年では分散データベースシステムという技術領域でスケーラビリティを解決しているものもある点は補足しておきます。
また、構造化データを管理対象とするため、文章や画像などの非構造化データの扱いには不向きです。そのため、近年のAI/機械学習といったデータ分析で求められるようなデータの蓄積にはあまり向いてません。
データウェアハウス(Datawarehouse)
データウェアハウス(Datawarehouse)は、主に構造化された大規模なデータを分析用途に最適化して保存するために使用するシステムです。DWH と省略されることもよくあります。
データウェアハウスは、主にテーブル形式の構造化されたデータを事前に加工・整理して蓄積します。整理された情報のため、効率的な分析やレポート作成に適しており、複雑なクエリに対しても高速なレスポンスを提供します。データウェアハウスとして開発/提供されているシステムは、このような状況を高速に対応できるように様々な工夫をして作られています。
後述するデータレイクは、あらゆるデータ形式を扱いますが、データウェアハウスは主に構造化データに焦点を当てているということがポイントです。データレイクは主にそのままの生データを蓄積して使用時に加工しますが、データウェアハウスでは、データを格納する前に加工・整理して蓄積するという違いがあります。
クラウドベースのデータウェアハウスのためのサービスとしては、Amazon のRedshift、Microsoft の Synapse Analytics(専用SQLプール)、Google のBigQuery、Snowflake などがあります。また、オンプレミスのデータウェアハウスシステムとしては、Oracle Exadata、Teradata などがあります。
データウェアハウスは、アナリストなどが、大規模なデータから特定データをクエリで絞って頻繁にアクセスするようなケースでは非常に適した選択肢となります。
データレイク(Datalake)
データレイク(Data Lake)は、構造化、非構造化データをそのままの形式で大量に保存することができるシステムです。データウェアハウスは、主に大規模な構造化データを対象としているのに対して、データレイクはあらゆる形式のデータを扱います。AWS や Azure といったクラウドのデータレイクサービスでは、ファイルベースでのストレージ環境が提供されています。
データレイクの特徴として、多様なデータ形式のものを保存でき、非常に大量のデータを格納することが可能でファイルベースで管理します。データベースよりもスケーラビリティに優れており、時系列データ等の大量データをまとめて取得するケース等では、とても高速に処理できます。また、ファイルベース管理のため、データ利用方法や処理方法を柔軟に技術者が選択できます。
近年のAI、機械学習、データ分析といった OLAP(Online Analytical Processing)の領域では、大量データを処理して意味のある解析、データ活用が必要であり、データレイクの技術が使用されることが多いです。
一方で、多様なデータ形式を扱えることから管理が難しい特徴もあります。例えばファイルを同時にアクセスするとファイルを破壊する可能性があるなど、トランザクション処理には弱いという点があるため、データの品質や整合性維持が比較的難しいという特徴があります。なお、データカタログやメタデータ管理ツールを使用してデータレイク内を効率的に管理する枠組みも提供されています。
データレイクとして有名なクラウドベースとしては Amazon の S3、Microsoft の Azure DataLake Storage (ADLS)、Google の Google Storageなどが代表的なサービスです。
データマート(Datamart)
データマート(Datamart)は、特定のビジネス部門が必要とするデータとして特化して整理したデータのことを言います。
データマートは、概念的なものであるため実現する技術が決まっているわけではありません。データベースやデータウェアハウス製品で実現されることもありますし、データレイクとしてファイルベースで実現されることもあります。
データを活用する際には、データを tableau、QlikSense、PowerBI といった BI(Business Intelligence)ツールにつなげて可視化して分析することが多いです。例えば、製造企業で財務部門と製造部門が分析に求めるデータは異なります。経営層と現場レベルで求めるデータも必要なデータは異なるでしょう。
このような場合に、分析に必要なデータに特化して整理されたデータを用意しておくと分析が非常にしやすくなります。このように特定の領域に特化して整理したデータをデータマートといいます。データウェアハウスやデータレイクのサブセットというようなイメージです。
アナリストなどが頻繁にクエリを発行するようなケースではデータベースやデータウェアハウスの方が適しています。バッチ処理やデータを一括でロードするようなタイプの BI ツールでは、データレイクでファイルベースで実現した方が高速に処理できる場合があります。最大限のパフォーマンスを出すためには、要件に応じて適切な技術を採用することが重要です。
レイクハウス(Lakehouse)
レイクハウス(Lakehouse)は、データレイクとデータウェアハウスの機能を組み合わせた新しいデータ管理アーキテクチャとして近年注目されています。
レイクハウスでは、あらゆるデータ形式を扱うデータレイクのような柔軟性を維持しながら、伝統的なデータウェアハウスのような堅牢なデータ管理機能を提供することを目的としています。つまり、レイクハウスは、構造化されたデータ(通常データウェアハウスで扱われる)と非構造化データ(通常データレイクで扱われる)の両方を単一のシステムで統合的に管理する能力を持ちます。これにより、企業は異なる種類のデータを同じプラットフォーム上で分析できるようになります。
近年のレイクハウス実装では、ACID 特性(A (Atomicity) : 原子性、C (Consistency) : 一貫性、I (Isolation) : 独立性、D (Durability) : 永続性)をサポートするように設計されておりトランザクション管理ができます。なお、すべてのレイクハウスで同等レベルの ACID 特性がサポートされているとは限らないことには注意してください。
レイクハウスは、データ管理と分析のためのモダンなアーキテクチャの概念です。この概念を実現するサービスも出てきています。以降で、レイクハウスとして代表的な Databricks や Microsoft Fabric について簡単に紹介したいと思います。
レイクハウスを実現するサービス例
Databricks
Databricks は、2013 年に設立されたビックデータ分析や機械学習に特化したソフトウェアの企業です。提供されているサービスも Databricks であるため、文脈により会社名を指す場合とサービス名を指す場合とがあります。Databricks 社は、Apache Spark の開発者を中心として立ち上げられました。Databricks は、レイクハウスという概念を提唱して広げていった先駆者と言える企業です。
Databricks は、分散処理基盤である Apach Spark 等のオープンソースのソフトウェアをベースに商業的な展開をしてきました。データソースとしては Microsoft の Azure Datalake Storage、Amazon の S3、Google の Cloud Storage などの様々なデータソースを対象に管理できるのも特徴です。レイクハウスを実現する 1 つの有用な手法である Delta Lake という機能も Databricks 社によって開発されています。
Delta Lake は、データレイク上での ACID 特性を提供し、スケーラブルで安全なデータ処理、管理を提供するための機能レイヤーです。Apache Spark 上で動作し、Parquet 形式でデータを格納します。Delta Lake は、オープンソースの機能であるため自分でも扱うことができますが、Detabricks を使うことによって面倒な管理等を簡単にしてくれます。Databricks は、その他にも機械学習のライフサイクルを管理する MLflowなどの機械学習との連携といった様々な機能を備えています。
レイクハウスは Databricks が提唱した考え方ですが、最近の Databricks では、レイクハウスの概念をさらに広げ「データインテリジェンスプラットフォーム」としてサービスの拡大をしています。
これから企業でレイクハウス構築をしようと思ったときに Databricks を選択するという考え方は、技術の選択や業界をリードする企業かどうかといった観点で、非常に良い選択肢であると考えています。
Microsoft Fabric
Microsoft Fabric は、レイクハウスの概念を Microsoft が実現したサービスです。
この Microsoft Fabric は、あらゆるデータソースや分析サービスを 1 つのプラットフォーム上に集めて接続することで、新しい方法で誰もがデータ簡単にアクセスできるようにするサービスです。Microsoft Fabric は、OneLake という概念で多くのデータを一元管理できるようにしますが、レイクハウスの規定ストレージ形式は Delta Lake となっています。
レイクハウスを実現するという意味では、Databricks とどう違うのかと疑問に思うと思います。Microsoft Fabric は、特に Microsoft の BI サービスである Power BI とデータをうまく連携して活用していく点を重視しているため、既に Office365 といったサービスを広く活用している企業では採用の検討価値があると思います。
なお、Microsoft は、Azure Databricks ということで Databricks も提供しており、Databricks 社と連携をしています。Azure 環境に慣れている企業であれば、Azure Databricks を使うというのも非常によい選択肢です。
まだ Microsoft Fabric は出てきたばかりのサービスであるため、サービスの成熟度を考慮すると Databricks が有利と私は考えています。PowerBI との連携を重視しないのであれば Databricks を選択するのが現状はよいかもしれませんが、今後のMicorosoft Fabric の成長によりどうなるかは正直まだ予想できません。
このように、レイクハウスや Delta Lake 等の関連技術はこれから重要になってくる概念・技術であるため、理解を深めていく必要があると考えています。私も引き続き情報収集や勉強をしていきたいと思います。
まとめ
データ管理技術である、データベース/データウェアハウス/データレイク/データマート/レイクハウスといった技術について紹介しました。
近年では、AI/機械学習といった発展もあり、データ管理技術は非常に重要になってきています。必ずこの技術を採用すればよいということはなく、何も考えずに新しい技術であるからと採用してしまうと失敗の原因になることがあります。
対象とするデータ、業務要件などを充分に検討し、データ管理技術のそれぞれの特徴を理解してうまく選択して、問題を解決していきたいですね。




の作成方法-_array-zeros-ones-full-arange-random-randint-randn-normal-linspace-eye-empty_.jpg)

の分割方法-_-split-vsplit-hsplit-_.jpg)
