簡(jiǎn)介：?58 同城的實(shí)時(shí) SQL 建設(shè)以及如何從 Storm 遷移至 Flink。

本文整理自 58 同城實(shí)時(shí)計(jì)算平臺(tái)負(fù)責(zé)人馮海濤在 Flink Forward Asia 2020 分享的議題《Flink 在 58 同城應(yīng)用與實(shí)踐》，內(nèi)容包括：

實(shí)時(shí)計(jì)算平臺(tái)架構(gòu)

實(shí)時(shí) SQL 建設(shè)

Storm 遷移 Flink 實(shí)踐

一站式實(shí)時(shí)計(jì)算平臺(tái)

后續(xù)規(guī)劃

一、實(shí)時(shí)計(jì)算平臺(tái)架構(gòu)

實(shí)時(shí)計(jì)算平臺(tái)的定位是為 58 集團(tuán)海量數(shù)據(jù)提供高效、穩(wěn)定的實(shí)時(shí)計(jì)算一站式服務(wù)。一站式服務(wù)主要分為三個(gè)方向：

• 第一個(gè)方向是實(shí)時(shí)數(shù)據(jù)存儲(chǔ)，主要負(fù)責(zé)為線上業(yè)務(wù)接入提供高速度的實(shí)時(shí)存儲(chǔ)能力。
• 第二是實(shí)時(shí)數(shù)據(jù)計(jì)算，主要為海量數(shù)據(jù)的處理提供分布式計(jì)算框架。
• 第三是實(shí)時(shí)數(shù)據(jù)分發(fā)，主要負(fù)責(zé)將計(jì)算后的數(shù)據(jù)分發(fā)到后續(xù)的實(shí)時(shí)存儲(chǔ)，供上層應(yīng)用。

平臺(tái)建設(shè)主要分為兩個(gè)部分：

• 第一部分是基礎(chǔ)能力建設(shè)，目前主要包括 Kafka 集群、storm 集群、 Flink 集群、SparkStreaming 集群。

• 另一部分是平臺(tái)化建設(shè)，主要是包括兩點(diǎn)：

  • 第一個(gè)是數(shù)據(jù)分發(fā)，我們的數(shù)據(jù)分發(fā)是基于 Kafka Connect 打造的一個(gè)平臺(tái)，目標(biāo)是實(shí)現(xiàn)異構(gòu)數(shù)據(jù)源的集成與分發(fā)。在實(shí)際使用數(shù)據(jù)場(chǎng)景過程中，經(jīng)常需要將不同的數(shù)據(jù)源匯聚到一起進(jìn)行計(jì)算分析。

    傳統(tǒng)方式可能需要針對(duì)不同的存儲(chǔ)采用不同的數(shù)據(jù)同步方案。我們的數(shù)據(jù)分發(fā)是通過提供一套完整的架構(gòu)，實(shí)現(xiàn)不同數(shù)據(jù)源的集成和分發(fā)。

  • 第二個(gè)是我們基于 Flink 打造的一站式實(shí)時(shí)計(jì)算平臺(tái)，后文會(huì)有詳細(xì)的介紹。

上圖是我們的實(shí)時(shí)計(jì)算平臺(tái)的架構(gòu)。

• 在實(shí)時(shí)數(shù)據(jù)接入這部分，我們采用的是 Kafka，binlog 提供 canal 和 debezium 兩種方式進(jìn)行接入。
• 在業(yè)務(wù)日志這部分，我們主要采用 flume 進(jìn)行線上業(yè)務(wù)的 log 的采集。
• 在實(shí)時(shí)計(jì)算引擎這部分，根據(jù)開源社區(qū)發(fā)展以及用戶的需求，從最早的 Storm 到后來引入 SparkStreaming，以及現(xiàn)在主流的 Flink。
• 在實(shí)時(shí)存儲(chǔ)這部分，為了滿足多元化的實(shí)時(shí)需求，我們支持 Kafka、Druid、Hbase、ES、ClickHouse。
• 同時(shí)在計(jì)算架構(gòu)之上，我們建設(shè)了一些管理平臺(tái)，比如集群管理，它主要負(fù)責(zé)集群的擴(kuò)容，穩(wěn)定性的管理。
• 另一個(gè)是 Nightfury，主要負(fù)責(zé)集群治理，包括數(shù)據(jù)接入、權(quán)限治理、資源管理等等。

