數(shù)據(jù)倉庫、數(shù)據(jù)湖和數(shù)據(jù)流的概念和架構(gòu)是解決業(yè)務(wù)問題的補(bǔ)充。為報(bào)告和分析存儲(chǔ)靜態(tài)數(shù)據(jù)與為實(shí)時(shí)工作負(fù)載連續(xù)處理動(dòng)態(tài)數(shù)據(jù)需要不同的功能和 SLA。存在許多開源框架、商業(yè)產(chǎn)品和 SaaS 云服務(wù)。不幸的是，底層技術(shù)經(jīng)常被誤解，被過度用于單一和不靈活的架構(gòu)，并且被供應(yīng)商推銷為錯(cuò)誤的用例。

數(shù)據(jù)的價(jià)值：事務(wù)性與分析性工作負(fù)載

過去十年提供了許多關(guān)于數(shù)據(jù)成為新石油的文章、博客和演示文稿。今天，沒有人質(zhì)疑數(shù)據(jù)驅(qū)動(dòng)的業(yè)務(wù)流程改變世界并實(shí)現(xiàn)跨行業(yè)創(chuàng)新。

數(shù)據(jù)驅(qū)動(dòng)的業(yè)務(wù)流程既需要實(shí)時(shí)數(shù)據(jù)處理，也需要批處理?？紤]以下跨應(yīng)用程序、域和組織的事件流：

事件是業(yè)務(wù)信息或技術(shù)信息。事件一直在發(fā)生?，F(xiàn)實(shí)世界中的業(yè)務(wù)流程需要各種事件的關(guān)聯(lián)。

一個(gè)事件有多重要？

事件的關(guān)鍵性決定了結(jié)果。潛在影響可能是增加收入、降低風(fēng)險(xiǎn)、降低成本或改善客戶體驗(yàn)。

• 業(yè)務(wù)交易：理想情況下，零停機(jī)時(shí)間和零數(shù)據(jù)丟失。示例：付款只需要處理一次。
• 關(guān)鍵分析：理想情況下，零停機(jī)時(shí)間。單個(gè)傳感器事件的數(shù)據(jù)丟失可能沒問題。對事件聚合發(fā)出警報(bào)更為重要。示例：持續(xù)監(jiān)控物聯(lián)網(wǎng)傳感器數(shù)據(jù)和（預(yù)測性）機(jī)器故障警報(bào)。
• 非關(guān)鍵分析：停機(jī)和數(shù)據(jù)丟失并不好，但不會(huì)扼殺整個(gè)業(yè)務(wù)。這是意外，但不是災(zāi)難。示例：用于預(yù)測需求的報(bào)告和商業(yè)智能。

何時(shí)處理事件

實(shí)時(shí)通常意味著毫秒或秒內(nèi)的端到端處理。如果您不需要實(shí)時(shí)決策，批處理（即在幾分鐘、幾小時(shí)、幾天之后）或按需（即請求-回復(fù)）就足夠了。

• 業(yè)務(wù)交易通常是實(shí)時(shí)的：像支付這樣的交易通常需要實(shí)時(shí)處理（例如，在顧客離開商店之前；在您發(fā)貨之前；在您離開網(wǎng)約車之前）。
• 關(guān)鍵分析通常是實(shí)時(shí)的：關(guān)鍵分析通常需要實(shí)時(shí)處理（例如，在欺詐發(fā)生之前檢測到；在機(jī)器損壞之前預(yù)測機(jī)器故障；在客戶離開商店之前向其追加銷售）。
• 非關(guān)鍵分析通常不是實(shí)時(shí)的：在歷史數(shù)據(jù)中尋找見解通常是在批處理過程中使用復(fù)雜的 SQL 查詢、map-reduce 或復(fù)雜算法（例如，報(bào)告；使用機(jī)器學(xué)習(xí)算法進(jìn)行模型訓(xùn)練；預(yù)測）等范例完成的).

通過這些有關(guān)處理事件的基礎(chǔ)知識(shí)，讓我們了解為什么將所有事件存儲(chǔ)在一個(gè)中央數(shù)據(jù)湖中并不能解決所有問題。

通過權(quán)力下放和同類最佳實(shí)現(xiàn)靈活性

傳統(tǒng)的數(shù)據(jù)倉庫和數(shù)據(jù)湖方法是將所有來源的所有數(shù)據(jù)提取到一個(gè)中央存儲(chǔ)系統(tǒng)中，以實(shí)現(xiàn)集中數(shù)據(jù)所有權(quán)。天空（和您的預(yù)算）是當(dāng)前大數(shù)據(jù)和云技術(shù)的極限。

