我是3y,一年CRUD
經驗用十年的markdown
程式設計師???常年被譽為職業八股文選手
最近如果拉過austin
專案程式碼的同學,可能就會發現多了一個austin-stream
模組。其實並不會意外,因為這一切都在計劃當中進行。
這個模組主要是接入流式處理平臺(flink),用於實時計算清洗資料給到業務以及系統維護者更方便去使用訊息推送平臺austin
。
這篇文章主要來聊聊接入的背景以及我淺薄的經驗吧
01、為什麼流式處理平臺
我在老東家有過處理資料相關的經驗,也看到過站內廣告「效果資料」的發展歷程。
所謂效果資料,說白了則是商家在平臺上投放了廣告,我們需要給商家看到廣告帶來的效果,最核心的是「曝光」「點選」「訂單」,基於這幾項資料再聚合些類roi
的指標。
下面來聊聊這個「發展歷程」,看完這個過程或許可以更好地瞭解為什麼需要流式處理平臺
1、PHP階段:在最初時業務以及系統結構都比較簡單,把「點選」和「訂單」都存入資料庫表,一把梭通過定時任務全量聚合,得到最終的效果資料,而「曝光」資料則是次日再寫入效果資料表中。
在這個階段裡,由於資料量不大,通過定時任務全量來聚合資料也不是不可以,那時候商家都能接受該業務的延遲性
2、Java階段:隨著業務的發展,逐漸摒棄PHP化並且廣告三層結構成型、資料量日益提升、站內中介軟體服務平臺也發展起來。通過中介軟體團隊提供的消費binlog
框架,從架構上改變聚合模式,並這個階段可以更快地給商家展示效果資料,大概1min出效果資料
3、流式處理平臺階段:流式處理平臺是對「計算」或者說處理資料時的抽象,在這抽象基礎上它更能充分利用系統的資源(一個大的任務被拆分多個小任務,然後分發到不同的機器上執行)
4、廣告效果資料是先用的Storm
作為流式處理平臺,資料跑了幾年都挺穩定的,效能吞吐量上也是滿足業務使用的。後來Flink
興起,支援SQL、Exactly-Once、流批一體化
等,隨著公司內推廣,我將廣告效果資料從Strom
改至Flink
體系上,大概秒級出效果資料。(其實還可以壓縮,但需要兼顧DB的效能成本,只要業務上能接受即可。Traff-off!)
在第三點我提出了「資料處理時的抽象」,我是這樣理解的。在Storm
裡,定義spout
為輸入,bolt
為中間處理或輸出,而中間的資料流轉為tuple
,用shuffle
機制來控制資料的流向
在Flink
裡,就有更加明確的語義來說明輸入和輸出了(程式的API也更有語義性)
這些流處理平臺都會資料處理進行了抽象,讓我們更加方便且高效去處理資料,比如一般會以下的功能:
02、austin哪裡用到了流式處理平臺
在前面austin
系統已經設計了一部分的埋點資訊了,在日誌上都已經列印了下來。
但針對這一部分資料,遲遲沒有做處理(不過之前有一起跟著學austin
的小夥伴給我截了日誌,我一眼就知道是哪裡出了問題)
而接入流式處理平臺就能對這一部分資料進行清洗(根據下發者維度、根據模板訊息維度等等),得到清洗後的資料再給到介面去展示或者排查問題使用,能大大提高排查或者業務方的使用效率
03、Flink入門
Flink
從2018年開始流行,現在已經有很多的公司都在用Flink
作為實時大資料處理的流式平臺。至於我為什麼會選擇Flink
的話,原因有以下:
1、我懂點兒Flink(主要是懶得學其他的了,目前還夠用)
2、Flink發展了幾年,成熟且被很多大公司用,社群活躍
3、Flink的官方文件挺不錯的,適合學習和排查問題
首先我們安裝下Flink
,docker-compose.yml
檔案內容:
version: "2.2"
services:
jobmanager:
image: flink:latest
ports:
- "8081:8081"
command: jobmanager
environment:
- |
FLINK_PROPERTIES=
jobmanager.rpc.address: jobmanager
- SET_CONTAINER_TIMEZONE=true
- CONTAINER_TIMEZONE=Asia/Shanghai
- TZ=Asia/Shanghai
taskmanager:
image: flink:latest
depends_on:
- jobmanager
command: taskmanager
scale: 1
environment:
- |
FLINK_PROPERTIES=
jobmanager.rpc.address: jobmanager
taskmanager.numberOfTaskSlots: 2
- SET_CONTAINER_TIMEZONE=true
- CONTAINER_TIMEZONE=Asia/Shanghai
- TZ=Asia/Shanghai
完了之後直接docker-compose up -d
就可以啟動flink
了,我們訪問在瀏覽器輸入ip:8081
埠就能看到flink
的後臺了
簡單看了下後臺,就能知道我們在本地開發完打包成jar
就可以在Submit New Job
提交jar
包給Flink去跑了
而在寫程式碼的時候,可以參考官方文件給出的mvn
命令去構建Flink
的基礎環境
當然啦,現在我已經搭好了,你們可以直接拉程式碼下來看austin-stream
模組就完事了。如果你們是自己從零搭的話可能還要注意的是,pom
裡的plugin
需要改動(不然打包會失敗的),可參考我的pom
檔案
04、austin程式碼
從目前的程式碼結構和邏輯上看,還是非常簡單的,沒有學過Flink
的同學應該都能看懂:
目前主要實現了將資料實時聚合到Redis,分了兩個維度:使用者和訊息模板(對應的Redis結構都已經寫在了程式碼的註釋上了)
跟著做austin
專案的小夥伴,只要在kafka
建立對應的topic
(我這裡定義的topicName是austinLog
),並且在AustinFlinkConstant
中填寫Kafka的Broker資訊以及Redis資訊後,編譯打包就完了。
提交到Flink平臺之後就可以跑了:
05、後續
經過Flink
的處理已經把資料寫入到Redis裡邊了,最近我已經在寫Controller
層開發介面在頁面上將清洗後的資料在頁面上做展示了。
從前面的頁面實現上如果有了解過的同學可能就知道我用的是低程式碼平臺amis
,而amis
我看了下圖表的文件用的是echarts
進行渲染的。
應該問題不大,過兩天估計就開發完了,主要就是適配引數的問題了,到時候看起來應該就算比較完整了。
最近已經有小夥伴提了pull request
寫了微信服務號的接入了,我已經merge
了程式碼,但還沒除錯。主要比較麻煩的是,我沒有營業執照,就不好開服務號進行除錯,我後面再想想辦法。
今天就聊到這吧,對Flink
感興趣的同學可以看看我以往的幾篇文章和官網入門下,我建議先可以把austin
的程式碼先拉下來,部署一把自己體驗體驗,然後再看理論的知識。
1、Flink入門
都看到這裡了,點個贊一點都不過分吧?我是3y,下期見。
關注我的微信公眾號【Java3y】除了技術我還會聊點日常,有些話只能悄悄說~ 【對線面試官+從零編寫Java專案】 持續高強度更新中!求star!!原創不易!!求三連!!
austin專案原始碼Gitee連結:gitee.com/austin
austin專案原始碼GitHub連結:github.com/austin