我們?cè)跇I(yè)務(wù)發(fā)展過程中，引入了 Flink 計(jì)算框架。首先從業(yè)務(wù)來說，58 是一個(gè)一站式生活服務(wù)平臺(tái)，包含很多業(yè)務(wù)線。隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量越來越大，場(chǎng)景越來越豐富，需要一個(gè)更加強(qiáng)大的計(jì)算框架來滿足用戶的需求。

• 第一個(gè)場(chǎng)景是實(shí)時(shí) ETL，主要是針對(duì)原始日志進(jìn)行信息轉(zhuǎn)化，結(jié)構(gòu)化處理，運(yùn)用于后續(xù)計(jì)算，需要高吞吐低延遲的計(jì)算能力。
• 第二塊是實(shí)時(shí)數(shù)倉，它作為離線數(shù)倉的一個(gè)補(bǔ)充，主要是提升一些實(shí)時(shí)指標(biāo)的時(shí)效性。第三種場(chǎng)景是實(shí)時(shí)監(jiān)控，它需要比較靈活的時(shí)間窗口支持。
• 最后一種場(chǎng)景是實(shí)時(shí)數(shù)據(jù)流分析，比如說，數(shù)據(jù)亂序的處理、中間狀態(tài)的管理、Exactly once 語義保障。

我們前期基于 Storm 和 SparkStreaming 構(gòu)建的計(jì)算集群在很大程度上并不能滿足這些場(chǎng)景需求。于是對(duì) Flink 進(jìn)行了調(diào)研，發(fā)現(xiàn) Flink 不論是在計(jì)算性能，還是流數(shù)據(jù)特性支持上，都體現(xiàn)出了非常大的優(yōu)勢(shì)。因此，我們決定采用 Flink 作為主流的計(jì)算框架。

上圖是我們 Flink 集群的建設(shè)情況。Flink 作為實(shí)時(shí)計(jì)算框架，經(jīng)常需要 7×24 小時(shí)的可用性。我們?cè)诮ㄔO(shè)底層集群的時(shí)候，需要考慮高可用的架構(gòu)。

• 首先在部署模式上，主要是采用 Flink On YARN，實(shí)現(xiàn)集群的高可用。
• 在底層的 HDFS 上，采用 HDFS federation 機(jī)制，既可以避免離線集群的抖動(dòng)對(duì)實(shí)時(shí)這邊造成影響，同時(shí)也減少了維護(hù)的 HDFS 數(shù)量。
• 在集群隔離上，主要是采用 Node Labe 機(jī)制，就可以實(shí)現(xiàn)把重要業(yè)務(wù)運(yùn)行在一些指定節(jié)點(diǎn)上。同時(shí)在這個(gè)基礎(chǔ)之上，引入了 Cgroup，對(duì) CPU 進(jìn)行隔離，避免任務(wù)間的 CPU 搶占。
• 在管理層面，不同的業(yè)務(wù)提交到不同的隊(duì)列進(jìn)行管理，避免業(yè)務(wù)間的資源搶占。
• 在計(jì)算場(chǎng)景上，根據(jù)不同的計(jì)算場(chǎng)景，比如說計(jì)算型、IO 型，會(huì)提交到不同的節(jié)點(diǎn)，從而提升整個(gè)集群的資源利用率。

Flink 計(jì)算框架在 58 經(jīng)歷了大概兩年多的發(fā)展。目前我們的集群有 900 多臺(tái)機(jī)器，2000 多個(gè)實(shí)時(shí)任務(wù)，每天處理大概 2.5 萬億的實(shí)時(shí)數(shù)據(jù)，數(shù)據(jù)量峰值達(dá)到了 3000 萬每秒。

二、實(shí)時(shí) SQL 建設(shè)

1. 實(shí)時(shí) SQL 演進(jìn)

