數據中臺技術的利與弊

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

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

經常使用架構以下：

▪︎  Serverless 架構：

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

▪︎  Event-Driven 架構：

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

▪︎  Microservices 架構：

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

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

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

Java8 引入了 Lambda 表達式和流，對許多從事數據開發人員來講很是有吸引力，但硬編碼須要很長時間，而且因爲人爲因素可能產生錯誤的重複性工做，浪費大量時間。爲了使這個過程更加簡便並減小錯誤數量，藉助成熟的計算框架和 DSL 語言逐漸成爲了主流。

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

	A	B
1	[mysql1,mysql2,mysql3,mysql4]
2	fork A1	=connect(A2)
3		=B2.query@x("select   product_no,sum(allDuration) sallDuration,sum(allTimes)   sallTimes,sum(localDuration) slocalDuration ,sum(localTimes) slocalTimes from   userService where I0419=? group by product_no", argType)
4	=A2.conj()
5	=A4.groups(product_no;sum(sallDuration):ad,sum(sallTimes):at,sum(slocalDuration):ld,sum(slocalTimes):lt)

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

引入中間計算層，將位於多個數據庫的 userService 數據合併彙總。多線程並行不只大幅提高了性能，用 SPL 腳原本實現也更加容易，Java 調用 SPL 也很方便。若是上述計算動做用硬編碼實現，多線程、數據合併再二次彙總，工做量將很是巨大。

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