前言

大數據開發的日常工作中，開發人員經常需要使用 Spark、Flink 等計算引擎作為工具來實現一些 業務邏輯 的計算。

以 Spark 為例，開發人員會使用 SparkSQL、DataFrame、RDD 等不同形式的API來實現業務需求。

通常情況下，簡單的需求都可以通過 SparkSQL、DataFrame 很方便的實現，其簡潔的API也是其深受數據分析師青睞的原因之一。

但是正是因為 SparkSQL、DataFrame 的高層次封裝，在 複雜度較高的計算需求 實現中，可能會出現 實現複雜或者API的功能性無法滿足，或者千方百計實現需求之後 性能表現低下，代碼段複雜而龐大 的情況。

儘管Spark允許開發人員通過UDF、UDAF等形式提供自定義的函數功能，但是此時很多人會選擇使用較為底層的RDD接口進行開發：可控性好、開發與調試方便、性能強勁。

但是使用RDD接口來開發業務需求時，很多小的項目團隊並沒有一個統一的項目規範，需求開發完全由開發人員個人自己發揮。

各個業務項目的大致流程基本是相同的：

1. 創建SparkSession
2. 用 spark.table or spark.textFile 等API讀取數據源
3. 進行RDD的各種 Transformation 和 Action 操作
4. 得到數據結果之後再調用 saveAsTable or saveAsTextFile 寫入外部數據源中

雖然看起來流程挺一致的，但是其中仍然存在以下問題：

• 業務代碼混亂
• 團隊成員代碼風格不一，有的喜歡一長串一長串的寫，有的喜歡將過程封裝
• 即使將過程封裝了，但是封裝的邊界沒有明確定義，仍然會有人不小心“越界”
• 讀寫數據源的API使用不統一
• 各個計算引擎對各個數據源都有不同的讀寫API接口提供使用，一些比較繁雜的API可能會被人“錯誤”使用
• 同時也會有人時常忘記對應接口如何使用，反覆查閱資料
• 重複的編碼工作
• 理論上所有業務項目，除了業務邏輯是變化的之外，其餘應該都是一個不變的模板
• 開發人員應該專註於變化的業務邏輯，而不是每次都要分一些精力出來處理其他“邊邊角角”的事情

沒有規範任由團隊成員發揮的話，儘管有些成員能寫一手漂亮的代碼，但是你並不能保證所有人都這麼優秀。

時間一久項目中代碼的 壞味道 會越來越多，最後混亂的程度可能會超出你的想象。

為了解決以上問題，我們建議：定義一個項目規範，所有業務項目都需要遵守這個規範。

俗話說，有規矩成方圓。

有了項目規範，所有人都遵守這個標準來開發。

有了這個標準，我們就可以在標準化的基礎上做很多事情，比如 定義自動化工具來幫助開發人員解放雙手。

本文討論的項目規範可以作為一種參考，以供讀者與相關開發人員翻閱。

一、項目規範

和Java項目規範類似，以 模塊化項目 的結構來定義項目規範可以為業務項目提供 結構化標準，其可以規整所有 混亂的業務項目結構。

項目結構標準化的重要性：

• 項目統一管理與生成
• 方便快速搭框架
• 所有開發人員遵守相同的編碼規範
• 易於交接與維護

以下模塊劃分和Java項目類似，略微有些細節差異。

1.1 api模塊

業務計算邏輯模塊，不應該出現任何 Spark等執行框架的API 以 保持模塊獨立性與可移植。

理論上該模塊可以獨立構成一個單機程序執行，這樣可以將最重要的業務邏輯根據需要遷移到任意計算引擎中，如 Spark 到 Spark Streaming、Flink 甚至 Hive UDF 等。

• 對外只提供接口調用，不可直接在外部實例化具體類（工廠模式）
• 所有service業務邏輯需要有對應的測試用例
• 事務控制、所有異常捕獲和處理
• 依賴common

1.2 common模塊

項目內通用的常量、枚舉、POJO實體類、工具函數等，視情況分離，可集成到 context 中

• 不包含任何業務邏輯
• 不依賴其他模塊
• 相關工具保持單例

1.3 context模塊

Spark或者其他程序 執行入口，負責初始化各種計算引擎的環境變量。

• 系統 全局配置（conf）與腳本（bin） 集中管理
• 依賴server、api、common
• 程序關鍵點需要打印日誌以便後續debug使用