SQL 編程具有低門檻、自動(dòng)優(yōu)化、版本統(tǒng)一等特點(diǎn)。同時(shí) Flink SQL 作為實(shí)時(shí)數(shù)倉的主要工具，是我們?cè)诮ㄔO(shè) Flink 平臺(tái)時(shí)考慮的一個(gè)主要方向。

我們最早上線的 Flink 是基于 1.6 版本的，當(dāng)時(shí)這個(gè)版本只支持 DML，我們?cè)诋?dāng)時(shí)的版本基礎(chǔ)上進(jìn)行了一些擴(kuò)展，主要是在 DDL 語法上的擴(kuò)展支持。在用戶使用層面，為了簡(jiǎn)化 DDL 的定義，也通過一個(gè)配置化的方式來實(shí)現(xiàn)自動(dòng)生成 DDL。在開發(fā)的時(shí)候，提供可視化開發(fā)的功能和在線調(diào)試的功能。

隨著社區(qū)的開源，我們將 Flink SQL 切換到了社區(qū)版本，之后也升級(jí)相關(guān)的版本，以及合并比較多的社區(qū)版本特性，比如說 Blink 相關(guān)、批流合一、對(duì) Hive 的支持。

最后針對(duì) Flink SQL 這塊的實(shí)時(shí)數(shù)倉，也做了一些數(shù)倉化的工作，主要包括元數(shù)據(jù)管理、血緣關(guān)系、數(shù)倉分層、權(quán)限管理等等。

2. 存儲(chǔ)擴(kuò)展

關(guān)于存儲(chǔ)擴(kuò)展這一塊，最開始我們是基于 Flink 自己實(shí)現(xiàn)的一套 DDL。隨著社區(qū)開源，切換到社區(qū)的 Flink SQL 版本，然后在上面做了一些擴(kuò)展，主要有幾個(gè)方面：

• 第一，打通了主流存儲(chǔ)和內(nèi)部的實(shí)時(shí)存儲(chǔ)。比如說，在源表上支持了內(nèi)部的 wmb，它是一個(gè)分布式消息隊(duì)列。在維表上支持這種 redis，內(nèi)部的 wtable。在結(jié)果表上支持了 ClickHouse，redis，以及我們內(nèi)部的 wtable；
• 第二，定制 format 支持。因?yàn)樵趯?shí)際業(yè)務(wù)中，很多數(shù)據(jù)格式并不是標(biāo)準(zhǔn)的，沒法通過 DDL 來定義一個(gè)表。我們提供了一種通用的方式，可以采用一個(gè)字段來代表一條日志，讓用戶可以通過 udf 去自定義，并解析一條日志。
• 最后，在 source 和 sink DDL 定義基礎(chǔ)上，增加了并發(fā)度的設(shè)置。這樣用戶就可以更靈活地控制任務(wù)的并發(fā)。

3. 性能優(yōu)化

關(guān)于性能優(yōu)化，主要是兩方面：

• 第一個(gè)是對(duì) Blink 特性的引進(jìn)，Blink 提供了大量的特性，比如通過 mini batch 的處理方式，提高任務(wù)的吞吐。通過 local global 兩階段聚合，緩解數(shù)據(jù)熱點(diǎn)問題。還有通過 emit，增強(qiáng)窗口的功能。把這些功能集成到我們的計(jì)算平臺(tái)，用戶通過一些按鈕可以直接打開。