然而，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、微服務(wù)和數(shù)據(jù)網(wǎng)格等架構(gòu)概念表明，去中心化所有權(quán)是現(xiàn)代企業(yè)架構(gòu)的正確選擇。

不用擔(dān)心。數(shù)據(jù)倉庫和數(shù)據(jù)湖并沒有消亡，而是在數(shù)據(jù)驅(qū)動(dòng)的世界中比以往任何時(shí)候都更加重要。兩者對許多用例都有意義。即使在這些領(lǐng)域之一中，較大的組織也不使用單個(gè)數(shù)據(jù)倉庫或數(shù)據(jù)湖。為工作（在您的領(lǐng)域或業(yè)務(wù)部門）選擇正確的工具是解決業(yè)務(wù)問題的最佳方式。

人們對 Databricks 的批處理 ETL、機(jī)器學(xué)習(xí)甚至數(shù)據(jù)倉庫感到滿意是有充分理由的，但對于某些用例，他們?nèi)匀桓矚g輕量級(jí)的云 SQL 數(shù)據(jù)庫，如 AWS RDS（完全托管的 PostgreSQL）。

有充分的理由讓 Splunk 用戶高興地將一些數(shù)據(jù)提取到 Elasticsearch 中。以及為什么 Cribl 在這個(gè)領(lǐng)域也越來越受歡迎。

有些項(xiàng)目利用Apache Kafka 作為數(shù)據(jù)庫是有充分理由的。在 Kafka 中長期存儲(chǔ)數(shù)據(jù)僅對某些特定用例有意義（例如壓縮主題、鍵/值查詢和流分析）。Kafka 不會(huì)取代其他數(shù)據(jù)庫或數(shù)據(jù)湖。

為具有去中心化數(shù)據(jù)所有權(quán)的工作選擇合適的工具！

考慮到這一點(diǎn)，讓我們探索現(xiàn)代數(shù)據(jù)倉庫的用例和附加值（以及它與數(shù)據(jù)湖和新的熱門話題——湖屋的關(guān)系）。

數(shù)據(jù)倉庫：靜態(tài)數(shù)據(jù)的報(bào)告和商業(yè)智能

數(shù)據(jù)倉庫 (DWH) 提供報(bào)告和數(shù)據(jù)分析功能。它被認(rèn)為是商業(yè)智能的核心組成部分。

靜態(tài)數(shù)據(jù)的用例

無論您使用的是數(shù)據(jù)倉庫、數(shù)據(jù)湖還是 Lakehouse 產(chǎn)品。數(shù)據(jù)靜態(tài)存儲(chǔ)以供進(jìn)一步處理：

• 報(bào)告和商業(yè)智能：快速靈活地提供報(bào)告、統(tǒng)計(jì)數(shù)據(jù)和關(guān)鍵數(shù)據(jù)，例如，確定市場和服務(wù)產(chǎn)品之間的相關(guān)性
• 數(shù)據(jù)工程：整合來自不同結(jié)構(gòu)和分布式數(shù)據(jù)集的數(shù)據(jù)，以識(shí)別數(shù)據(jù)之間隱藏的關(guān)系
• 大數(shù)據(jù)分析和人工智能/機(jī)器學(xué)習(xí)：源數(shù)據(jù)的全局視圖，從而進(jìn)行總體評(píng)估以發(fā)現(xiàn)未知的見解，從而改進(jìn)業(yè)務(wù)流程和相互關(guān)系。

有讀者可能會(huì)說：只有第一個(gè)是數(shù)據(jù)倉庫的用例，其他兩個(gè)是數(shù)據(jù)湖或湖屋！這完全取決于定義。

數(shù)據(jù)倉庫架構(gòu)

DWH 是來自不同來源的集成數(shù)據(jù)的中央存儲(chǔ)庫。它們將歷史數(shù)據(jù)存儲(chǔ)在一個(gè)存儲(chǔ)系統(tǒng)中。數(shù)據(jù)是靜態(tài)存儲(chǔ)的，即保存以供以后分析和處理。業(yè)務(wù)用戶分析數(shù)據(jù)以尋找見解。

數(shù)據(jù)從操作系統(tǒng)上傳，例如物聯(lián)網(wǎng)數(shù)據(jù)、ERP、CRM 和許多其他應(yīng)用程序。數(shù)據(jù)清理和數(shù)據(jù)質(zhì)量保證是 DWH 管道中的關(guān)鍵部分。提取、轉(zhuǎn)換、加載 (ETL) 或提取、加載、轉(zhuǎn)換 (ELT) 是構(gòu)建數(shù)據(jù)倉庫系統(tǒng)的兩種主要方法。數(shù)據(jù)集市有助于專注于數(shù)據(jù)倉庫生態(tài)系統(tǒng)中的單個(gè)主題或業(yè)務(wù)線。

