數據開發技術的3個方向

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

一、流批一體成為主流開發模式

先說說我看到的數據開發的歷史。

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

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

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

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

實時、離線的存儲統一

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

實時、離線的代碼統一

實時和離線代碼被統一為一份，通過調度設置來區分是實時還是離線批處理。這個階段存在兩個挑戰。

第一個挑戰是對計算引擎的，需要實時計算引擎兼具批任務執行能力，且做到流批 API 的統一，這塊能力在 Flink Roadmap 里，Blink當前已經支持的不錯。

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

二、代碼自動化技術走向成熟

代碼自動化，有兩個方向，一是代碼的自動生成，二是代碼的自動優化。

代碼的自動生成

數倉模型設計的實施工作流包含業務和需求調研，架構設計，規范定義，數據建模四個過程。

架構設計指以維度建模為理論基礎，基于業務和需求調研的結果，進行整體數倉設計，包含確定數據域，定義每個數據域下面的業務過程及相關維度兩件事情； 規范定義指定義指標體系，包括原子指標，業務限定如修飾詞、時間周期，以及派生指標，由原子指標和業務限定組合而成； 數據建模主要包括維度及屬性的規范定義，維表、明細事實表和匯總事實表的模型設計。

現在已經有數據研發平臺可以做到可視化數據模型設計：配置化定義維度、業務過程和事實表元數據，自動生成維表和事實表；可視化關聯字段的原子指標和業務限定，配置化定義派生指標口徑，自動生成匯總表。整個模型設計過程代碼是自動生成的，當然，一些復雜指標計算邏輯是通過代碼片段的形式作為配置項提交。

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

大家有興趣可以了解下阿里的 Dataphin 產品。

代碼的自動優化

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

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

三、OLAP Cubes 終將衰落

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

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

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

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

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

數據應用的契機

數據應用端的兩個發展趨勢一定程度上可以解決上述潛在問題。

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

概括來說，就是使用可視化分析工具替代取數 SQL 開發，產品化構建交互式分析場景替代集市主題表建設。

數據開發從業者的3個核心能力

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

1、能深入理解你所服務的業務

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

2、有把數據做深的能力

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

3、具備數據鏈路的全局觀

數據鏈路的全局觀不僅僅是清楚整個數據架構是什么樣子，熟悉數據是如何流轉的，更是能做數據鏈路的全局優化。如整個數據鏈路的穩定性保障，數據資產的組織和管理機制設計，數據的全鏈路價值評估、成本治理，數據的質量管理及測試、監控機制的建設等。