• 另一個(gè)是對(duì)異步 lO 的應(yīng)用。在實(shí)時(shí)數(shù)倉化建設(shè)過程中，維表之間的關(guān)聯(lián)是比較大的應(yīng)用場(chǎng)景，經(jīng)常因?yàn)榫S表的性能導(dǎo)致整個(gè)任務(wù)的吞吐不高。因此我們?cè)黾恿艘粋€(gè)異步 IO 的機(jī)制，主要有兩種實(shí)現(xiàn)：

  • 一種針對(duì)目標(biāo)存儲(chǔ)支持異步 client，直接基于異步 client 來實(shí)現(xiàn)。比如 MySQL 和 redis。
  • 另一種不支持異步 client 的，我們就借助現(xiàn)成的機(jī)制來模擬，同時(shí)在這個(gè)基礎(chǔ)之上增加了一套緩存的機(jī)制，避免所有的數(shù)據(jù)直接查詢到目標(biāo)存儲(chǔ)，減少目標(biāo)存儲(chǔ)的壓力。同時(shí)在緩存基礎(chǔ)上，也增加 LRU 機(jī)制，更加靈活的控制整個(gè)緩存。

    同樣，數(shù)據(jù)寫入這一塊遇到大并發(fā)量寫入的時(shí)候，盡量提高并發(fā)來解決寫入性的問題，這樣就會(huì)導(dǎo)致整個(gè)任務(wù)的 CPU 利用率比較低，所以就采用單并發(fā)度多線程的寫入機(jī)制，它的實(shí)現(xiàn)是在 sink 算子里面增加一個(gè) buffer，數(shù)據(jù)流入到 sink 之后會(huì)首先寫入到 buffer，然后會(huì)啟動(dòng)多線程機(jī)制去消費(fèi)這個(gè) buffer，最終寫到存儲(chǔ)里面。

4. 數(shù)倉化建設(shè)

實(shí)時(shí)數(shù)倉作為 Flink 的一個(gè)比較典型的應(yīng)用場(chǎng)景，相較于離線數(shù)倉它可能存在一些平臺(tái)化不完善的方面：

• 首先，元數(shù)據(jù)管理功能不完善。
• 然后，Flink SQL 這一塊，對(duì)于每個(gè)任務(wù)我們都可能需要重新定義一個(gè)數(shù)據(jù)表。并且由于數(shù)據(jù)沒有分層的概念，導(dǎo)致任務(wù)比較獨(dú)立，煙囪式開發(fā)，數(shù)據(jù)和資源使用率比較低下。
• 另外，也缺乏數(shù)據(jù)血緣信息。

為了提升實(shí)時(shí)數(shù)倉建設(shè)的效率，我們提供了面向數(shù)倉化實(shí)時(shí) SQL 能力，在數(shù)倉設(shè)計(jì)，任務(wù)開發(fā)，平臺(tái)化管理方面全面對(duì)齊離線數(shù)倉的建設(shè)模式。

4.1 數(shù)倉化

數(shù)倉化主要是參考離線數(shù)倉的模型，對(duì)我們實(shí)時(shí)數(shù)倉這一塊進(jìn)行模型建設(shè)。

比如說，最原始的數(shù)據(jù)會(huì)進(jìn)入ODS 層，經(jīng)過一些清洗落入到行為明細(xì)層，之后會(huì)拆分到具體的主題明細(xì)層，然后再將一些相關(guān)的維表信息進(jìn)行計(jì)算，再到匯總層，最終提供給最上層的應(yīng)用，包括一些實(shí)時(shí)報(bào)表，Ad-hoc 查詢等。

4.2 數(shù)倉平臺(tái)

實(shí)時(shí)數(shù)倉目前主要還是基于這種 Lambda 架構(gòu)來進(jìn)行平臺(tái)化的建設(shè)。

• 首先，在元數(shù)據(jù)管理這一塊，Flink 默認(rèn)采用內(nèi)存對(duì)元數(shù)據(jù)進(jìn)行管理，我們就采用了 HiveCatalog 機(jī)制對(duì)庫表進(jìn)行持久化。
• 同時(shí)我們?cè)跀?shù)據(jù)庫的權(quán)限管理上，借助 Hive ACL 來進(jìn)行權(quán)限管理。
• 有了元數(shù)據(jù)持久化之后，就可以提供全局的元數(shù)據(jù)檢索。
• 同時(shí)任務(wù)模式就可以由傳統(tǒng)的 DDL+DML 簡(jiǎn)化為 DML。
• 最后，我們也做了血緣關(guān)系，主要是在 Flink SQL 提交過程中，自動(dòng)發(fā)現(xiàn) SQL 任務(wù)血緣依賴關(guān)系。

三、Storm 遷移 Flink 實(shí)踐

1. Flink 與 Storm 對(duì)比