數(shù)據(jù)倉庫與數(shù)據(jù)湖和 Lakehouse 的關(guān)系

數(shù)據(jù)倉庫的重點(diǎn)是使用結(jié)構(gòu)化數(shù)據(jù)進(jìn)行報(bào)告和商業(yè)智能。相反，數(shù)據(jù)湖是存儲(chǔ)和處理原始大數(shù)據(jù)的同義詞。數(shù)據(jù)湖過去是用Hadoop、HDFS、Hive等技術(shù)構(gòu)建的。如今，數(shù)據(jù)倉庫和數(shù)據(jù)湖已合并為一個(gè)解決方案。云原生 DWH 支持大數(shù)據(jù)。同樣，云原生數(shù)據(jù)湖需要使用傳統(tǒng)工具的商業(yè)智能。

Databricks：從數(shù)據(jù)湖到數(shù)據(jù)倉庫的演變

幾乎所有供應(yīng)商都是如此。例如，看看領(lǐng)先的大數(shù)據(jù)供應(yīng)商之一的歷史：Databricks，以 Apache Spark 公司而聞名。該公司最初是大數(shù)據(jù)批處理平臺(tái) Apache Spark 背后的商業(yè)供應(yīng)商。該平臺(tái)通過使用微批處理的（一些）實(shí)時(shí)工作負(fù)載得到增強(qiáng)。幾個(gè)里程碑之后，Databricks 今天是一家完全不同的公司，專注于云、數(shù)據(jù)分析和數(shù)據(jù)倉庫。Databricks 的策略從：

• 開源到云端
• 自管理軟件到完全托管的無服務(wù)器產(chǎn)品
• 專注于 Apache Spark 到 AI/機(jī)器學(xué)習(xí)以及后來添加的數(shù)據(jù)倉庫功能
• 從單一產(chǎn)品到圍繞數(shù)據(jù)分析的龐大產(chǎn)品組合，包括標(biāo)準(zhǔn)化數(shù)據(jù)格式（“Delta Lake”）、治理、ETL 工具（Delta Live Tables）等，

Databricks 和 AWS 等供應(yīng)商還為這種數(shù)據(jù)湖、數(shù)據(jù)倉庫、商業(yè)智能和實(shí)時(shí)功能的合并創(chuàng)造了一個(gè)新的流行語：The Lakehouse。

Lakehouse（有時(shí)稱為 Data Lakehouse）并不是什么新鮮事物。它結(jié)合了獨(dú)立平臺(tái)的特點(diǎn)。我寫了一篇關(guān)于結(jié)合使用 Kafka 和 AWS 分析平臺(tái)在 AWS 上構(gòu)建云原生無服務(wù)器 Lakehouse的文章。

Snowflake：從數(shù)據(jù)倉庫到數(shù)據(jù)湖的演變

雪花從另一個(gè)方向過來。它是所有主要云上可用的第一個(gè)真正的云原生數(shù)據(jù)倉庫。如今，Snowflake 提供了超出傳統(tǒng)商業(yè)智能范圍的更多功能。例如，數(shù)據(jù)和軟件工程師可以通過其他技術(shù)和 API 與 Snowflake 的數(shù)據(jù)湖進(jìn)行交互。數(shù)據(jù)工程師需要 Python 接口來分析歷史數(shù)據(jù)，而軟件工程師更喜歡任何規(guī)模的實(shí)時(shí)數(shù)據(jù)攝取和分析。

無論您是構(gòu)建數(shù)據(jù)倉庫、數(shù)據(jù)湖還是 Lakehouse：關(guān)鍵是了解動(dòng)態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)之間的區(qū)別，以便為您的解決方案找到合適的企業(yè)架構(gòu)和組件。以下部分探討了為什么一個(gè)好的數(shù)據(jù)倉庫架構(gòu)需要兩者以及它們?nèi)绾魏芎玫叵嗷パa(bǔ)充。

事務(wù)性實(shí)時(shí)工作負(fù)載不應(yīng)在數(shù)據(jù)倉庫或數(shù)據(jù)湖中運(yùn)行！由于不同的正常運(yùn)行時(shí)間 SLA、監(jiān)管和合規(guī)性法律以及延遲要求，關(guān)注點(diǎn)分離至關(guān)重要。

數(shù)據(jù)流：用動(dòng)態(tài)數(shù)據(jù)補(bǔ)充現(xiàn)代數(shù)據(jù)倉庫

