數據中臺技術的利與弊

伴隨信息時代的發展，新技術、新框架、新語言層出不窮，解決問題的技術視角其實從來沒有改變。所有應用都需要和存儲系統相關聯，無論存儲是 SQL 還是 NOSQL 的。業務系統和數據庫遵循不同的開發規范，為了讓開發更容易，有一類框架專門幫助解決從應用層到數據庫的轉換，著名的 ORM 類框架就是其中之一。實際上數據中臺技術主要面臨的挑戰主要也是計算服務和各種數據存儲如何便捷的統一起來，并通過服務化 API 和前臺業務層對接。

當我們討論中臺應用程序時，先理清包括設計和體系結構在內的一些方法，會更容易認識設計思想的本質。體系結構是處理靈活性，可伸縮性，可用性，安全性以及其他直接與業務視角相關的結構設計。

常用架構如下：

??? Serverless 架構：

Serverless 體系結構是包含第三方“后端即服務”（BaaS）服務的應用程序設計，包括在“功能即服務”（FaaS）平臺上以托管、臨時容器運行的自定義代碼。

??? Event-Driven 架構：

Event-Driven 體系結構模式，是基于事件促成生成、檢測、消費和響應。

??? Microservices 架構：

它是面向服務的體系結構（SOA）的一種變體，將應用程序構建為松散耦合的服務的集合。 在微服務架構中，服務是細粒度的，協議是輕量級的。

中臺應用程序會涉及與多個系統的多個集成，所以從程序的工程角度，應使用古老的羅馬策略：分而治之，將復雜性分解為小塊，此外，應可擴展，自由使用實現方式達成目標結果，不拘泥于簡單的實現手段。

這里的挑戰是應用開發和數據開發都有不同各自數據對象和處理方式，應用開發是 OOP、函數式編程，常規集合、key-value 數據，數據開發則需要反復處理動態結構數據和復雜的關聯運算。因此，從系統結構的角度來看，需要應用開發和數據開發之間的轉換器。

Java8 引入了 Lambda 表達式和流，對許多從事數據開發人員來說非常有吸引力，但硬編碼需要很長時間，并且由于人為因素可能產生錯誤的重復性工作，浪費大量時間。為了使這個過程更加簡便并減少錯誤數量，借助成熟的計算框架和 DSL 語言逐漸成為了主流。

舉例說明，以集算器為例，腳本如下：

某電信企業用庫表 userService 存儲用戶服務信息，T+0 查詢需要呈現各類電信產品的通話時長、通話次數、撥打本地時長、撥打本地次數。實際使用中發現數據量太大，查詢效率很低，導致前端顯示很慢。

引入中間計算層，將位于多個數據庫的 userService 數據合并匯總。多線程并行不僅大幅提升了性能，用 SPL 腳本來實現也更加容易，Java 調用 SPL 也很方便。如果上述計算動作用硬編碼實現，多線程、數據合并再二次匯總，工作量將非常巨大。

使用中臺計算組件是一個很好的策略，它去適配各類 SQL、NOSQL、大數據平臺，使用一致的結構化數據模型 / 語法進行開發，對外提供通用接口和標準結果集，應用可以根據自身需要繼續封裝和對外提供服務。中臺計算組件最好具備數據緩存特性，不會在大量訪問時，直接對存儲系統產生影響。從維護角度，它可以方便地修改計算邏輯而不會影響其他代碼，不斷優化算法和利用緩存，這對其他開發人員和存儲系統維護人員來說都是最愿意看到的方式。但由于向開發方面增加了一層，因此破壞了簡單性。