2021年大數(shù)據(jù)開發(fā)發(fā)展趨勢

未來數(shù)據(jù)開發(fā)技術(shù)方向，我認(rèn)為有三個，首先是流批一體成為主流開發(fā)模式，其次是代碼自動化技術(shù)走向成熟，第三是 OLAP Cubes 終將衰落。

一、流批一體成為主流開發(fā)模式

先說說我看到的數(shù)據(jù)開發(fā)的歷史。

1. “遠(yuǎn)古”時代，通過寫 SQL 腳本抽取 OLTP 數(shù)據(jù)庫中數(shù)據(jù)進行分析和統(tǒng)計，大量查詢有可能把數(shù)據(jù)庫拖掛；
2. OLAP 分析成為數(shù)據(jù)庫的一項重要能力，這個時候，可以寫 SQL，也可以寫Python 代碼等來進行數(shù)據(jù)分析和統(tǒng)計，但面對不斷增長的數(shù)據(jù)量，數(shù)據(jù)庫性能遇到挑戰(zhàn)；
3. Hadoop 技術(shù)的引入和不斷成熟，海量數(shù)據(jù)的離線存儲、計算和調(diào)度問題得到解決；
4. Storm 讓海量數(shù)據(jù)的實時計算成為可能，促進了一大批實時數(shù)據(jù)產(chǎn)品的出現(xiàn)，也促進了 Lambda數(shù)據(jù)架構(gòu)的出現(xiàn)和流行；
5. Kafka、Spark、Flink 等技術(shù)的流行，整個數(shù)據(jù)鏈路的全流式計算成為可能，Kappa 架構(gòu)出現(xiàn)和流行。

從單機 OLAP 到 Lambda 到Kappa 的演進，數(shù)據(jù)鏈路上的問題、數(shù)據(jù)計算層面的問題得到了很好解決。那未來一切皆流式，一切皆實時是否可行？是否經(jīng)濟？我們的數(shù)據(jù)架構(gòu)還存在什么問題？列舉幾個數(shù)據(jù)領(lǐng)域常見的問題：

• 數(shù)據(jù)產(chǎn)品實時和離線模塊同一指標(biāo)數(shù)值不同，因為指標(biāo)計算離線、實時是單獨開發(fā)，單獨存儲的，口徑有差異；
• 同一口徑的數(shù)據(jù)指標(biāo)，需要離線和實時各開發(fā)一份代碼，因為彼此的計算引擎不同，編程范式不同，即使都用 SQL 編寫，也很難完全復(fù)用；
• 離線數(shù)倉和實時數(shù)倉彼此獨立存在，帶來雙重的存儲和維護成本，因為離線和實時任務(wù)有不同的數(shù)倉分層及存儲體系。

要解決這些問題，需要實時和離線計算的融合，稱作流批一體架構(gòu)。這里說的融合不是用實時計算替代所有離線計算，離線和實時計算有各自適用的場景，而是對于數(shù)據(jù)的下游應(yīng)用來說，不用去關(guān)注數(shù)據(jù)來自實時還是離線，對于數(shù)據(jù)開發(fā)工程師來說，不用去關(guān)注開發(fā)的是實時還是離線代碼，實時、離線只是調(diào)度層面的概念。融合過程根據(jù)現(xiàn)狀的不同可以分兩個階段，第一是存儲統(tǒng)一，第二是代碼統(tǒng)一。

實時、離線的存儲統(tǒng)一

這個階段，實時和離線任務(wù)還是單獨開發(fā)和執(zhí)行的，但不再區(qū)分存儲介質(zhì)，比如常見的離線結(jié)果存 MySQL，實時結(jié)果存 HBase 方案，改成統(tǒng)一存儲到海量數(shù)據(jù)高頻讀寫皆優(yōu)的存儲計算引擎，如 Apache Kudu & Impala，Alibaba Hologres 等。存儲統(tǒng)一可以解決下游應(yīng)用需要通過不同邏輯對接實時、離線數(shù)據(jù)的問題，例如統(tǒng)一后，同一張表取當(dāng)天的數(shù)據(jù)就是截止目前為止的實時數(shù)據(jù)，取昨天的數(shù)據(jù)，就是 T-1 的離線數(shù)據(jù)。另外，也為后續(xù)第二階段的代碼統(tǒng)一做了鋪墊，因為已經(jīng)做到實時、離線統(tǒng)一存儲，代碼統(tǒng)一過程對下游是無感知的。