Flink 相對(duì)于 Storm 來說，有比較多的優(yōu)勢(shì)。

• 在數(shù)據(jù)保障上，Flink 支持 Exactly once 語義，在吞吐量、資源管理、狀態(tài)管理，用戶越來越多的基于 Flink 進(jìn)行開發(fā)。
• 而 Storm 對(duì)用戶來說，編程模型簡(jiǎn)單，開發(fā)成本高，流式計(jì)算特性缺乏，吞吐低無法滿足性能。在平臺(tái)側(cè)，獨(dú)立集群多、運(yùn)維困難、任務(wù)缺少平臺(tái)化管理、用戶體驗(yàn)差。

因此我們決定遷移到 Flink。

2. Flink-Storm 工具

在 Storm 遷移到 Flink 的時(shí)候，如果讓用戶重新基于 Flink 進(jìn)行邏輯開發(fā)，可能需要比較大的工作量。因此我們對(duì) Flink 進(jìn)行了調(diào)研，發(fā)現(xiàn)有個(gè) Flink-Storm 工具。它實(shí)現(xiàn)了將 Storm Topology 轉(zhuǎn)到 Flink Topology。比如說，把 spout 轉(zhuǎn)換到 Flink 的 source function，把 bolt 轉(zhuǎn)換到 Transform 和 sink function。

在使用的過程中我們也發(fā)現(xiàn)一些問題，Flink-Storm 工具無法支持 Yarn 模式， 缺少 Storm 引擎功能，最后還有一個(gè)比較大的問題，我們的 storm 在發(fā)展過程中維護(hù)了很多版本，但是 Flink-Storm 工具只支持基于一個(gè)版本進(jìn)行開發(fā)。于是，我們做了一些改進(jìn)。

3. 對(duì) Flink-Storm 的改進(jìn)

3.1 消息保障

Storm 有三個(gè)特點(diǎn)：

• 第一，ack 機(jī)制；
• 第二，依賴 zookeeper；
• 第三，at least once 語義保障。

我們做了四點(diǎn)改進(jìn)：

• 第一，Flink-Storm 去掉 ack 支持；
• 第二，KafkaSpout 實(shí)現(xiàn) CheckpointListener；
• 第三，KafkaSpout 實(shí)現(xiàn) CheckpointedFunction；
• 第四，Flink-Storm 打開 checkpoint。

3.2 對(duì) Storm 定時(shí)器的支持

在早期版本里面其實(shí)是沒有窗口機(jī)制的，我們借助 Storm 定時(shí)機(jī)制來實(shí)現(xiàn)窗口計(jì)算。它的機(jī)制是這樣的，Storm 引擎會(huì)定時(shí)向 bolt 里面發(fā)送一個(gè)系統(tǒng)信號(hào)，用戶就可以通過這個(gè)系統(tǒng)信號(hào)進(jìn)行一個(gè)切分，模擬窗口操作。

同樣，Flink 也沒有這樣一個(gè)定時(shí)器的機(jī)制，于是我們就考慮從 Flink-Storm 層面來實(shí)現(xiàn)，改造了 BoltWrapper 類，它作為 bolt 類的一個(gè)封裝，實(shí)現(xiàn)機(jī)制跟 bolt 是一樣的，包括 5 點(diǎn)：

• 初始化 open 方式啟動(dòng)異步線程。
• 模擬構(gòu)造 tick 的 StreamRecord；
• 調(diào)用 processeElement 函數(shù)發(fā)送 tuple；
• 頻率由外部參數(shù)全局控制；
• close 中關(guān)閉線程。

3.3 Storm on Yarn

Storm on yarn 并不是直接提交到 YARN 集群，它只是提交到 local 或者 stand alone 的模式。Flink on yarn 主要是提供了 ClusterClient 這樣一個(gè)代理，實(shí)現(xiàn)方式有三個(gè)步驟：

初始化 YarnClusterConfiguration Flink 配置 執(zhí)行 jar 包 / 資源配置 加載 classpath；

啟動(dòng) yarn client；

復(fù)用 Flink on yarn 機(jī)制 deploy 轉(zhuǎn)換后的 jobGraph。

