我是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