本文轉(zhuǎn)自個人微信公眾號，原文鏈接。

接上篇。

使用場景

先說流計算平臺應(yīng)用場景。在我們的業(yè)務(wù)中，實(shí)時平臺核心包括幾個部分：一是大促看板，比如剛過去的雙11，供領(lǐng)導(dǎo)層和運(yùn)營查看決策使用；二是實(shí)時風(fēng)控的技術(shù)支持；三是實(shí)時數(shù)據(jù)接入、清洗、入庫功能，為下游提供實(shí)時、準(zhǔn)確的數(shù)據(jù)。

為了支持這些業(yè)務(wù)需求，并最小化技術(shù)人員的介入，設(shè)計并實(shí)現(xiàn)了實(shí)時計算平臺。

設(shè)計

首先，是數(shù)據(jù)源部分。數(shù)據(jù)接入包括埋點(diǎn)日志、數(shù)據(jù)庫數(shù)據(jù)、API上報數(shù)據(jù)等，埋點(diǎn)數(shù)據(jù)、API上報的數(shù)據(jù)等都接入Kafka，平臺支持的數(shù)據(jù)源包括Kafka、MySQL、Redis、Elasticsearch，根據(jù)使用經(jīng)驗(yàn)，Kafka和MySQL 已經(jīng)基本覆蓋我們的業(yè)務(wù)需求。我們將數(shù)據(jù)源統(tǒng)一在平臺進(jìn)行管理，使用者不需要關(guān)注數(shù)據(jù)源的具體來源信息。

其次，是Job。Job由數(shù)據(jù)源和具體的task組成。數(shù)據(jù)接入后，需要進(jìn)行運(yùn)算，要定義算子和工作流。算子就是我們要對數(shù)據(jù)流進(jìn)行的操作，同時，對數(shù)據(jù)可能需要經(jīng)過中間很多層處理，所以，還需要定義工作流。算子我們采用Flink SQL，且目前僅支持Flink SQL。Flink 使用 Apache calcite 解析SQL，它支持 ANSI SQL，這對于BI和分析師，都是比較容易使用的。在當(dāng)前情況下，F(xiàn)link SQL 對有些語法還不支持，對我們來說，這不算大問題，一是先有語法已經(jīng)覆蓋我們的絕大多數(shù)需求，如果我們要等它完美支持后再來使用，反而是得不償失，正所謂Done is better than perfect.；其次是對于剛需語法，我們可以根據(jù)Flink 提供的UDF 自行開發(fā)，比如函數(shù)? LAST_VALUE()。

部署

Flink 集群支持Standalone、Yarn、Mesos、K8S等多種模式，我們目前的版本采用Standalone cluster模式，現(xiàn)在流行的在生產(chǎn)環(huán)境使用較多的是Yarn模式，下表是Standalone 模式和 Yarn 模式的優(yōu)缺點(diǎn)對比。我們之前采用Standalone 模式的兩個原因，一是為了快速實(shí)現(xiàn)；二是盡量減少外部依賴特別是對 Yarn 集群的依賴（Yarn 集群主要是離線計算和BI、分析師日常取數(shù)使用，盡量減少對他們的影響。如果要采用Yarn 集群模式，我也推薦單獨(dú)搭建Yarn 集群）。但我還是更推薦Yarn 模式，Job 級別的資源隔離以及失敗自動重啟會更加重要點(diǎn)。

資源

不同的任務(wù)數(shù)據(jù)量不同，計算量不同，需要的資源也不同，我們支持對不同的Job 配置不同的 parallelism，從而滿足不同的資源需求，該值還只是一個經(jīng)驗(yàn)值，暫時無法做到自適應(yīng)配置。

使用

Flink 將 savepoint 保存到HDFS，在使用過程中，我們發(fā)現(xiàn)HDFS上的savepoint 數(shù)量巨大，但一段時間前的savepoint是沒有用處的，所以，我們對savepoint 進(jìn)行了生命周期管理，自動刪除過期的savepoint。

另外，在業(yè)務(wù)方使用過程中，也要做Job的生命周期管理，比如大促看板，否則，實(shí)時計算平臺的資源就是一個黑洞。

其它

系統(tǒng)還涉及用戶管理、權(quán)限管理、監(jiān)控告警等部分，暫不做詳細(xì)介紹。

掃描下方二維碼關(guān)注我。