KKday 資料分析平台系列 (1) - 資料架構篇
Data Warehouse, Data Lake or Data Lakehouse
多數企業在數位轉型的過程中，嘗試發展數據力，藉由導入資料庫、資料倉儲、商業智慧，第一時間洞察企業內部龐大的資料，以解決企業內部，或是解決商業問題、挖掘商機，但隨著企業的發展，資料量持續增加、資料類型也越趨多元，敏捷、彈性的資料架構能夠提高運用資料的團隊的生產力，成為企業與競爭者之間拉開差距的關鍵之一。
本文將會從資料架構發展演進依序介紹資料倉儲 (Data Warehouse) 、資料湖 (Data Lake) 與 Data Lakehouse。
資料倉儲 (Data Warehouse) 與資料湖 (Data Lake)
資料倉儲 (Data Warehouse)與資料湖 (Data Lake)可以算是資料工作者必備的知識，在網路上有許多專業的文章很詳細地介紹，筆者在下方整理列出兩者的比較，並帶著讀者快速回顧。
資料倉儲(Data Warehouse)
資料倉儲(Data Warehouse)起源於 1980 年前後，它是一個統一的資料儲存庫，主要儲存結構化資料，也能有限的支持如 Json 的半結構化資料。資料倉儲是依靠 ETL 機制從多個資料來源取得(Extract)資料，經過轉換(Transform)後將資料載入(Load)到倉儲裡面。倉儲代表企業中所有資料單一的來源，並支持商業決策和商業智慧(Business Intelligence, BI)，進一步提升企業在商業的洞察力。
資料湖(Data Lake)
隨著商業需求的產生與技術的發展，企業越來越多應用場景必須處理如非結構化的文章、圖片、影片、音訊等越來越常見的資料格式，傳統資料倉儲無法處理在這類非結構化的資料。且傳統資料倉儲儲存成本高，不是儲存大量資料最具成本效益考量的方法，於是在 2010 年前後出現了資料湖(Data Lake)，試圖解決這些問題。
資料湖(Data Lake)是一個集中、彈性高的儲存架構，與儲存經過資料清理(data cleaning)後資料的資料倉儲(Data Warehouse)相比，資料湖以低成本、靈活地儲存大量原始資料形式的結構化、半結構化、非結構化資料，常見的如 Google Cloud Storage (GCS)、AWS S3 等都可以被定義是數據湖。在資料進入資料湖之前，不需要滿足特定的資料 schema，而是在使用資料時才被定義，使企業能夠從非結構化數據中獲得更多洞察結果。
雖然資料湖的設計初衷是解決資料倉儲遇到的挑戰，諸如資料格式支援性不足、儲存非常大量資料的容量與成本問題等，但它不支援 ACID、有較差的資料品質、不被保證的資料可靠性和資料完整性、查詢效能不佳，並且需要搭配其它工具和技術來對資料執行 SQL 查詢，導致資料都往資料湖儲存，但最終這些資料仍無法直接使用，存在資料治理的問題，形成了資料沼澤(Data Swamp)。
因為資料倉儲和資料湖都不是能解決所有問題的唯一解，許多企業在實務上會在當要真正使用資料的時候，再將資料放到多個資料倉儲中使用，形成混合式的資料架構(如下圖)，如此一來企業內就必須同時維護一個資料倉儲系統與一個資料湖系統，提高了企業成本與資料架構複雜度。
試想一個情境，若我們有多個 ETL pipeline 要將資料從企業內部的資料庫移動到資料湖，再從資料湖移動到多個資料倉儲， 當中的每一個 ETL Tasks 都有可能發生延遲與故障，使得要維持每一個副本資料與源頭的一致性，更增添困難與複雜度。
因此，新的資料架構 — Data Lakehouse 結合了資料倉儲與資料湖各別的優勢成一個新的資料架構來解決各別的限制。Lakehouse 基於低成本的 storage 儲存大量保持原始的形式的資料，運用了資料湖的特色，並且直接在資料湖之上提供資料倉儲的性能和管理功能，從而降低維運成本、架構複雜度。
Data Lakehouse
Data Lakehouse，對岸有人將之翻譯為湖倉一體，是由 Databricks 於 2020 年在 What Is a Lakehouse? 一文中提出的概念，文中定義 Lakahouse：
A lakehouse is a new, open architecture that combines the best elements of data lakes and data warehouses. — What Is a Lakehouse?
What Is a Lakehouse? 文中提到了 Lakahouse 具備的關鍵特色，從原文描述比較能完整得到解釋，筆者直接列於下方不多做解釋與翻譯，這些特色點出了 Lakehouse 能夠在支援性、可靠性、易用性三的面向帶來優勢：
- Transaction support: In an enterprise lakehouse many data pipelines will often be reading and writing data concurrently. Support for ACID transactions ensures consistency as multiple parties concurrently read or write data, typically using SQL.
- Schema enforcement and governance: The Lakehouse should have a way to support schema enforcement and evolution, supporting DW schema architectures such as star/snowflake-schemas. The system should be able to reason about data integrity, and it should have robust governance and auditing mechanisms.
- BI support: Lakehouses enable using BI tools directly on the source data. This reduces staleness and improves recency, reduces latency, and lowers the cost of having to operationalize two copies of the data in both a data lake and a warehouse.
- Storage is decoupled from compute: In practice this means storage and compute use separate clusters, thus these systems are able to scale to many more concurrent users and larger data sizes. Some modern data warehouses also have this property.
- Openness: The storage formats they use are open and standardized, such as Parquet, and they provide an API so a variety of tools and engines, including machine learning and Python/R libraries, can efficiently access the data directly.
- Support for diverse data types ranging from unstructured to structured data: The lakehouse can be used to store, refine, analyze, and access data types needed for many new data applications, including images, video, audio, semi-structured data, and text.
- Support for diverse workloads: including data science, machine learning, and SQL and analytics. Multiple tools might be needed to support all these workloads but they all rely on the same data repository.
- End-to-end streaming: Real-time reports are the norm in many enterprises. Support for streaming eliminates the need for separate systems dedicated to serving real-time data applications.
在 2021 年第十一屆的 Conference on Innovative Data Systems Research (CIDR)，由來自 Databricks、UC Berkeley、Stanford University 的幾位專家在所發表的論文 Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics，詳細地說明 Data Lakehouse 的架構與實作細節。
論文中說明 Lakehouse 的架構(下圖)，它將資料的儲存和運算分離，資料儲存在資料湖上，並且加入 Metadata 層，這一層能夠在低成本的資料湖儲存上增加資料管理的功能，包括 ACID、資料版本控制、權限管理、快取、索引。資料的運算處理則是在 Metadata 層之上，可以透過 SQL API 直接讀取資料湖中的原始資料用於 BI 與 Reports，也可以透過 Declarative DataFrame API 將原始資料用於資料科學和機器學習應用。
Data Lakehouse 真的有這麼神？
新的資料架構皆是為了解決不斷發展和產生的商業需求而迭代產生的，但是 Data Lakehouse 是否已是當今企業的最佳選擇嗎？
- 技術尚未成熟： Data Lakehouse 仍是個相對新且不成熟的架構，仍有許多本身架構待解決或是優化的問題，以資料架構發展歷史經驗來看，Lakehoust 可能仍需數年的時間才能與成熟的資料架構或解決方案競爭。
- 統一架構是雙面刃：雖然 Lakehouse 如此大一統的資料架構，看似解決了維護與資料一致性的問題，但在實務應用上是否會因此缺乏靈活性，難以同時滿足所有資料使用者的需求。
- 架構也需適才適所：「沒有最好的架構，只有最適合的架構。」在企業內建置資料架構的過程，會綜合從企業資料規模、資料型態、規劃使用資料來解決的商業問題等各個面向，來評估何種資料架構是適合企業的，而非一昧的追求最新、最潮的解決方案。