4. 任務(wù)遷移

在完善上述的一些改進(jìn)之后，遷移就比較容易了。首先我們會(huì)把改造后的版本打包，上傳到公司的私服上。然后用戶在他的工程里面只需要引入 jar 包。在代碼這一塊，只需要將原來基于 storm 的提交方式改造成基于 Flink 的提交方式，邏輯是完全不用動(dòng)的。在任務(wù)部署模式這一塊，也提供了 Flink 提交的模式，這樣一個(gè)腳本可以實(shí)現(xiàn) Flink Perjob 模式。

總結(jié)一下，除了一些比較極端的復(fù)雜情況，基本上做到了無縫遷移所有的任務(wù)。遷移到 Flink 之后，大部分任務(wù)的延遲都降低到毫秒級(jí)別，整個(gè)吞吐提升 3~5 倍。同時(shí)，整體資源節(jié)省了大概 40%，約等于 80 臺(tái)機(jī)器。完成了 5 個(gè) storm 集群完全下線，實(shí)現(xiàn)了任務(wù)平臺(tái)化管理。

四、一站式實(shí)時(shí)計(jì)算平臺(tái)

1. Wstream 平臺(tái)

我們?yōu)榱颂嵘芾硇识蛟炝?Wstream 平臺(tái)，它構(gòu)建在底層引擎和上層應(yīng)用之間，對(duì)用戶可以屏蔽底層的集群信息，比如跨機(jī)房多集群的一些信息。

• 在任務(wù)接入方式上，支持 Flink Jar，Flink SQL，Flink-Storm，PyFlink 這 4 種方式，來滿足多元化的用戶需求。
• 在產(chǎn)品功能上，主要支持了任務(wù)管理、任務(wù)的創(chuàng)建、啟動(dòng)刪除等。
• 另外，為了更好的讓用戶管理自己的任務(wù)和對(duì)任務(wù)進(jìn)行問題定位，我們也提供了一個(gè)監(jiān)控告警和任務(wù)診斷的系統(tǒng)。
• 針對(duì)數(shù)倉，提供了一些數(shù)倉平臺(tái)化的功能，包括權(quán)限管理、血緣關(guān)系等等。
• 針對(duì) Flink SQL 也提供了調(diào)試探查的功能。

用戶可以在 Wstream 平臺(tái)之上很好的去構(gòu)建他們的應(yīng)用。

2. 狀態(tài)管理

狀態(tài)作為 Flink 一個(gè)比較重要的特性，在實(shí)際場(chǎng)景中有大量的應(yīng)用。用戶在使用平臺(tái)的時(shí)候，沒法跟底層的 Flink 工具進(jìn)行交互，于是我們就將底層的一些能力進(jìn)行了集成。

• 在任務(wù)保存方面，支持 Checkpoint，Savepoint，Cancel With Savepoint。
• 在容錯(cuò)方面，支持 allowNonRestoredState，跳過無法恢復(fù)的狀態(tài)。
• 在分析方面，支持 Queryable State 實(shí)時(shí)查詢，基于離線的 State Processor 的分析方式，我們會(huì)幫用戶把這個(gè)狀態(tài)下載進(jìn)行分析。

對(duì)于整個(gè)任務(wù)狀態(tài)管理來說，我們通過 jobgraph 設(shè)置定向到指定 Hdfs 目錄，進(jìn)行統(tǒng)一目錄管理。在狀態(tài)小文件這塊，控制并發(fā)度，jobgraph 優(yōu)化，checkpoint 間隔時(shí)間，保留版本數(shù)量。

3. SQL 調(diào)試

針對(duì) Flink SQL，我們也提供了一些調(diào)試功能。這里主要包括兩塊：

• 第一，語法層面的功能包括：

  • 智能提示；
  • 語法校驗(yàn)；
  • 轉(zhuǎn)換 graph 邏輯校驗(yàn)。

• 第二，邏輯層面的功能包括：

  • 模擬輸入，DataGen 自定義數(shù)據(jù)源；
  • 結(jié)果輸出，Print 重定向到標(biāo)準(zhǔn)輸出。