實時、離線的代碼統(tǒng)一

實時和離線代碼被統(tǒng)一為一份，通過調(diào)度設(shè)置來區(qū)分是實時還是離線批處理。這個階段存在兩個挑戰(zhàn)。

• 第一個挑戰(zhàn)是對計算引擎的，需要實時計算引擎兼具批任務(wù)執(zhí)行能力，且做到流批 API 的統(tǒng)一，這塊能力在 Flink Roadmap 里，Blink當(dāng)前已經(jīng)支持的不錯。

• 第二個挑戰(zhàn)是對數(shù)倉架構(gòu)的，實時和離線數(shù)倉需要統(tǒng)一，存在兩個問題:（1）新流批一體任務(wù)如何和所替代的老的離線任務(wù)保持統(tǒng)一的上游依賴？這個問題在存儲、計算分離的計算平臺架構(gòu)下比較容易解決，打通元數(shù)據(jù)，不同計算引擎訪問統(tǒng)一存儲；（2）流批一體任務(wù)依賴的上游任務(wù)可能未做流批一體，比如為了更精準(zhǔn)的反作弊，需要獨立開發(fā)離線任務(wù)通過長周期歷史數(shù)據(jù)做計算，即如何解決流批一體任務(wù)依賴雙重上游數(shù)據(jù)輸入的問題？這個問題可以通過對該上游任務(wù)的結(jié)果表在 Schema 層面做統(tǒng)一來解決，如構(gòu)建鏡像表，根據(jù)調(diào)度模式的不同來映射依賴上游哪份數(shù)據(jù)。

二、代碼自動化技術(shù)走向成熟

代碼自動化，有兩個方向，一是代碼的自動生成，二是代碼的自動優(yōu)化。

代碼的自動生成

數(shù)倉模型設(shè)計的實施工作流包含業(yè)務(wù)和需求調(diào)研，架構(gòu)設(shè)計，規(guī)范定義，數(shù)據(jù)建模四個過程。

• 架構(gòu)設(shè)計指以維度建模為理論基礎(chǔ)，基于業(yè)務(wù)和需求調(diào)研的結(jié)果，進行整體數(shù)倉設(shè)計，包含確定數(shù)據(jù)域，定義每個數(shù)據(jù)域下面的業(yè)務(wù)過程及相關(guān)維度兩件事情；
• 規(guī)范定義指定義指標(biāo)體系，包括原子指標(biāo)，業(yè)務(wù)限定如修飾詞、時間周期，以及派生指標(biāo)，由原子指標(biāo)和業(yè)務(wù)限定組合而成；
• 數(shù)據(jù)建模主要包括維度及屬性的規(guī)范定義，維表、明細(xì)事實表和匯總事實表的模型設(shè)計。

現(xiàn)在已經(jīng)有數(shù)據(jù)研發(fā)平臺可以做到可視化數(shù)據(jù)模型設(shè)計：配置化定義維度、業(yè)務(wù)過程和事實表元數(shù)據(jù)，自動生成維表和事實表；可視化關(guān)聯(lián)字段的原子指標(biāo)和業(yè)務(wù)限定，配置化定義派生指標(biāo)口徑，自動生成匯總表。整個模型設(shè)計過程代碼是自動生成的，當(dāng)然，一些復(fù)雜指標(biāo)計算邏輯是通過代碼片段的形式作為配置項提交。

代碼的自動生成除了提升開發(fā)效率外，還帶來額外的好處，因為計算代碼是動態(tài)生成的，匯總表是否生成真正的物理表，對用戶是透明的，平臺可以根據(jù)成本、性能、效率等的考慮，來動態(tài)決定是構(gòu)建物理表（也就是OLAP Cube），還是只是一個視圖，背后是直接下發(fā)查詢到事實明細(xì)表。

大家有興趣可以了解下阿里的 Dataphin 產(chǎn)品。

代碼的自動優(yōu)化

實時/離線計算引擎的不斷發(fā)展演進，越來越多人肉在做的優(yōu)化最佳實踐會被集成到引擎里，做到在線識別、自動優(yōu)化。

