相信身處于大數(shù)據(jù)領(lǐng)域的讀者多少都能感受到，大數(shù)據(jù)技術(shù)的應(yīng)用場景正在發(fā)生影響深遠(yuǎn)的變化: 隨著實(shí)時(shí)計(jì)算、Kubernetes 的崛起和 HTAP、流批一體的大趨勢，之前相對(duì)獨(dú)立的大數(shù)據(jù)技術(shù)正逐漸和傳統(tǒng)的在線業(yè)務(wù)融合。關(guān)于該話題，筆者早已如鯁在喉，但因拖延癥又犯遲遲沒有動(dòng)筆，最終借最近參加多項(xiàng)會(huì)議收獲不少感悟的契機(jī)才能克服懶惰寫下這片文章。 本文旨在簡單回顧大數(shù)據(jù)的歷史，然后概括當(dāng)前的主要發(fā)展趨勢以及筆者的思考，最后不免主觀地展望未來。 01、過去：先進(jìn)與落后并存 大數(shù)據(jù)起源于 21 世紀(jì)初 Web 2.0[1] 帶來的互聯(lián)網(wǎng)爆發(fā)性增長，當(dāng)時(shí) Google、雅虎等頭部公司的數(shù)據(jù)量級(jí)已經(jīng)遠(yuǎn)超單機(jī)可處理，并且其中大部分?jǐn)?shù)據(jù)是網(wǎng)頁文本這樣的非結(jié)構(gòu)化、半結(jié)構(gòu)化數(shù)據(jù)，用傳統(tǒng)的數(shù)據(jù)庫基本無法處理，因此開始探索新型的數(shù)據(jù)存儲(chǔ)和計(jì)算技術(shù)。在 2003-2006 年里，Google 發(fā)布了內(nèi)部研發(fā)成果的論文，即被稱為 Google 三駕馬車的 GFS、MapReduce 和 Bigtable 論文。在此期間，雅虎基于 GFS/MapReduce 論文建立了開源的 Hadoop 項(xiàng)目，奠定了后續(xù)十多年大數(shù)據(jù)發(fā)展的基礎(chǔ)，也在同時(shí)大數(shù)據(jù)一詞被廣泛被用于描述這類數(shù)據(jù)量過大或過于復(fù)雜而無法通過傳統(tǒng)單機(jī)技術(shù)處理的系統(tǒng)[2]。 然而，雖然以 MapReduce 作為代表的通用數(shù)據(jù)存儲(chǔ)計(jì)算框架在搜索引擎場景獲得巨大成功，但是在于之存在競爭關(guān)系的數(shù)據(jù)庫社區(qū)看來，MapReduce 是一次巨大的倒退（”A major step backwards”）[3]。主要原因大致如下: 編程模型的巨大倒退，缺乏 schema 和高級(jí)數(shù)據(jù)訪問語言 實(shí)現(xiàn)非常原始，基本是暴力遍歷而不是使用索引 理念落后，是 25 年前的技術(shù)實(shí)現(xiàn) 缺少當(dāng)時(shí) DBMS 標(biāo)配的大部分特性，比如事務(wù)、數(shù)據(jù)更新 與當(dāng)時(shí) DBMS 用戶依賴的工具不兼容 在筆者看來，這篇論文直言不諱地指出了大數(shù)據(jù)系統(tǒng)的不足，時(shí)至今日仍非常有指導(dǎo)意義。而此后的十多年，也正是大數(shù)據(jù)系統(tǒng)逐漸完善彌補(bǔ)這些缺陷的過程，比如 Hive/Spark 填補(bǔ)了高級(jí)編程模型的空白，Parquet/ORC 等存儲(chǔ)格式給文件添加了索引，如今的數(shù)據(jù)湖又在實(shí)現(xiàn)缺失的 ACID 事務(wù)特性。不過值得一提的是，這些批評(píng)是對(duì)于通用數(shù)據(jù)庫場景而言，因?yàn)樗阉饕鎴鼍搬槍?duì)的是無結(jié)構(gòu)化/非結(jié)構(gòu)化數(shù)據(jù)，而且 Google 搜索本身就是一個(gè)巨大的倒排索引（因此無需額外索引）。 由于大數(shù)據(jù)系統(tǒng)特性上的種種不足和技術(shù)棧的獨(dú)立性，大數(shù)據(jù)在過去的十多年中雖然發(fā)展迅猛，各種項(xiàng)目百花齊放，但應(yīng)用場景仍很大程度上局限在數(shù)據(jù)倉庫、機(jī)器學(xué)習(xí)等數(shù)據(jù)準(zhǔn)確性要求沒有那么高的場景下。其中很多項(xiàng)目也在設(shè)計(jì)之初就定位在某些細(xì)分應(yīng)用場景而不是通用場景，比如 Hive 定位為數(shù)據(jù)倉庫，Storm 定位為對(duì)于離線數(shù)據(jù)倉庫的實(shí)時(shí)增量補(bǔ)充[5]。雖然這可以視為支持大數(shù)據(jù)量級(jí)而做的 trade-off，但客觀上也造成了大數(shù)據(jù)生態(tài)圈的非常復(fù)雜，要完整地用好大數(shù)據(jù)，通常要引入至少十余個(gè)組件，無論對(duì)于大數(shù)據(jù)團(tuán)隊(duì)還是用戶而言都有較高的門檻。 02、現(xiàn)在：百花齊放與融合統(tǒng)一 所謂天下大勢分久必合，一方面大數(shù)據(jù)生態(tài)中各類組件獨(dú)立的開發(fā)使用成本在業(yè)務(wù)穩(wěn)定后已經(jīng)成為不可小覷的開支，另一方面技術(shù)發(fā)展也使得不少組件有共享底層設(shè)施或技術(shù)棧的基礎(chǔ)，因此 “融合” 將是當(dāng)下最為明顯的趨勢，具體分為幾個(gè)方向: 計(jì)算的流批一體、存儲(chǔ)的流批一體、在離線服務(wù)混部、HTAP。 1.計(jì)算的流批一體 計(jì)算的流批一體指的是用同一套計(jì)算框架同時(shí)來實(shí)現(xiàn)流計(jì)算和批計(jì)算，目標(biāo)是解決 Lambda 架構(gòu)離線批處理和實(shí)時(shí)流處理兩個(gè)不同編程模型的重復(fù)數(shù)據(jù)管道的問題。 之所以會(huì)形成這樣的架構(gòu)，主要原因是實(shí)時(shí)流計(jì)算發(fā)展早期無法提供準(zhǔn)確一次的語義（Exactly-Once Semantics），在出現(xiàn)異常重試或數(shù)據(jù)延遲的情況下很容易導(dǎo)致數(shù)據(jù)少算或多算，因此需要依賴成熟可靠的離線批計(jì)算來定時(shí)修正數(shù)據(jù)。兩者在數(shù)據(jù)準(zhǔn)確性上的差別主要來源于：離線批計(jì)算的數(shù)據(jù)是有界的（因此不用考慮數(shù)據(jù)是否完整）且允許較高延遲，因而幾乎不需要在數(shù)據(jù)準(zhǔn)確性和延遲間做 trade-off；而實(shí)時(shí)流計(jì)算非常依賴輸入數(shù)據(jù)的低延遲，如果某個(gè)時(shí)間點(diǎn)產(chǎn)生的業(yè)務(wù)數(shù)據(jù)沒有及時(shí)被處理，那么它很可能被錯(cuò)誤地算入下個(gè)統(tǒng)計(jì)計(jì)算窗口，可能導(dǎo)致前后兩個(gè)窗口的數(shù)據(jù)都不準(zhǔn)確。 然而，2015 年 Google Dataflow Model 論文的發(fā)布[6]厘清了流處理和批處理的對(duì)立統(tǒng)一的關(guān)系，即批處理是流處理的特例，這為流批一體的大趨勢奠定了基礎(chǔ)。本文不打算過于深入 Dataflow Model 內(nèi)容，簡單來說，論文引入了對(duì)于流處理至關(guān)重要的兩個(gè)概念：Watermark 和 Accumulation Mode（結(jié)果累積模式）。Watermark 由數(shù)據(jù)本身的業(yè)務(wù)時(shí)間提取而成（這被稱為 Event Time 時(shí)間特性），表示對(duì)輸入數(shù)據(jù)的業(yè)務(wù)時(shí)間的估計(jì)。依據(jù) Watermark 而不是數(shù)據(jù)處理時(shí)間來觸發(fā)計(jì)算，這樣可以很大程度上解決流計(jì)算對(duì)延遲的依賴問題。另一方面，Accumulation Mode 定義了流計(jì)算不同執(zhí)行產(chǎn)生的結(jié)果之間的關(guān)系，從而使得流計(jì)算可以先輸出不完整的中間結(jié)果，然后再逐步修正，最終收斂至準(zhǔn)確結(jié)果。 在開源界，最早采用流批一體計(jì)算模型的計(jì)算框架 Flink/Beam 等，在經(jīng)過幾年的迭代后流批一體已經(jīng)逐漸達(dá)到生產(chǎn)可用，并陸續(xù)在前沿的公司落地。由于流批一體涉及到大量業(yè)務(wù)改造，在目前 Lambda 架構(gòu)已經(jīng)穩(wěn)定運(yùn)行多年的情況下，推動(dòng)存量業(yè)務(wù)的改造的主要?jiǎng)恿碓从? 降本增效。避免同時(shí)建設(shè)兩套數(shù)據(jù)管道的機(jī)器和人力成本。 對(duì)齊口徑。批處理的 schema 與流處理的 schema 可能存在不一致，比如同一個(gè)指標(biāo)在批處理可能是天粒度，而流處理是分鐘粒度。這樣的不一致導(dǎo)致同時(shí)使用流和批的結(jié)果時(shí)容易出錯(cuò)。 值得注意的是，流批一體并不是將 Lambda 架構(gòu)中的離線管道改為與實(shí)時(shí)管道相同的引擎，并與之前一樣雙跑，而是令作業(yè)可以靈活在兩種模式上自由切換。通常來說，對(duì)延遲不敏感的業(yè)務(wù)可以用批的模式執(zhí)行來提高資源利用率，而當(dāng)業(yè)務(wù)變?yōu)檠舆t敏感時(shí)可以無縫切換為實(shí)時(shí)流處理模式。而在需要修正實(shí)時(shí)計(jì)算結(jié)果時(shí)，也可以直接采用 Kappa 架構(gòu)[7]的方式復(fù)制一個(gè)作業(yè)以批模式來重刷部分?jǐn)?shù)據(jù)。 2.存儲(chǔ)的流批一體 眾所周知，批處理中常讀寫文件系統(tǒng)，用文件作為存儲(chǔ)抽象；而流處理中常讀寫消息隊(duì)列，用隊(duì)列作為存儲(chǔ)抽象。在 Lambda 架構(gòu)中，我們常常要將同時(shí)數(shù)據(jù)寫入 HDFS、S3 等文件系統(tǒng)或?qū)ο蟠鎯?chǔ)供批處理使用，并寫入 Kafka 等消息隊(duì)列供流處理使用。盡管消息隊(duì)列通過只保留最近一段時(shí)間的數(shù)據(jù)來減少數(shù)據(jù)存儲(chǔ)成本，但這樣兩套系統(tǒng)的冗余仍造成很大的機(jī)器資源開銷和人力資源成本。在計(jì)算的流批一體大趨勢下，存儲(chǔ)的流批一體的推進(jìn)自然也是順?biāo)浦邸? 不過不同于計(jì)算有 Dataflow Model 這樣能讓業(yè)界達(dá)成 “批處理是流處理特例” 共識(shí)的重量級(jí)論文，存儲(chǔ)的流批一體仍處在基于文件系統(tǒng)和基于消息隊(duì)列兩種流派不相伯仲的狀況。基于文件來實(shí)現(xiàn)隊(duì)列特性的代表是 Iceberg/Hudi/DeltaLake 等數(shù)據(jù)湖，而以隊(duì)列來實(shí)現(xiàn)文件特性的代表是 Pulsar/Prevega 等新型消息隊(duì)列系統(tǒng)。 在筆者看來，文件存儲(chǔ)和隊(duì)列存儲(chǔ)經(jīng)過一定的改進(jìn)都可以滿足流批一體的需求，比如 Pulsar 支持將數(shù)據(jù)歸檔到分級(jí)存儲(chǔ)并可選擇 Segment(文件) API 或 Message(隊(duì)列) API 來讀取，而 Iceberg 支持文件的批量讀取或流式地監(jiān)聽文件。然而結(jié)合計(jì)算的流批一體而言，兩者在寫入更新 API 方面有根本的不同，并且該不同點(diǎn)進(jìn)一步導(dǎo)致了兩者的許多不同特性： 更新方式。雖然文件和隊(duì)列在大數(shù)據(jù)場景下通常都是以 Append 方式寫入，但文件支持對(duì)已經(jīng)寫入數(shù)據(jù)的更新，而隊(duì)列則不允許直接更新，而是通過寫入新數(shù)據(jù)加 Compact 刪除舊數(shù)據(jù)的方式來間接更新。這意味著在批處理中讀寫隊(duì)列或在流處理中讀寫文件都有一些不自然（下文會(huì)詳細(xì)說明）。在數(shù)據(jù)湖等基于文件的存儲(chǔ)中，流式讀取通常以監(jiān)聽 Changelog 的方式實(shí)現(xiàn)；而在基于隊(duì)列的存儲(chǔ)中，批處理要重算更新結(jié)果，則無法直接刪除或覆蓋之前已經(jīng)寫入隊(duì)列的結(jié)果，要么轉(zhuǎn)為 Changelog 要么重建一個(gè)新隊(duì)列。版本控制。由于更新方式的不同，文件中的數(shù)據(jù)是可變的，而隊(duì)列中的數(shù)據(jù)是不可變的。文件表示某個(gè)時(shí)間點(diǎn)的狀態(tài)，因此數(shù)據(jù)湖需要版本控制以增加回溯的功能；而相對(duì)地，隊(duì)列則表示一段時(shí)間內(nèi)狀態(tài)變化的事件，本來有 Event Sourcing 的能力，因此不需要版本控制。并行寫入。文件有唯一的寫鎖，只允許單個(gè)進(jìn)程寫入。數(shù)據(jù)湖通常以整個(gè)目錄作為一個(gè)表暴露給用戶，如果有多并行寫入，則在該目錄下為每個(gè)并行進(jìn)程新增基于文件的快照進(jìn)行隔離（MVCC）。而相對(duì)地，隊(duì)列本來就支持并行寫入，因此無需快照隔離。其實(shí)這個(gè)差異也是由于兩者不同的更新方式導(dǎo)致的，因?yàn)殛?duì)列 Append-Only 的方式保證了并發(fā)寫入也不會(huì)導(dǎo)致數(shù)據(jù)丟失，而文件則不然。 通過上述的分析，相信不少讀者已經(jīng)隱約感覺到：基于文件的存儲(chǔ)類似流表二象性中的表，適合用于保存可以被查詢的可變狀態(tài)（計(jì)算的最終結(jié)果或中間結(jié)果），而基于隊(duì)列的存儲(chǔ)類似表示流表二象性中的流，適合用于保存被流計(jì)算引擎讀取的事件流（Changelog 數(shù)據(jù)）。 雖然流表二象性能使得兩者可以交替使用，但若使用不當(dāng)會(huì)導(dǎo)致數(shù)據(jù)在流表兩種狀態(tài)間進(jìn)行不必要的轉(zhuǎn)換，并給下游業(yè)務(wù)造成額外的麻煩。具體來講，如果文件系統(tǒng)中存的是 Changelog 數(shù)據(jù)，那么下游進(jìn)行流式讀取（監(jiān)聽）時(shí)，讀到的是 Changelog 的 Changelog，完全不合理。相對(duì)地，如果消息隊(duì)列存的是非 Changelog 數(shù)據(jù)，那么該隊(duì)列則丟失了更新的能力，任何更新都會(huì)導(dǎo)致消息不同版本的同時(shí)存在。由于目前 Changelog 類型一般由 CDC 或者流計(jì)算的聚合、Join 產(chǎn)生，還未推廣到一般的 MQ 使用場景，所以后一種問題更常發(fā)生。但筆者認(rèn)為，Changelog 是更加流原生的格式，未來大概會(huì)標(biāo)準(zhǔn)化并普及到隊(duì)列存儲(chǔ)中，目前非 Changelog 的數(shù)據(jù)則可以被看作是 Append-Only 業(yè)務(wù)的特例。 上述的結(jié)論可以被應(yīng)用到當(dāng)前熱門的實(shí)時(shí)數(shù)倉建設(shè)中。除了 Lambda 架構(gòu)，當(dāng)前實(shí)時(shí)數(shù)倉架構(gòu)主要有 Kappa 架構(gòu)和實(shí)時(shí) OLAP 變體兩種[9]，無論哪種通常都使用 Kafka/Pulsar 等 MQ 作為 ODS/DWD/DWS 等中間層的存儲(chǔ)，OLAP 數(shù)據(jù)庫或 OLTP 數(shù)據(jù)庫作為 ADS 應(yīng)用層的儲(chǔ)存。這樣的架構(gòu)主要問題在于不夠靈活，比如若想直接基于 DWD 層做一些 Ad-hoc 分析，那么常要將 DWD 層 MQ 中的數(shù)據(jù)再導(dǎo)出到數(shù)據(jù)庫再做查詢。 可能有讀者會(huì)問，如果使用 Flink 直接讀 MQ 數(shù)據(jù)來算呢？其實(shí)是可以的，因?yàn)橄?Pulsar 也提供了無限期的存儲(chǔ)，但效率會(huì)比較低，主要原因是 MQ 無法提供索引來實(shí)現(xiàn)謂詞下推等優(yōu)化[10]，另外經(jīng)過聚合或者 Join 的數(shù)據(jù)是 Changelog 格式，數(shù)據(jù)流中會(huì)包含舊版本的冗余數(shù)據(jù)。因此業(yè)界有新的趨勢是用 Iceberg 等數(shù)據(jù)湖來代替 MQ 作為數(shù)倉中間層的存儲(chǔ)，這樣的優(yōu)點(diǎn)是能比較好地對(duì)接離線數(shù)倉及其長久以來的業(yè)務(wù)模式，而代價(jià)則是數(shù)據(jù)延遲可能變?yōu)榻鼘?shí)時(shí)。以本文 “文件適合存儲(chǔ)狀態(tài)” 的觀點(diǎn)來講，實(shí)時(shí)數(shù)倉中需要被業(yè)務(wù)查詢的表的確更適合用文件存儲(chǔ)，因?yàn)闃I(yè)務(wù)需要的是狀態(tài)，而不關(guān)心變更歷史。 3.在離線混部 在離線混部指的是將在線業(yè)務(wù)與大數(shù)據(jù)場景的實(shí)時(shí)、離線業(yè)務(wù)混合部署在相同的物理集群上，目的是提高機(jī)器的利用率。由于歷史原因，在線業(yè)務(wù)和大數(shù)據(jù)業(yè)務(wù)的技術(shù)棧是相對(duì)獨(dú)立的，因而理所當(dāng)然地分開部署: 在線業(yè)務(wù)使用為 k8s/Mesos 代表的集群管理器，而大數(shù)據(jù)業(yè)務(wù)通常使用 Hadoop 生態(tài)原生的 YARN 作為集群管理器。然而隨著集群規(guī)模的擴(kuò)大，資源利用率不足的問題日益突顯，例如通常 CPU 平均占用不足 20%。解決問題的最佳辦法便是打破不同業(yè)務(wù)獨(dú)立集群的邊界實(shí)現(xiàn)混部，并利用業(yè)務(wù)資源的潮汐現(xiàn)象和優(yōu)先級(jí)進(jìn)行動(dòng)態(tài)的資源分配。實(shí)際上很多公司在離線混部已經(jīng)有多年的探索，而最近一兩年 k8s 的迅猛發(fā)展大大加速了業(yè)務(wù)（包括大數(shù)據(jù)）上云的進(jìn)度，因而在離線混部再次成為熱點(diǎn)。 在離線混部技術(shù)的難點(diǎn)主要是統(tǒng)一集群管理器、資源隔離和資源調(diào)度這幾點(diǎn)，下文逐點(diǎn)展開。 首先，統(tǒng)一在離線的集群管理器是混部的基礎(chǔ)。目前大多數(shù)公司是 k8s 與 YARN 并存的狀態(tài)，但在云原生的大趨勢下，大數(shù)據(jù)組件也逐步對(duì) k8s 提供頭等的支持，看起來 k8s 一統(tǒng)集群資源只是時(shí)間問題。不過 k8s 的要做到這點(diǎn)也絕非一路平坦，一是 k8s 的一級(jí)調(diào)度設(shè)計(jì)并不能很好地滿足很多批計(jì)算作業(yè)的復(fù)雜調(diào)度，二是 k8s 當(dāng)前能掌控的集群規(guī)模一般在 5000 節(jié)點(diǎn)左右，比起 YARN 差了一個(gè)量級(jí)[11]。因此在當(dāng)前階段，業(yè)界大多是選擇 YARN on k8s 的方式來漸進(jìn)式地遷移。常見的做法是在 k8s pod 里啟動(dòng) NM，讓 YARN 部分 NM 節(jié)點(diǎn)運(yùn)行在 k8s 上。 然后，資源隔離是混部的核心。雖然 k8s 提供資源管理，但是僅限于 CPU、內(nèi)存兩個(gè)維度，而網(wǎng)絡(luò)和磁盤 IO 卻暫未納入考慮[12]。這對(duì)于在混部大數(shù)據(jù)業(yè)務(wù)而言顯然是不夠的，因?yàn)榇髷?shù)據(jù)業(yè)務(wù)可以很輕松地將機(jī)器的網(wǎng)絡(luò)或磁盤打滿，嚴(yán)重影響在線業(yè)務(wù)。要達(dá)到生產(chǎn)的資源隔離，通常需要 Linux 內(nèi)核級(jí)別的支持，這超出本文的范圍和筆者的知識(shí)儲(chǔ)備，不再詳述。 最后，資源調(diào)度是服務(wù)質(zhì)量的保證。調(diào)度器需要考慮物理節(jié)點(diǎn)的資源異構(gòu)、同類業(yè)務(wù)充分打散分布和業(yè)務(wù)的部署偏好來優(yōu)化調(diào)度，優(yōu)化效率并最大程度避免相互干擾。此外，集群調(diào)度器會(huì)按照優(yōu)先級(jí)來進(jìn)行資源超發(fā)。在業(yè)務(wù)低峰期，空閑的資源可以用于跑優(yōu)先級(jí)低、延遲不敏感的離線作業(yè)，然而在業(yè)務(wù)出現(xiàn)突發(fā)流量或發(fā)現(xiàn)在線作業(yè)受到離線作業(yè)干擾時(shí)，集群調(diào)度器需要快速讓離線作業(yè)退出并讓出資源。 4.HTAP HTAP 全稱是 Hybrid Transactional Analytical Processing (混合事務(wù)分析處理)，即同時(shí)支持在線事務(wù)查詢和分析查詢。前文所說的計(jì)算和存儲(chǔ)的流批一體是實(shí)時(shí)和離線技術(shù)棧上的融合，在離線混部是大數(shù)據(jù)業(yè)務(wù)與在線業(yè)務(wù)運(yùn)維管理上的融合，而 HTAP 就是最終的大數(shù)據(jù)和在線業(yè)務(wù)技術(shù)棧上的融合。自 2014 年 Gartner 提出該概念后，HTAP 成為了數(shù)據(jù)庫領(lǐng)域最為熱門的方向。除了簡化 OLTP 和 OLAP 兩套技術(shù)棧的復(fù)雜架構(gòu)外，HTAP 還有一個(gè)重要的需求背景: 隨著數(shù)據(jù)場景從企業(yè)內(nèi)部決策支持，到用作為線上增值服務(wù)的算法模型輸入（比如推薦、廣告），再到直接作為面向用戶的數(shù)據(jù)服務(wù)（比如淘寶生意參謀、滴滴行車軌跡等），OLTP 和 OLAP 的邊界正變得越來越模糊。 HTAP 從架構(gòu)來看分為兩類: 單系統(tǒng)同時(shí)服務(wù)于 OLTP 和 OLAP，或有兩套系統(tǒng)分別服務(wù)于 OLTP 和 OLAP。現(xiàn)在業(yè)界比較熱門的 TiDB、OceanBase 和 Google 的 F1 Lightning 都屬于后者。在這類系統(tǒng)中，OLTP 和 OLAP 分別有獨(dú)立的存儲(chǔ)和計(jì)算引擎，并依靠內(nèi)建的同步機(jī)制來將 OLTP 系統(tǒng)中的行存數(shù)據(jù)同步到 OLAP 系統(tǒng)轉(zhuǎn)為適合分析業(yè)務(wù)的列存數(shù)據(jù)。在此之上，查詢優(yōu)化器對(duì)外提供統(tǒng)一的查詢?nèi)肟冢瑢⒉煌愋偷牟樵兎謩e路由到合適的系統(tǒng)中。 比起傳統(tǒng)的基于 Hadoop 生態(tài)的數(shù)據(jù)倉庫，HTAP 的優(yōu)點(diǎn)是： 內(nèi)置可靠的數(shù)據(jù)同步機(jī)制，避免建立 OLTP 庫到數(shù)據(jù)倉庫的復(fù)雜 ETL 管道，同時(shí)也提高了數(shù)據(jù)一致性（比如 TiDB 和 F1 Lightning 都提供與 OLTP 一致的可重復(fù)讀一致性）。 對(duì)用戶友好的統(tǒng)一查詢接口，屏蔽了底層引擎的復(fù)雜性，大大降低了 OLAP 的門檻。這使得在有授權(quán)的情況下，線上業(yè)務(wù)團(tuán)隊(duì)能利用 OLAP 進(jìn)行輕量級(jí)數(shù)據(jù)分析，而數(shù)據(jù)分析團(tuán)隊(duì)也能利用 OLTP 進(jìn)行快速的點(diǎn)查。 數(shù)據(jù)安全性更有保障。將數(shù)據(jù)在不同組件間移動(dòng)容易造成權(quán)限不一致和安全漏洞，而 HTAP 可以復(fù)用 OLTP 的數(shù)據(jù)權(quán)限和避免數(shù)據(jù)跨組件訪問來避免這些問題。 雖然 HTAP 的愿景非常美好，但要構(gòu)建經(jīng)得起業(yè)務(wù)檢驗(yàn)的 HTAP 系統(tǒng)并不容易。數(shù)據(jù)庫和大數(shù)據(jù)領(lǐng)域先后有多次嘗試，不過目前算得上成功的案例屈指可數(shù)，其主要難點(diǎn)在于： OLTP 和 OLAP 資源的隔離。由于 OLAP 常包含一些資源密集的復(fù)雜查詢，OLTP 和 OLAP 公用的組件很容易產(chǎn)生資源競爭，從而干擾優(yōu)先級(jí)更高的 OLTP 查詢。在早些年的案例中，共享計(jì)算和存儲(chǔ)的 HTAP 都不能獲得很好的效果，因此最近的 HTAP 數(shù)據(jù)庫都在硬件級(jí)別進(jìn)行兩者負(fù)載的隔離，也就是獨(dú)立的存儲(chǔ)和計(jì)算。 數(shù)據(jù)同步機(jī)制如何確保數(shù)據(jù)一致性和新鮮度（freshness）。不同于基于 Hadoop 的數(shù)據(jù)倉庫通常允許小時(shí)級(jí)別的數(shù)據(jù)延遲和不一致窗口，HTAP 通常承諾強(qiáng)一致性以保證一個(gè)查詢無論被路由到 OLTP 系統(tǒng)還是 OLAP 系統(tǒng)都能獲得一致結(jié)果，這對(duì)數(shù)據(jù)同步機(jī)制的性能和容錯(cuò)性都提出很高的要求。目前在 HTAP 領(lǐng)域稱得上 State of the art 的兩個(gè)數(shù)據(jù)庫里，F(xiàn)1 Lightning 使用無入侵的 CDC 方式進(jìn)行同步，TiDB 基于 Raft 算法進(jìn)行數(shù)據(jù)復(fù)制。前者松耦合，但實(shí)現(xiàn)比較復(fù)雜；后者更加簡潔優(yōu)雅，但會(huì)受 OLTP 設(shè)計(jì)的約束，比如復(fù)制的數(shù)據(jù)塊大小需要與 OLTP 一致[16]。 淺談大數(shù)據(jù)的過去、現(xiàn)在和未來 如何利有機(jī)結(jié)合 OLTP 和 OLAP 工作負(fù)載。目前的 HTAP 像同一個(gè)門面后的兩套獨(dú)立系統(tǒng)，一個(gè)查詢要么交給 OLTP 處理，要么交給 OLAP 處理，并沒有產(chǎn)生 1 + 1 > 2 的化學(xué)反應(yīng)。IBM 指出，真正的 OLAP 是在同一個(gè)事務(wù)里高效地處理 OLTP 和 OLAP 兩種工作負(fù)載[15]。要做到這點(diǎn)，靠數(shù)據(jù)同步的 HTAP 架構(gòu)大概難以做到，需要從分布式事務(wù)算法層面來解決。 盡管 HTAP 還未被廣泛應(yīng)用，但可以預(yù)見未來將在很大程度上影響數(shù)據(jù)倉庫架構(gòu)。在數(shù)據(jù)規(guī)模不大、分析需求簡單的場景下，HTAP 將成為最為流行的解決方案。 03、未來：回歸本質(zhì) “融合” 是大數(shù)據(jù)當(dāng)前發(fā)展的大勢，這點(diǎn)從歷史的發(fā)展規(guī)律角度可以窺見其必然性。對(duì)于新出現(xiàn)的技術(shù)挑戰(zhàn)，在最初的探索期各類解決方案總是層出不窮，其中采用 Greenfield 方式的解決方案可能會(huì)將已有的基礎(chǔ)推倒重來，相比原有技術(shù)帶來一定的退化（Regression）。退化限制了新技術(shù)的應(yīng)用場景，導(dǎo)致新舊兩種技術(shù)的雙軌制，但只要核心功能沒有太大變化，這樣的割裂這往往只是暫時(shí)的。 回顧大數(shù)據(jù)的發(fā)展歷史，“大數(shù)據(jù)” 一詞原本用于描述數(shù)據(jù)規(guī)模、多樣性和處理性能給數(shù)據(jù)管理帶來的挑戰(zhàn)，而后續(xù)被用于描述為處理這類問題而構(gòu)建的數(shù)據(jù)系統(tǒng)，即 “大數(shù)據(jù)系統(tǒng)”。由于這類系統(tǒng)基于與傳統(tǒng)數(shù)據(jù)不同的基礎(chǔ)構(gòu)建，并舍棄后者標(biāo)配的事務(wù)特性，導(dǎo)致難以應(yīng)用到線上業(yè)務(wù)，通常只用于數(shù)據(jù)倉庫、機(jī)器學(xué)習(xí)等對(duì)數(shù)據(jù)延遲、數(shù)據(jù)準(zhǔn)確性要求稍微低一點(diǎn)的場景，而這類業(yè)務(wù)場景又逐漸被稱為 “大數(shù)據(jù)業(yè)務(wù)”。 然而，大數(shù)據(jù)技術(shù)本質(zhì)是數(shù)據(jù)密集型的分布式系統(tǒng)，而隨著分布式系統(tǒng)的發(fā)展和普及，大數(shù)據(jù)系統(tǒng)在功能特性和業(yè)務(wù)場景的限制終將被打破，與新出現(xiàn)的以 Spanner 為代表的 NewSQL 分布式數(shù)據(jù)庫并無明顯界限。屆時(shí)，”大數(shù)據(jù)” 一詞也許會(huì)和很多 buzzword 一樣逐漸消失在歷史的長河，回歸到通用的分布式系統(tǒng)的本質(zhì)。水平擴(kuò)展、優(yōu)秀容錯(cuò)性、高可用的分布式特性將成為各種系統(tǒng)的標(biāo)配，無論在 OLTP 或者 OLAP 場景。