數(shù)據(jù)倉庫是糟糕的應(yīng)用程序后端
盡管商業(yè)智能分析有用，但它們無法以效益化的方式滿足面向數(shù)據(jù)應(yīng)用的實(shí)時(shí)性、延遲性和并發(fā)性的需求。
翻譯自 Data Warehouses Are Terrible Application Backends 。
日益增長(zhǎng)的數(shù)據(jù)洪流已經(jīng)成為當(dāng)今開發(fā)者的富余困境。根據(jù) Seagate 的報(bào)告，到 2025 年，全球的數(shù)據(jù)量將激增至驚人的 163 澤字節(jié)，比 2016 年增長(zhǎng) 10 倍以上。更多的數(shù)據(jù)應(yīng)意味著更深入的洞察和更好的用戶體驗(yàn)，但它也會(huì)導(dǎo)致問題。
對(duì)于面向數(shù)據(jù)的開發(fā)者來說，這種爆炸式增長(zhǎng)是一把雙刃劍。它提供了一個(gè)利用數(shù)據(jù)和實(shí)時(shí)分析來構(gòu)建用戶特征的無與倫比的機(jī)會(huì)。另一方面，以最小延遲和高并發(fā)處理所有這些數(shù)據(jù)對(duì)于典型的現(xiàn)代數(shù)據(jù)堆棧來說可能是一個(gè)巨大的挑戰(zhàn)。
特別是，數(shù)據(jù)倉庫成為當(dāng)今公司大數(shù)據(jù)的首選存儲(chǔ)地，它們的在線分析處理(OLAP)方法非常適合針對(duì)業(yè)務(wù)智能報(bào)告和儀表盤等目的，對(duì)大數(shù)據(jù)執(zhí)行復(fù)雜的長(zhǎng)時(shí)間運(yùn)行的分析查詢。
然而，它們當(dāng)應(yīng)用后端效果很糟糕。
本文解釋了為什么作業(yè)池管理、并發(fā)約束和延遲問題都阻止了數(shù)據(jù)倉庫有效地作為面向用戶的應(yīng)用程序的存儲(chǔ)層發(fā)揮作用，以及為什么您應(yīng)該考慮為您的數(shù)據(jù)應(yīng)用堆棧選擇替代技術(shù)。
了解數(shù)據(jù)倉庫
十年前，數(shù)據(jù)倉庫在數(shù)據(jù)世界中是非常熱門的新事物。數(shù)據(jù)倉庫能夠存儲(chǔ)大量結(jié)構(gòu)化數(shù)據(jù)并處理復(fù)雜的分析查詢，它們?yōu)槠髽I(yè)運(yùn)行內(nèi)部業(yè)務(wù)智能流程設(shè)置了新標(biāo)準(zhǔn)。
特別是，數(shù)據(jù)倉庫具有以下三個(gè)功能，使分析變得可訪問和強(qiáng)大:
它們分離存儲(chǔ)和計(jì)算，降低擴(kuò)展成本。
它們利用分布式計(jì)算和云網(wǎng)絡(luò)最大化查詢吞吐量。
它們使用眾所周知的 SQL 民主化分析。
如果您想深入了解數(shù)據(jù)倉庫的存在原因以及它們?yōu)楝F(xiàn)代數(shù)據(jù)團(tuán)隊(duì)啟用的功能，我鼓勵(lì)您閱讀這個(gè)文章。
如今，像 Snowflake、BigQuery、Redshift 和 Azure Synapse 這樣的數(shù)據(jù)倉庫在許多公司的數(shù)據(jù)堆棧中仍然占據(jù)重要位置，由于在組織內(nèi)的優(yōu)先地位，開發(fā)人員可能會(huì)傾向于將它們用作面向用戶的分析的存儲(chǔ)層。它們有能力運(yùn)行這些用例所需的復(fù)雜分析查詢;數(shù)據(jù)已經(jīng)在那里，您已經(jīng)為它們支付了費(fèi)用。有什么不好的呢?
事實(shí)證明，有很多不好的地方。以下是為什么應(yīng)用程序開發(fā)人員不能依賴數(shù)據(jù)倉庫作為他們面向用戶的分析的存儲(chǔ)層的原因。
不可預(yù)測(cè)的作業(yè)池和非確定性延遲的世界
數(shù)據(jù)倉庫以作業(yè)池的形式處理分析查詢。例如，Snowflake 使用共享池方法并發(fā)處理查詢，旨在優(yōu)化可用的計(jì)算資源。
這里的問題是:作業(yè)池創(chuàng)建了具有固定下限的非確定性延遲。Snowflake 上的一個(gè)簡(jiǎn)單的?SELECT 1?可能只需要幾毫秒，但更可能的是，由于必須與所有其他查詢一起在隊(duì)列中處理，它至少需要一秒鐘或者更長(zhǎng)時(shí)間。
即使最佳的查詢優(yōu)化策略也無法克服這一限制。
在數(shù)據(jù)倉庫上運(yùn)行查詢就像玩“延遲輪盤賭”游戲。您可以每次以相同的方式旋轉(zhuǎn)輪盤，但最終結(jié)果(在這種情況下，查詢響應(yīng)的延遲)會(huì)不可預(yù)測(cè)地出現(xiàn)。
現(xiàn)在，如果您是一個(gè)在存儲(chǔ)層上構(gòu)建 API 的后端開發(fā)人員，您絕不會(huì)冒非確定性延遲的風(fēng)險(xiǎn)。用戶期望快速響應(yīng)的 API，響應(yīng)時(shí)間在毫秒級(jí)內(nèi)。事實(shí)上，數(shù)據(jù)庫查詢應(yīng)該是請(qǐng)求路徑中最快的部分之一，即使與網(wǎng)絡(luò)延遲相比也是如此。如果您在數(shù)據(jù)倉庫之上構(gòu)建，情況就不會(huì)如此，您的用戶會(huì)感受到痛苦。
可擴(kuò)展性的幻覺
對(duì)于 API 構(gòu)建者來說，延遲只是方程式的一部分。第二個(gè)是并發(fā)性。如果您正在構(gòu)建預(yù)期可以擴(kuò)展的 API，那么穩(wěn)固的基礎(chǔ)要求您為大量并發(fā)用戶提供低延遲響應(yīng)。
當(dāng)您深入研究數(shù)據(jù)倉庫的功能時(shí)，您會(huì)意識(shí)到為了真正橫向擴(kuò)展以適應(yīng)增加的查詢并發(fā)性，您需要啟動(dòng)新的虛擬數(shù)據(jù)倉庫或者增加群集限制，或者兩者兼而有之。例如，如果您想在 Snowflake 上支持每分鐘僅 100 個(gè)并發(fā)查詢，您需要 10 個(gè)多集群數(shù)據(jù)倉庫。
而啟動(dòng)新數(shù)據(jù)倉庫的成本不菲。去問問你在數(shù)據(jù)工程部門的伙伴們吧。對(duì)于 Snowflake 的例子，您每個(gè)月將支付超過 30，000 美元。
Snowflake 等數(shù)據(jù)倉庫中的并發(fā)約束呈現(xiàn)了開發(fā)實(shí)時(shí)應(yīng)用程序時(shí)面臨的最重大挑戰(zhàn)之一。隨著大量查詢敲打您的數(shù)據(jù)倉庫的大門，以及有限的資源來為它們提供服務(wù)，除非您進(jìn)行擴(kuò)容，否則您一定會(huì)遇到嚴(yán)重的延遲問題。而擴(kuò)容的成本往往過高。
構(gòu)建緩存層：一種近期趨勢(shì)及其缺點(diǎn)
好吧，沒有人會(huì)真的在數(shù)據(jù)倉庫之上直接構(gòu)建一個(gè)應(yīng)用程序，對(duì)吧?顯然，您會(huì)使用 Redis 或其他實(shí)時(shí)數(shù)據(jù)庫等緩存層，以確保即使在許多并發(fā)用戶的情況下，您的 API 請(qǐng)求也很快且負(fù)載均衡。
這是一種常見的方法，當(dāng)您需要支持的應(yīng)用程序中的數(shù)據(jù)駐留在數(shù)據(jù)倉庫中時(shí)。從理論上講，這種方法似乎可行。但在現(xiàn)實(shí)中，它帶來了一些嚴(yán)重的缺點(diǎn)，其中最重要的是數(shù)據(jù)的實(shí)時(shí)性。
簡(jiǎn)單地說，使用緩存層可以大大縮短查詢延遲，但它仍然無法用于構(gòu)建必須始終服務(wù)最新事件的流數(shù)據(jù)之上的應(yīng)用程序。
想象一個(gè)欺詐檢測(cè)用例，其中金融機(jī)構(gòu)必須在完成交易(幾秒鐘)的時(shí)間內(nèi)確定交易是否存在欺詐。這通常涉及基于剛創(chuàng)建的數(shù)據(jù)的復(fù)雜分析過程或在線機(jī)器學(xué)習(xí)特征庫。如果該數(shù)據(jù)在您的后端 API 之前進(jìn)入數(shù)據(jù)倉庫，則不存在任何緩存層可以拯救您。緩存層非常適合通過存儲(chǔ)在批處理 ETL(提取、轉(zhuǎn)換、加載)流程中最近運(yùn)行的分析來啟用低延遲的 API 請(qǐng)求，但它無法訪問剛創(chuàng)建的數(shù)據(jù)，因?yàn)閿?shù)據(jù)倉庫仍在處理這些數(shù)據(jù)。
替代方案：實(shí)時(shí)數(shù)據(jù)平臺(tái)
正如我們所討論的，在數(shù)據(jù)倉庫之上構(gòu)建數(shù)據(jù)密集型應(yīng)用程序的根本問題歸結(jié)為無法維持:
低延遲查詢
來自高并發(fā)用戶
在實(shí)時(shí)數(shù)據(jù)上
那么，替代方案是什么呢?
對(duì)于構(gòu)建面向用戶的應(yīng)用程序，您應(yīng)該使用實(shí)時(shí)數(shù)據(jù)平臺(tái)，如 Tinybird 。
什么是實(shí)時(shí)數(shù)據(jù)平臺(tái)?
實(shí)時(shí)數(shù)據(jù)平臺(tái)幫助數(shù)據(jù)和工程團(tuán)隊(duì)在大規(guī)模流數(shù)據(jù)上創(chuàng)建高并發(fā)、低延遲的數(shù)據(jù)產(chǎn)品。
實(shí)時(shí)數(shù)據(jù)平臺(tái)在引擎蓋下使用列式數(shù)據(jù)庫，因此它可以處理以前只降級(jí)到數(shù)據(jù)倉庫的復(fù)雜分析工作負(fù)載，但速度要快得多。此外，實(shí)時(shí)數(shù)據(jù)平臺(tái)通常提供低延遲發(fā)布層，為可能依賴于批處理和流數(shù)據(jù)源的數(shù)據(jù)密集型應(yīng)用程序公開低延遲 API。在流數(shù)據(jù)平臺(tái)上按規(guī)模構(gòu)建 API 通常不被考慮，但隨著數(shù)據(jù)的增長(zhǎng)，維護(hù)和擴(kuò)展可能會(huì)成為巨大的痛點(diǎn)。
實(shí)時(shí)數(shù)據(jù)平臺(tái)的參考架構(gòu)
在實(shí)時(shí)數(shù)據(jù)平臺(tái)之上構(gòu)建時(shí)，請(qǐng)考慮數(shù)據(jù)堆棧的兩種增量架構(gòu)。
在第一種方法中，數(shù)據(jù)倉庫仍然可以是主要的支撐存儲(chǔ)層，而實(shí)時(shí)數(shù)據(jù)平臺(tái)實(shí)際上充當(dāng)發(fā)布層。在這種架構(gòu)中，數(shù)據(jù)在數(shù)據(jù)倉庫和實(shí)時(shí)數(shù)據(jù)平臺(tái)之間以計(jì)劃的方式或在攝取時(shí)同步，實(shí)時(shí)數(shù)據(jù)平臺(tái)處理額外的轉(zhuǎn)換以及提供低延遲、高并發(fā)的 API。
實(shí)時(shí)數(shù)據(jù)平臺(tái)如 Tinybird 可以通過使用本機(jī)連接器作為數(shù)據(jù)倉庫上的緩存層運(yùn)行。通過這種方式，它們消除了編寫自定義對(duì)象關(guān)系映射(ORM)代碼的需要，但仍可能會(huì)遭受一些數(shù)據(jù)實(shí)時(shí)性約束。
在實(shí)踐中，這類似于在數(shù)據(jù)倉庫上使用實(shí)時(shí)數(shù)據(jù)平臺(tái)作為緩存層，額外的好處是避免了編寫自定義 API 代碼將緩存連接到應(yīng)用程序，并具有使用完整聯(lián)機(jī)分析處理(OLAP)的強(qiáng)大功能進(jìn)行額外的增強(qiáng)或轉(zhuǎn)換的能力。
第二種方法完全繞過數(shù)據(jù)倉庫或并行運(yùn)行。假設(shè)事件數(shù)據(jù)被放置在某種消息隊(duì)列或流平臺(tái)上，實(shí)時(shí)數(shù)據(jù)平臺(tái)訂閱流主題并在創(chuàng)建數(shù)據(jù)時(shí)攝取數(shù)據(jù)，執(zhí)行必要的轉(zhuǎn)換并為應(yīng)用程序使用提供 API 層。
實(shí)時(shí)數(shù)據(jù)平臺(tái)如 Tinybird 可以通過使用本機(jī)連接器作為數(shù)據(jù)倉庫上的緩存層運(yùn)行。通過這種方式，它們消除了編寫自定義對(duì)象關(guān)系映射(ORM)代碼的需要，但仍可能會(huì)遭受一些數(shù)據(jù)實(shí)時(shí)性約束。
這可能是首選方法，因?yàn)樗巳源嬖谟跀?shù)據(jù)倉庫上使用緩存層的數(shù)據(jù)實(shí)時(shí)性問題，并且使用正確的實(shí)時(shí)數(shù)據(jù)平臺(tái)，流式攝取可以非常簡(jiǎn)單。
實(shí)時(shí)數(shù)據(jù)平臺(tái)的好處
原生數(shù)據(jù)源連接器：實(shí)時(shí)數(shù)據(jù)平臺(tái)可以與各種數(shù)據(jù)源和其他技術(shù)棧組件集成。這使得統(tǒng)一和連接多個(gè)數(shù)據(jù)源以實(shí)現(xiàn)實(shí)際用例變得非常簡(jiǎn)單。例如，您可以將來自 Snowflake 或 BigQuery 的數(shù)據(jù)與 Confluent 或 Apache Kafka 的流數(shù)據(jù)相結(jié)合。例如，Tinybird 甚至提供了一個(gè)簡(jiǎn)單的 HTTP 流端點(diǎn)，可以輕松地直接在上游應(yīng)用程序代碼中流式傳輸事件。
實(shí)時(shí) OLAP 功能：與數(shù)據(jù)倉庫一樣，實(shí)時(shí)數(shù)據(jù)平臺(tái)為開發(fā)人員提供運(yùn)行復(fù)雜 OLAP 工作負(fù)載的能力。
經(jīng)濟(jì)高效：使用傳統(tǒng)方法在 Snowflake 上建立發(fā)布層將需要額外的虛擬數(shù)據(jù)倉庫，從而導(dǎo)致成本增加。相比之下，實(shí)時(shí)數(shù)據(jù)平臺(tái)的定價(jià)模型通常以通過發(fā)布層處理的數(shù)據(jù)量為基礎(chǔ)，這大大降低了用作應(yīng)用后端時(shí)的成本。
可伸縮性：許多實(shí)時(shí)數(shù)據(jù)平臺(tái)是無服務(wù)器的，因此基礎(chǔ)架構(gòu)隨您的業(yè)務(wù)增長(zhǎng)而擴(kuò)展，使用高級(jí)別的性能和可用性來處理大數(shù)據(jù)。與在裸機(jī)服務(wù)器上托管數(shù)據(jù)庫或使用托管數(shù)據(jù)庫調(diào)整集群設(shè)置不同，您可以專注于構(gòu)建和交付用例，而實(shí)時(shí)數(shù)據(jù)平臺(tái)將在引擎蓋下處理規(guī)模。
零膠水代碼：即使在數(shù)據(jù)倉庫上使用緩存層，您仍然需要編寫粘合代碼:將數(shù)據(jù)從倉庫移到緩存的 ETL，以及從緩存發(fā)布 API 的對(duì)象關(guān)系映射代碼。相比之下，實(shí)時(shí)數(shù)據(jù)平臺(tái)處理整個(gè)數(shù)據(jù)流，從攝取到發(fā)布，零膠水代碼。使用本機(jī)連接器同步數(shù)據(jù)，使用 SQL 定義轉(zhuǎn)換，并使用內(nèi)置文檔、認(rèn)證令牌管理和動(dòng)態(tài)查詢參數(shù)即時(shí)發(fā)布可伸縮 API。
與數(shù)據(jù)倉庫一樣，Tinybird 提供了基于 SQL 的轉(zhuǎn)換的 OLAP 存儲(chǔ)。與數(shù)據(jù)倉庫不同，它保留了數(shù)據(jù)的實(shí)時(shí)性并提供了低延遲、高并發(fā)的 API 層以支持應(yīng)用程序開發(fā)。
當(dāng)數(shù)據(jù)倉庫作為應(yīng)用后端失效時(shí)， Tinybird 等實(shí)時(shí)數(shù)據(jù)平臺(tái)則大放異彩。與數(shù)據(jù)倉庫一樣，這些平臺(tái)支持大數(shù)據(jù)量和復(fù)雜的分析，但它們以保留數(shù)據(jù)實(shí)時(shí)性、最小化查詢延遲并擴(kuò)展以支持高并發(fā)的方式做到了這一點(diǎn)。
總結(jié)
數(shù)據(jù)倉庫不是壞技術(shù)，但它們是糟糕的應(yīng)用后端。盡管它們?cè)跇I(yè)務(wù)智能方面強(qiáng)大且有用，但它們無法以具有成本效益的方式處理面向數(shù)據(jù)應(yīng)用程序必須支持的實(shí)時(shí)性、延遲和并發(fā)需求。
另一方面，實(shí)時(shí)數(shù)據(jù)平臺(tái)在各種各樣的數(shù)據(jù)密集型應(yīng)用程序的后端起著非常好的作用，跨許多用例:實(shí)時(shí)個(gè)性化、產(chǎn)品內(nèi)分析、運(yùn)營(yíng)智能、異常檢測(cè)、基于用量的定價(jià)、體育博彩和游戲、庫存管理等等。
本文使用 文章同步助手 同步