這樣我們可以更方便的對(duì)整個(gè)業(yè)務(wù)邏輯進(jìn)行調(diào)試。

4. 任務(wù)監(jiān)控

關(guān)于任務(wù)監(jiān)控，對(duì)于 Flink 實(shí)時(shí)計(jì)算任務(wù)來說，我們主要關(guān)心的是任務(wù)的穩(wěn)定性、性能方面、以及業(yè)務(wù)邏輯是否符合預(yù)期。對(duì)于如何監(jiān)控這些指標(biāo)，主要包括 4 個(gè)層面：

• 第一個(gè)是 Flink 自帶的 Flink-metrics，提供大量的信息，比如流量信息、狀態(tài)信息、反壓、檢查點(diǎn)、CPU、網(wǎng)絡(luò)等等；
• 第二個(gè)是 yarn 層面，提供運(yùn)行時(shí)長(zhǎng)、任務(wù)狀態(tài)；
• 第三，從 kafka 層面提供消息堆積；
• 最后，通過用戶自定義的一些 metrics，我們可以了解業(yè)務(wù)邏輯是否符合預(yù)期。

5. 監(jiān)控體系

為了采集這些指標(biāo)，我們也基于 Prometheus 搭建了一套監(jiān)控體系。對(duì)于所有的 Flink 任務(wù)，會(huì)實(shí)時(shí)將 metrics 推到 pushgateway，然后會(huì)將收集到的指標(biāo)推到 Prometheus，這一塊我們主要是采用的 federation 的機(jī)制。所有子節(jié)點(diǎn)負(fù)責(zé)指標(biāo)采集，之后匯聚到一個(gè)中心節(jié)點(diǎn)，由中心節(jié)點(diǎn)統(tǒng)一對(duì)外提供服務(wù)。最終可以實(shí)現(xiàn)整個(gè)指標(biāo)的計(jì)算和告警。

6. 監(jiān)控告警

有了上面這些指標(biāo)之后，我們?cè)诟婢@一塊就可以比較方便。針對(duì)實(shí)時(shí)計(jì)算比較關(guān)注的任務(wù)穩(wěn)定性方面，我們可以從 Topic 消息消費(fèi)堆積、任務(wù)計(jì)算 qps 波動(dòng)、Flink task Restart、Flink Checkpoint failed、任務(wù)失敗、延遲等信息來觀察整個(gè)任務(wù)的運(yùn)行情況。

7. 指標(biāo)可視化

在指標(biāo)可視化這一塊，主要是兩個(gè)層面：

• 第一個(gè)層面是 Job 層面，這一塊主要是把一些比較核心的指標(biāo)匯聚到我們的實(shí)時(shí)計(jì)算平臺(tái)。比如說，qps 信息、輸入輸出的信息、延遲的信息等等；
• 對(duì)于更底層的 task 級(jí)別的 metrics，通過 Grafana 可以了解具體的一些task信息，比如流量信息、反壓信息等。

五、后續(xù)規(guī)劃

我們的后續(xù)規(guī)劃，主要包括 4 個(gè)方面：

• 第一個(gè)是社區(qū)比較流行的批流合一。因?yàn)槲覀儺?dāng)前這個(gè)實(shí)時(shí)架構(gòu)大部分還是基于 Lambda 架構(gòu)，這種架構(gòu)會(huì)帶來很大的維護(hù)工作量，所以我們也希望借助批流合一的能力來簡(jiǎn)化架構(gòu)；
• 第二個(gè)是資源調(diào)優(yōu)，因?yàn)樽鳛榱魇接?jì)算來說，缺少一些動(dòng)態(tài)資源管理的機(jī)制，因此我們也希望有手段來進(jìn)行這樣一些調(diào)優(yōu)；
• 第三個(gè)是智能監(jiān)控，我們當(dāng)前的監(jiān)控和告警是事后的，希望有某種方式在任務(wù)出現(xiàn)問題之前進(jìn)行預(yù)警；
• 最后是擁抱社區(qū)的新能力，包括對(duì)新場(chǎng)景的探索。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的Flink 在 58 同城的应用与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。