1.4 server模塊

整個項目中整合了業務邏輯調用、數據源讀寫等操作的模塊，需求簡單的情況下可以直接集成到 context 中。

該模塊中根據不同的接口操作類，還劃分了 dal、service與manager三個包。

1.4.1 dal包

主要是對數據進行操作，如讀寫常用的庫：Hive、MySQL、HBase；以及讀寫文件系統：HDFS。

dal中的所有使用都由接口來定義，不同的接口實現使用不同的應用框架API，如Spark、Flink應該為兩個獨立的dal實現，在後續service使用過程中可以自由切換。

需要遵循以下原則：

• 所有bean對象，定義在dal
• 不得在dal寫各種業務邏輯、數據清洗邏輯
• 一張表對應一個dal接口、一個bean，對應多個獨立的dao實現
• 不允許在1個dao中同時操作多個表

包結構如下：

• basic: basic包下主要放一些基礎對象，如BaseDao，所有dao都需要完善 TABLE_NAME
• bean: 定義數據源表結構，不同的數據源可以定義在不同的包中，如hive、hbase、mysql等
• dao: 接口具體實現，用來操作數據表。如：增刪改查

1.4.2 service包

和dao對接，一個service對應一個dao，service的使用都由接口來定義。

一個service下有兩個實現包：

• 正常實現包：直接對接dao，簡單處理一些判斷：如參數不合法校驗等。
• 測試實現包：模擬數據，可以不通過dao獲取，從本地文件生成或代碼中生成。

不同的計算框架有不同的service實現，如spark、flink等（需要傳入其環境變量）。

1.4.3 manager包

• 調用service包實現數據增刪改查
• 調用api模塊進行業務邏輯組合
• 提供函數接口給context模塊調用執行

二、代碼框架

基於以上項目模塊的劃分，我們可以看到，api、common是 每次都會變化的業務邏輯和通用屬性的抽取，而 context 是根據業務需要的計算引擎和運行環境設置的 執行入口。

以上三個模塊都是 根據業務需求變化比較大的，而server模塊則是負責對 其他各個模塊的調用與整合，最後通過 manager 提供統一的函數接口給 context 入口調用執行。

所以 server 模塊是這個項目規範中可以 自動化 起來的重點目標。

基於這個目標，我們開發了一個 大數據業務開發 基準項目的雛形，開發人員能夠做到開箱即用，不必再花太多精力在研究計算引擎與各個數據源的接口和API如何調用，專註於業務邏輯的實現，提升開發效率。

項目地址：
https://github.com/chubbyjiang/aisql-bigdata-base

使用介紹

org.aisql.bigdata.base.framework 包中提供了幾種常見大數據項目需要用到的數據源。

framework 以 模塊化項目 的結構提供了 各個數據源基礎的Dao、Service接口與默認實現。

配合自動化的代碼生成工具，可以一鍵生成 server 模塊的代碼文件直接使用。

現在我們來看一下規範+自動化的威力，例如現有 default.t_users 表需要讀取。

開發人員僅需要生成代碼文件並複製到項目中，寫代碼如下：

val service = new UsersService
//讀取整個表
val allRdd:RDD[Users] = service.selectAll()
//字段篩選
val allRdd:RDD[Users] = service.selectAllWithCols(Seq("name","age"))
//條件過濾
val allRdd:RDD[Users] = service.selectAllByWhere("age>10")
//讀取1000條數據
val demoRdd:RDD[Users] = service.selectDemo()
//寫入表
service.insertInto(demoRDD)
service.createTable(demoRDD)

是不是 so easy？

其實所做的內容也就是在 server 模塊中封裝了 常用的不同計算引擎對不同數據源的讀寫操作API，並 自動化了 bean、dal、service 三個部分的代碼生成。

使得開發人員可以直接使用 service 提供的數據操作接口 讀出數據源 後 調用業務計算邏輯 處理完畢後 寫入數據源 中。

通過對項目模塊的標準化規範，我們可以以一個 比較統一和簡單易懂的開發方式 來進行需求落地。

雖然剛開始使用規範的時候會有人覺得繁瑣與不耐煩，如果是手動開發的話誰都會煩，都是一些重複性的苦力活兒，這就是框架規範的缺點：特別繁瑣。

但是配套做一些自動化工具來使用的話，相信大部分開發人員都會覺得很酸爽，某種程度上標準化項目就是這麼來提升開發效率的。