讓我們澄清一下：數(shù)據(jù)流與數(shù)據(jù)攝取不同！您可以使用 Apache Kafka 等數(shù)據(jù)流技術(shù)將數(shù)據(jù)引入數(shù)據(jù)倉庫或數(shù)據(jù)湖。大多數(shù)公司都這樣做。很好很有價(jià)值。

但是：像 Apache Kafka 這樣的數(shù)據(jù)流平臺(tái)不僅僅是一個(gè)攝取層。因此，它與 AWS Kinesis、Google Pub/Sub 和類似工具等攝取引擎有很大不同。

數(shù)據(jù)流與數(shù)據(jù)攝取不同

數(shù)據(jù)流提供消息傳遞、持久性、集成和處理能力。每秒數(shù)百萬條消息的高可擴(kuò)展性、高可用性（包括向后兼容性和關(guān)鍵任務(wù)工作負(fù)載的滾動(dòng)升級(jí)）以及云原生功能是一些內(nèi)置功能。

數(shù)據(jù)流的事實(shí)標(biāo)準(zhǔn)是 Apache Kafka。因此，我主要將 Kafka 用于數(shù)據(jù)流架構(gòu)和用例。

使用 Apache Kafka 進(jìn)行數(shù)據(jù)流傳輸?shù)氖聞?wù)和分析用例

數(shù)據(jù)流的不同用例數(shù)量幾乎是無窮無盡的。請記住，數(shù)據(jù)流不僅僅是用于數(shù)據(jù)攝取的消息隊(duì)列！雖然將數(shù)據(jù)引入數(shù)據(jù)湖是第一個(gè)突出的用例，但這意味著不到 5% 的實(shí)際 Kafka 部署。業(yè)務(wù)應(yīng)用程序、流式 ETL 中間件、實(shí)時(shí)分析和邊緣/混合場景是其他一些示例：

Kafka的持久層為敏捷和真正解耦的應(yīng)用程序啟用分散的微服務(wù)架構(gòu)。

請記住，Apache Kafka 支持事務(wù)和分析工作負(fù)載。兩者通常具有非常不同的正常運(yùn)行時(shí)間、延遲和數(shù)據(jù)丟失 SLA。查看這篇文章和幻燈片，了解更多關(guān)于Apache Kafka 支持的跨行業(yè)數(shù)據(jù)流用例的信息。

不要（嘗試）使用數(shù)據(jù)倉庫或數(shù)據(jù)湖進(jìn)行數(shù)據(jù)流

本文探討了靜態(tài)數(shù)據(jù)和動(dòng)態(tài)數(shù)據(jù)之間的區(qū)別：

• 數(shù)據(jù)倉庫非常適合報(bào)告和商業(yè)智能。
• 數(shù)據(jù)湖非常適合大數(shù)據(jù)分析和人工智能/機(jī)器學(xué)習(xí)。
• 數(shù)據(jù)流支持實(shí)時(shí)用例。
• 需要一個(gè)分散的、靈活的企業(yè)架構(gòu)來圍繞微服務(wù)和數(shù)據(jù)網(wǎng)格構(gòu)建現(xiàn)代數(shù)據(jù)堆棧。

沒有一項(xiàng)技術(shù)是靈丹妙藥。為問題選擇正確的工具。單體架構(gòu)無法解決當(dāng)今的業(yè)務(wù)問題。僅靜態(tài)存儲(chǔ)所有數(shù)據(jù)無助于滿足實(shí)時(shí)用例的需求。

Kappa 架構(gòu)是一種用于實(shí)時(shí)和批處理工作負(fù)載的現(xiàn)代方法，可避免使用 Lambda 架構(gòu)的復(fù)雜得多的基礎(chǔ)架構(gòu)。數(shù)據(jù)流補(bǔ)充了數(shù)據(jù)倉庫和數(shù)據(jù)湖。如果您選擇合適的供應(yīng)商（通常是戰(zhàn)略合作伙伴，而不是一些人認(rèn)為的競爭對手），這些系統(tǒng)之間的連接是開箱即用的。

您今天如何結(jié)合數(shù)據(jù)倉庫和數(shù)據(jù)流？Kafka 只是您進(jìn)入數(shù)據(jù)湖的攝取層嗎？您是否已經(jīng)將數(shù)據(jù)流用于其他實(shí)時(shí)用例？或者 Kafka 是否已經(jīng)成為企業(yè)架構(gòu)中用于解耦微服務(wù)和數(shù)據(jù)網(wǎng)格的戰(zhàn)略組件？