比如 Join 長尾（傾斜）問題，有一個優(yōu)化方式是把熱點數(shù)據(jù)提取出來，然后拆分任務(wù)，用大小表的 mapjoin 機制來提速；比如 count distinct 傾斜問題，可以基于熱點字段做數(shù)據(jù)的二次分發(fā)，將查詢拆成兩層，內(nèi)層子查詢基于二次分發(fā)的數(shù)據(jù)做聚合，外層查詢再按熱點字段聚合。后者已經(jīng)被 Flink partialAgg 機制所支持，開發(fā)人員使用普通SQL 開發(fā)任務(wù)即可。相信這些有規(guī)可循的優(yōu)化“套路“會越來越多地被集成到計算引擎中。

三、OLAP Cubes 終將衰落

OLAP Cube 又稱 Data Cube，工程實踐上是對（明細(xì)）數(shù)據(jù)表基于合適的維度組合（基于業(yè)務(wù)確定的維度組合或基于重要維度的笛卡爾積組合）做預(yù)先聚合計算，典型的計算機領(lǐng)域以空間換時間案例。

這種預(yù)計算模式，通過為下游應(yīng)用提供穩(wěn)定的查詢性能，長久來促進了數(shù)據(jù)倉庫的發(fā)展，我們通常說的集市層“百花齊放”，快速響應(yīng)業(yè)務(wù)訴求，指的就是 OLAP Cubes 的建設(shè)。數(shù)據(jù)倉庫建模理論，如 Kimball 的維度建模理論，本質(zhì)上就是解決如何基于業(yè)務(wù)的分析訴求，科學(xué)的定義數(shù)據(jù)倉庫中數(shù)據(jù)的組織方式，讓數(shù)據(jù)開發(fā)工程師更好更容易的構(gòu)建 OLAP Cubes。

技術(shù)的限制讓這種模式存在并流行，這種模式反過來又在塑造數(shù)據(jù)團隊的組織形式和職能，成為一種行業(yè)標(biāo)準(zhǔn)。做個假設(shè)，如果我們當(dāng)前擁有極為充足的計算能力，很便宜的內(nèi)存資源，還有能高效利用它們提供足夠優(yōu)秀查詢性能的數(shù)據(jù)庫，我們是否還需要花費大量人力基于明細(xì)數(shù)據(jù)去開發(fā)一個個應(yīng)用層匯總表來解決多樣的數(shù)據(jù)查詢訴求？

計算技術(shù)的成熟

• 第一個因素是摩爾定律，帶來了計算和存儲成本的不斷降低，公有云的高速發(fā)展，按需購買，按量付費的模式，進一步降低了數(shù)據(jù)的存儲和計算成本。
• 第二個因素是類MPP計算架構(gòu)，列存儲模式數(shù)據(jù)查詢引擎的技術(shù)突破和成熟，同等資源下，能提供成倍甚至幾十倍的查詢性能提升。

從技術(shù)上來看，停止建設(shè) OLAP Cubes，所有請求直連明細(xì)數(shù)據(jù)是可能的。但從業(yè)務(wù)上來看，所有的數(shù)據(jù)查詢請求直連明細(xì)數(shù)據(jù)，存在兩個潛在問題：1）查詢請求過于復(fù)雜，不易理解，且容易出錯；2）數(shù)倉匯總層會變得很薄，業(yè)務(wù)人員要從明細(xì)層取數(shù)，效率變低。

數(shù)據(jù)應(yīng)用的契機

數(shù)據(jù)應(yīng)用端的兩個發(fā)展趨勢一定程度上可以解決上述潛在問題。

