1. 首頁 > 生活 > >

spark開發實戰pdf spark實戰項目案例

小知識spark開發實戰pdf



文章插圖
spark開發實戰pdf spark實戰項目案例

文章插圖
前言
大數據開發的日常工作中，開發人員經常需要使用 Spark、Flink 等計算引擎作為工具來實現一些 業務邏輯 的計算 。
以 Spark 為例，開發人員會使用 SparkSQL、DataFrame、RDD 等不同形式的API來實現業務需求 。
通常情況下，簡單的需求都可以通過 SparkSQL、DataFrame 很方便的實現，其簡潔的API也是其深受數據分析師青睞的原因之一 。
但是正是因為 SparkSQL、DataFrame 的高層次封裝，在 復雜度較高的計算需求 實現中，可能會出現 實現復雜或者API的功能性無法滿足，或者千方百計實現需求之后 性能表現低下，代碼段復雜而龐大 的情況 。
盡管Spark允許開發人員通過UDF、UDAF等形式提供自定義的函數功能，但是此時很多人會選擇使用較為底層的RDD接口進行開發：可控性好、開發與調試方便、性能強勁 。
但是使用RDD接口來開發業務需求時，很多小的項目團隊并沒有一個統一的項目規范，需求開發完全由開發人員個人自己發揮 。
各個業務項目的大致流程基本是相同的：
創建SparkSession用 spark.table or spark.textFile 等API讀取數據源進行RDD的各種 Transformation 和 Action 操作得到數據結果之后再調用 saveAsTable or saveAsTextFile 寫入外部數據源中
雖然看起來流程挺一致的，但是其中仍然存在以下問題：
業務代碼混亂團隊成員代碼風格不一，有的喜歡一長串一長串的寫，有的喜歡將過程封裝即使將過程封裝了，但是封裝的邊界沒有明確定義，仍然會有人不小心“越界”讀寫數據源的API使用不統一各個計算引擎對各個數據源都有不同的讀寫API接口提供使用，一些比較繁雜的API可能會被人“錯誤”使用同時也會有人時常忘記對應接口如何使用，反復查閱資料重復的編碼工作理論上所有業務項目，除了業務邏輯是變化的之外，其余應該都是一個不變的模板開發人員應該專注于變化的業務邏輯，而不是每次都要分一些精力出來處理其他“邊邊角角”的事情
沒有規范任由團隊成員發揮的話，盡管有些成員能寫一手漂亮的代碼，但是你并不能保證所有人都這么優秀 。
時間一久項目中代碼的 壞味道 會越來越多，最后混亂的程度可能會超出你的想象 。
為了解決以上問題，我們建議：定義一個項目規范，所有業務項目都需要遵守這個規范 。
俗話說，有規矩成方圓 。
有了項目規范，所有人都遵守這個標準來開發 。
有了這個標準，我們就可以在標準化的基礎上做很多事情，比如 定義自動化工具來幫助開發人員解放雙手 。
本文討論的項目規范可以作為一種參考，以供讀者與相關開發人員翻閱 。
一、項目規范
和Java項目規范類似，以 模塊化項目 的結構來定義項目規范可以為業務項目提供 結構化標準，其可以規整所有 混亂的業務項目結構 。
項目結構標準化的重要性：
項目統一管理與生成方便快速搭框架所有開發人員遵守相同的編碼規范易于交接與維護
以下模塊劃分和Java項目類似，略微有些細節差異 。
1.1 api模塊
業務計算邏輯模塊，不應該出現任何 Spark等執行框架的API 以 保持模塊獨立性與可移植 。
理論上該模塊可以獨立構成一個單機程序執行，這樣可以將最重要的業務邏輯根據需要遷移到任意計算引擎中，如 Spark 到 Spark Streaming、Flink 甚至 Hive UDF 等 。
對外只提供接口調用，不可直接在外部實例化具體類（工廠模式）所有service業務邏輯需要有對應的測試用例事務控制、所有異常捕獲和處理依賴common1.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中同時操作多個表
包結構如下：
【spark開發實戰pdf spark實戰項目案例】basic: basic包下主要放一些基礎對象，如BaseDao，所有dao都需要完善 TABLE_NAMEbean: 定義數據源表結構，不同的數據源可以定義在不同的包中，如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 提供的數據操作接口 讀出數據源 后 調用業務計算邏輯 處理完畢后 寫入數據源 中 。
通過對項目模塊的標準化規范，我們可以以一個 比較統一和簡單易懂的開發方式 來進行需求落地 。
雖然剛開始使用規范的時候會有人覺得繁瑣與不耐煩，如果是手動開發的話誰都會煩，都是一些重復性的苦力活兒，這就是框架規范的缺點：特別繁瑣 。
但是配套做一些自動化工具來使用的話，相信大部分開發人員都會覺得很酸爽，某種程度上標準化項目就是這么來提升開發效率的 。