• 第一個趨勢是BI工具的演化，從提供優(yōu)秀的報表制作及數(shù)據(jù)可視化能力，到兼具高級分析的”計算“能力。用戶不再需要費腦力去思考如何寫復(fù)雜的取數(shù) SQL，而是通過 BI 工具的拖拽可視化，以及簡單易用的計算字段配置來進行數(shù)據(jù)的分析和探索，如 YoY/MoM/DoD 對比、年/月/日匯總和趨勢分析、字段級聯(lián)組織和下鉆分析等，都是通過系統(tǒng)配置自動支持，不用寫 SQL。
• 第二個趨勢是交互式/對話式查詢在數(shù)據(jù)產(chǎn)品上的應(yīng)用越來越多。這類數(shù)據(jù)產(chǎn)品模式的目標(biāo)是提供更大的靈活性給用戶，數(shù)據(jù)產(chǎn)品不僅僅只是看數(shù)，而是用戶參與其中，定義自己的看數(shù)視角。以用戶行為轉(zhuǎn)化漏斗分析舉例，常規(guī)數(shù)據(jù)產(chǎn)品會首先根據(jù)業(yè)務(wù)訴求定義轉(zhuǎn)化過程重要節(jié)點，數(shù)據(jù)開發(fā)進行需求開發(fā)，然后通過數(shù)據(jù)的可視化展現(xiàn)服務(wù)用戶。而交互式分析模式首先是對轉(zhuǎn)化分析方式進行抽象：轉(zhuǎn)化漏斗分析是對漏斗窗口期內(nèi)，所有滿足限制條件的用戶行為，按既定步驟順序的轉(zhuǎn)化計算，以漏斗圖的可視化形式展現(xiàn)。產(chǎn)品模塊定義如下：1）漏斗名稱設(shè)置組件，2）漏斗窗口周期設(shè)置組件，3）漏斗步驟設(shè)置模塊，其中每項步驟包含用戶行為選擇和限制條件配置，4）漏斗圖展現(xiàn)組件。至于對哪些行為做分析，是否需要對該行為再做條件篩選，關(guān)聯(lián)多長時間的數(shù)據(jù)做時間序列追蹤等，交由用戶選擇，即席查詢。

概括來說，就是使用可視化分析工具替代取數(shù) SQL 開發(fā)，產(chǎn)品化構(gòu)建交互式分析場景替代集市主題表建設(shè)。

數(shù)據(jù)開發(fā)從業(yè)者的3個核心能力

前面講了數(shù)據(jù)開發(fā)技術(shù)的三個方向：1）流批一體成為主流開發(fā)模式，2）代碼自動化技術(shù)走向成熟，3）OLAP Cubes 終將衰落。對于數(shù)據(jù)開發(fā)從業(yè)者而言，在技術(shù)的發(fā)展中，如何持續(xù)保持個人競爭力，我認(rèn)為最重要的是如下三項能力。

1、能深入理解你所服務(wù)的業(yè)務(wù)

只有深入理解業(yè)務(wù)，才能真正知道當(dāng)前業(yè)務(wù)處在什么階段，碰到了什么問題，重點目標(biāo)是什么。對應(yīng)到企業(yè)的數(shù)據(jù)建設(shè)，一定要先解決“為什么”的問題，當(dāng)前數(shù)倉服務(wù)的業(yè)務(wù)現(xiàn)狀是什么，為了解決業(yè)務(wù)什么問題，期望達(dá)到什么目標(biāo)，這些是無法靠技術(shù)自動化解決的。然后才是模型設(shè)計、實施落地。

2、有把數(shù)據(jù)做深的能力

數(shù)據(jù)會被用來搭建一個個分析報表，服務(wù)一個個數(shù)據(jù)產(chǎn)品，好像數(shù)據(jù)產(chǎn)生后，就和數(shù)據(jù)開發(fā)從業(yè)者無關(guān)了，以至于從業(yè)者很多自嘲是“人肉SQL機器”，是“數(shù)據(jù)搬運工”，也經(jīng)常被合作方稱做“ETL工程師”。把數(shù)據(jù)做深的能力是指生產(chǎn)數(shù)據(jù)之外，能持續(xù)去思考從這些數(shù)據(jù)里能獲取什么，不管是通過數(shù)理統(tǒng)計還是機器學(xué)習(xí)，探索能否挖掘出推動業(yè)務(wù)增長的洞察，以及行動指引，是做“數(shù)據(jù)掘金者”。

3、具備數(shù)據(jù)鏈路的全局觀

數(shù)據(jù)鏈路的全局觀不僅僅是清楚整個數(shù)據(jù)架構(gòu)是什么樣子，熟悉數(shù)據(jù)是如何流轉(zhuǎn)的，更是能做數(shù)據(jù)鏈路的全局優(yōu)化。如整個數(shù)據(jù)鏈路的穩(wěn)定性保障，數(shù)據(jù)資產(chǎn)的組織和管理機制設(shè)計，數(shù)據(jù)的全鏈路價值評估、成本治理，數(shù)據(jù)的質(zhì)量管理及測試、監(jiān)控機制的建設(shè)等。

    

     掃描下方二維碼

    
    

     添加好友，備注【交流】
    
    

     可私聊交流，也可進資源豐富學(xué)習(xí)群
    

更文不易，點個“在看”支持一下??