本文系《Flink在美團(tuán)的應(yīng)用與實(shí)踐》的聽(tīng)課筆記

原始視頻視頻資源已經(jīng)在優(yōu)酷公開(kāi)：2018.8.11 Flink China Meetup·北京站-Flink在美團(tuán)的應(yīng)用與實(shí)踐?

作者：劉迪珊@美團(tuán)

?

1.現(xiàn)狀和背景

?

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

最底層是數(shù)據(jù)緩存層，可以看到美團(tuán)測(cè)的所有日志類的數(shù)據(jù)，都是通過(guò)統(tǒng)一的日志收集系統(tǒng)收集到Kafka。

Kafka作為最大的數(shù)據(jù)中轉(zhuǎn)層，支撐了美團(tuán)線上的大量業(yè)務(wù)，包括離線拉取，以及部分實(shí)時(shí)處理業(yè)務(wù)等。

在數(shù)據(jù)緩存層之上，是一個(gè)引擎層，這一層的左側(cè)是我們目前提供的實(shí)時(shí)計(jì)算引擎，包括Storm和Flink。

Storm在此之前是 standalone 模式的部署方式，Flink由于其現(xiàn)在運(yùn)行的環(huán)境，美團(tuán)選擇的是On YARN模式，除了計(jì)算引擎之外，我們還提供一些實(shí)時(shí)存儲(chǔ)功能，用于存儲(chǔ)計(jì)算的中間狀態(tài)、計(jì)算的結(jié)果、以及維度數(shù)據(jù)等，目前這一類存儲(chǔ)包含Hbase、Redis以及ES。

在計(jì)算引擎之上，是趨于五花八門(mén)的一層，這一層主要面向數(shù)據(jù)開(kāi)發(fā)的同學(xué)。實(shí)時(shí)數(shù)據(jù)開(kāi)發(fā)面臨諸多問(wèn)題，例如在程序的調(diào)試調(diào)優(yōu)方面就要比普通的程序開(kāi)發(fā)困難很多。在數(shù)據(jù)平臺(tái)這一層，美團(tuán)面向用戶提供的實(shí)時(shí)計(jì)算平臺(tái)，不僅可以托管作業(yè)，還可以實(shí)現(xiàn)調(diào)優(yōu)診斷以及監(jiān)控報(bào)警，此外還有實(shí)時(shí)數(shù)據(jù)的檢索以及權(quán)限管理等功能。

除了提供面向數(shù)據(jù)開(kāi)發(fā)同學(xué)的實(shí)時(shí)計(jì)算平臺(tái)，美團(tuán)現(xiàn)在正在做的事情還包括構(gòu)建元數(shù)據(jù)中心。這也是未來(lái)我們想做SQL的一個(gè)前提，元數(shù)據(jù)中心是承載實(shí)時(shí)流系統(tǒng)的一個(gè)重要環(huán)節(jié)，我們可以把它理解為實(shí)時(shí)系統(tǒng)中的大腦，它可以存儲(chǔ)數(shù)據(jù)的Schema，Meta。架構(gòu)的最頂層就是我們現(xiàn)在實(shí)時(shí)計(jì)算平臺(tái)支撐的業(yè)務(wù)，不僅包含線上業(yè)務(wù)日志的實(shí)時(shí)查詢和檢索，還涵蓋當(dāng)下十分熱門(mén)的實(shí)時(shí)機(jī)器學(xué)習(xí)。

機(jī)器學(xué)習(xí)經(jīng)常會(huì)涉及到搜索和推薦場(chǎng)景，這兩個(gè)場(chǎng)景最顯著特點(diǎn)：

一、會(huì)產(chǎn)生海量實(shí)時(shí)數(shù)據(jù)；

二、流量的QPS相當(dāng)高。此時(shí)就需要實(shí)時(shí)計(jì)算平臺(tái)承載部分實(shí)時(shí)特征的提取工作，實(shí)現(xiàn)應(yīng)用的搜索推薦服務(wù)。

還有一類是比較常見(jiàn)的場(chǎng)景，包括實(shí)時(shí)的特征聚合，斑馬Watcher（可以認(rèn)為是一個(gè)監(jiān)控類的服務(wù)），實(shí)時(shí)數(shù)倉(cāng)等。

?

實(shí)時(shí)平臺(tái)現(xiàn)狀

美團(tuán)實(shí)時(shí)計(jì)算平臺(tái)的現(xiàn)狀是作業(yè)量現(xiàn)在已經(jīng)達(dá)到了近萬(wàn)，集群的節(jié)點(diǎn)的規(guī)模是千級(jí)別的，天級(jí)消息量已經(jīng)達(dá)到了萬(wàn)億級(jí)，高峰期的消息量能夠達(dá)到千萬(wàn)條每秒。

痛點(diǎn)和問(wèn)題

美團(tuán)在調(diào)研使用Flink之前遇到了一些痛點(diǎn)和問(wèn)題:

實(shí)時(shí)計(jì)算精確性問(wèn)題：在調(diào)研使用Flink之前美團(tuán)很大規(guī)模的作業(yè)是基于Storm去開(kāi)發(fā)的，Storm主要的計(jì)算語(yǔ)義是At-Least-Once，這種語(yǔ)義在保證正確性上實(shí)際上是有一些問(wèn)題的，在Trident之前Storm是無(wú)狀態(tài)的處理。雖然Storm Trident提供了一個(gè)維護(hù)狀態(tài)的精確的開(kāi)發(fā)，但是它是基于串行的Batch提交的，那么遇到問(wèn)題在處理性能上可能會(huì)有一點(diǎn)瓶頸。并且Trident是基于微批的處理，在延遲上沒(méi)有達(dá)到比較高的要求，所以不能滿足一些對(duì)延遲比較高需求的業(yè)務(wù)。

流處理中的狀態(tài)管理問(wèn)題：基于之前的流處理過(guò)程中狀態(tài)管理的問(wèn)題是非常大的一類問(wèn)題。狀態(tài)管理除了會(huì)影響到比如說(shuō)計(jì)算狀態(tài)的一致性，還會(huì)影響到實(shí)時(shí)計(jì)算處理的性能以及故障恢復(fù)時(shí)候的能力。而Flink最突出的一個(gè)優(yōu)勢(shì)就是狀態(tài)管理。

實(shí)時(shí)計(jì)算表義能力的局限性：在實(shí)時(shí)計(jì)算之前很多公司大部分的數(shù)據(jù)開(kāi)發(fā)還是面向離線的場(chǎng)景，近幾年實(shí)時(shí)的場(chǎng)景也慢慢火熱起來(lái)了。那與離線的處理不同的是，實(shí)時(shí)的場(chǎng)景下，數(shù)據(jù)處理的表意能力可能有一定的限制，比如說(shuō)他要進(jìn)行精確計(jì)算以及時(shí)間窗口都是需要在此之上去開(kāi)發(fā)很多功能性的東西。

開(kāi)發(fā)調(diào)試成本高：近千結(jié)點(diǎn)的集群上已經(jīng)跑了近萬(wàn)的作業(yè)，分布式的處理的引擎，手工寫(xiě)代碼的方式，給數(shù)據(jù)開(kāi)發(fā)的同學(xué)也帶來(lái)了很高開(kāi)發(fā)和調(diào)試的成本，再去維護(hù)的時(shí)候，運(yùn)維成本也比較高。

?

Flink探索關(guān)注點(diǎn)

在上面這些痛點(diǎn)和問(wèn)題的背景下，美團(tuán)從去年開(kāi)始進(jìn)行Flink的探索，關(guān)注點(diǎn)主要有以下4個(gè)方面：

1.ExactlyOnce計(jì)算能力
2.狀態(tài)管理能力
3.窗口/Join/時(shí)間處理等等
4.SQL/TableAPI

?

?

2.Flink在美團(tuán)的實(shí)踐

?

穩(wěn)定性實(shí)踐

穩(wěn)定性實(shí)踐-資源隔離

資源隔離的考慮：分場(chǎng)景、按業(yè)務(wù)

高峰期不同，運(yùn)維時(shí)間不同；

可靠性、延遲需求不同；

應(yīng)用場(chǎng)景，重要性不同；

?

資源隔離的策略：

1YARN打標(biāo)簽，節(jié)點(diǎn)物理隔離：

按照?qǐng)鼍昂蜆I(yè)務(wù)維度考慮資源分配的問(wèn)題和滴滴類似是yarn打標(biāo)簽的模式進(jìn)行獨(dú)立的隊(duì)列的隔離。

重要業(yè)務(wù)的運(yùn)行時(shí)的作業(yè)會(huì)獨(dú)立在某一批機(jī)器上，避免其他業(yè)務(wù)的影響。

2離線DataNode與實(shí)時(shí)計(jì)算節(jié)點(diǎn)的隔離：

之前都是on yarn為了節(jié)約成本計(jì)算和存儲(chǔ)節(jié)點(diǎn)就混布，發(fā)現(xiàn)離線DataNode某一段時(shí)間數(shù)據(jù)量大導(dǎo)致出現(xiàn)毛刺現(xiàn)象。

這時(shí)會(huì)對(duì)實(shí)時(shí)計(jì)算的穩(wěn)定性造成影響。

?

穩(wěn)定性實(shí)踐-智能調(diào)度

?

yarn基于CPU和內(nèi)存去調(diào)度

智能調(diào)度目的也是為了解決資源不均的問(wèn)題，現(xiàn)在普通的調(diào)度策略就是基于CPU，基于內(nèi)存去調(diào)度的。除此之外，在生產(chǎn)過(guò)程中也發(fā)現(xiàn)了一些其他的問(wèn)題，比如說(shuō)Flink是會(huì)依賴本地磁盤(pán)，進(jìn)行依賴本地磁盤(pán)做本地的狀態(tài)的存儲(chǔ)，所以磁盤(pán)IO，還有磁盤(pán)的容量，也是一類考慮的問(wèn)題點(diǎn)，除此之外還包括網(wǎng)卡流量，因?yàn)槊總€(gè)業(yè)務(wù)的流量的狀態(tài)是不一樣的，分配進(jìn)來(lái)會(huì)導(dǎo)致流量的高峰，把某一個(gè)網(wǎng)卡打滿，從而影響其他業(yè)務(wù)，所以期望的話是說(shuō)做一些智能調(diào)度化的事情。目前暫時(shí)能做到的是從cpu和內(nèi)存兩方面，未來(lái)會(huì)從其他方面做一些更優(yōu)的調(diào)度策略。

?

穩(wěn)定性實(shí)踐-故障容錯(cuò)

1.節(jié)點(diǎn)/網(wǎng)絡(luò)故障

JobManagerHA，自動(dòng)拉起

與Storm不同的是，知道Storm在遇到異常的時(shí)候是非常簡(jiǎn)單粗暴的，比如說(shuō)有發(fā)生了異常，可能用戶沒(méi)有在代碼中進(jìn)行比較規(guī)范的異常處理，但是沒(méi)有關(guān)系，因?yàn)?strong>worker會(huì)重啟作業(yè)還會(huì)繼續(xù)執(zhí)行，并且他保證的是At-Least-Once這樣的語(yǔ)義，比如說(shuō)一個(gè)網(wǎng)絡(luò)超時(shí)的異常對(duì)他而言影響可能并沒(méi)有那么大，

Flink不同的是他對(duì)異常的容忍度是非常的苛刻的，那時(shí)候就考慮的是比如說(shuō)會(huì)發(fā)生節(jié)點(diǎn)或者是網(wǎng)絡(luò)的故障，那JobManager單點(diǎn)問(wèn)題可能就是一個(gè)瓶頸，JobManager那個(gè)如果掛掉的話，那么可能對(duì)整個(gè)作業(yè)的影響就是不可回復(fù)的，所以考慮了做HA，另外一個(gè)就是會(huì)去考慮一些由于運(yùn)維的因素而導(dǎo)致的，還有除此之外，可能有一些用戶作業(yè)是沒(méi)有開(kāi)啟CheckPoint，但如果是因?yàn)?strong>節(jié)點(diǎn)或者是網(wǎng)絡(luò)故障導(dǎo)致掛掉，希望會(huì)在平臺(tái)那一層做一些自動(dòng)拉起的策略，去保證作業(yè)運(yùn)行的穩(wěn)定性。

2.上下游容錯(cuò)

FlinkKafka 08異常重試

我們的數(shù)據(jù)源主要是Kafka，讀寫(xiě)Kafka是一類非常常見(jiàn)的實(shí)時(shí)流處理避不開(kāi)的一個(gè)內(nèi)容，而Kafka本身的集群規(guī)模是非常比較大的，因此節(jié)點(diǎn)的故障出現(xiàn)是一個(gè)常態(tài)問(wèn)題，在此基礎(chǔ)上我們對(duì)節(jié)點(diǎn)故障進(jìn)行了一些容錯(cuò)，比如說(shuō)節(jié)點(diǎn)掛掉或者是數(shù)據(jù)均衡的時(shí)候，Leader會(huì)切換，那本身Flink的讀寫(xiě)對(duì)Leader的切換容忍度沒(méi)有那么高，在此基礎(chǔ)上我們對(duì)一些特定場(chǎng)景的，以及一些特有的異常做的一些優(yōu)化，進(jìn)行了一些重試。這是影響作業(yè)穩(wěn)定性的一個(gè)點(diǎn)。

3.容災(zāi)

多機(jī)房，流熱備

?

Flink平臺(tái)化-作業(yè)管理

容災(zāi)可能大家對(duì)考慮的并不多，比如說(shuō)有沒(méi)有可能一個(gè)機(jī)房的所有的節(jié)點(diǎn)都掛掉了，或者是無(wú)法訪問(wèn)了，雖然它是一個(gè)小概率的事件，但它也是會(huì)發(fā)生的。所以現(xiàn)在也會(huì)考慮做多機(jī)房的一些部署，包括還有Kafka流的一些熱備。

?

在實(shí)踐過(guò)程中，為了解決作業(yè)管理的一些問(wèn)題，減少用戶開(kāi)發(fā)的一些成本，我們做了一些平臺(tái)化的工作，下圖是一個(gè)作業(yè)提交的界面展示，包括作業(yè)的配置，作業(yè)生命周期的管理，報(bào)警的一些配置，延遲的展示，都是集成在實(shí)時(shí)計(jì)算平臺(tái)的。

Flink平臺(tái)化-監(jiān)控報(bào)警

在監(jiān)控上我們也做了一些事情，對(duì)于實(shí)時(shí)作業(yè)來(lái)講，對(duì)監(jiān)控的要求會(huì)更高，比如說(shuō)在作業(yè)延遲的時(shí)候?qū)I(yè)務(wù)的影響也比較大，所以做了一些延遲的報(bào)警，包括作業(yè)狀態(tài)的報(bào)警，比如說(shuō)作業(yè)存活的狀態(tài)，以及作業(yè)運(yùn)行的狀態(tài)，還有未來(lái)會(huì)做一些自定義Metrics的報(bào)警。自定義Metrics是未來(lái)會(huì)考慮基于作業(yè)處理本身的內(nèi)容性，做一些可配置化的一些報(bào)警。

?

Flink平臺(tái)化-調(diào)優(yōu)診斷

實(shí)時(shí)計(jì)算引擎提供統(tǒng)一日志和Metrics方案

為業(yè)務(wù)提供按條件過(guò)濾的日志檢索

為業(yè)務(wù)提供自定義時(shí)間跨度的指標(biāo)查詢

基于日志和指標(biāo)，為業(yè)務(wù)提供可配置的報(bào)警

另外就是剛剛提到說(shuō)在開(kāi)發(fā)實(shí)時(shí)作業(yè)的時(shí)候，調(diào)優(yōu)和診斷是一個(gè)比較難的痛點(diǎn)，就是用戶不是很難去查看分布式的日志，所以也提供了一套統(tǒng)一的解決方案。這套解決方案主要是針對(duì)日志和Metrics，會(huì)在針對(duì)引擎那一層做一些日志和Metrics的上報(bào)，那么它會(huì)通過(guò)統(tǒng)一的日志收集系統(tǒng)，將這些原始的日志，還有Metrics匯集到Kafka那一層。今后Kafka這一層大家可以發(fā)現(xiàn)它有兩個(gè)下游，

一方面：是做日志到ES的數(shù)據(jù)同步，目的的話是說(shuō)能夠進(jìn)入日志中心去做一些日志的檢索，

另外一方面：是通過(guò)一些聚合處理流轉(zhuǎn)到寫(xiě)入到OpenTSDB把數(shù)據(jù)做依賴，這份聚合后的數(shù)據(jù)會(huì)做一些查詢，一方面是Metrics的查詢展示，另外一方面就是包括實(shí)做的一些相關(guān)的報(bào)警。

下圖是當(dāng)前某一個(gè)作業(yè)的一個(gè)可支持跨天維度的Metrics的一個(gè)查詢的頁(yè)面。可以看到說(shuō)如果是能夠通過(guò)縱向的對(duì)比，可以發(fā)現(xiàn)除了作業(yè)在某一個(gè)時(shí)間點(diǎn)是因?yàn)槭裁辞闆r導(dǎo)致的？比如說(shuō)延遲啊這樣容易幫用戶判斷一些他的做作業(yè)的一些問(wèn)題。除了作業(yè)的運(yùn)行狀態(tài)之外，也會(huì)先就是采集一些節(jié)點(diǎn)的基本信息作為橫向的對(duì)比

下圖是當(dāng)前的日志的一些查詢，它記錄了，因?yàn)樽鳂I(yè)在掛掉之后，每一個(gè)ApplicationID可能會(huì)變化，那么基于作業(yè)唯一的唯一的主鍵作業(yè)名去搜集了所有的作業(yè)，從創(chuàng)建之初到當(dāng)前運(yùn)行的日志，那么可以允許用戶的跨Application的日志查詢。

?

生態(tài)建設(shè)

Flink落地做了一些生態(tài)的建設(shè)，

線上的MQ和面向生產(chǎn)環(huán)境的Kafka，雖然他們底層都是依賴kafka但是面向的場(chǎng)景是不同的。

線上MQ的特點(diǎn)是單集群的規(guī)模比較小，但是對(duì)延遲的要求合需求比較高。

生產(chǎn)類的kafka的特點(diǎn)是規(guī)模比較大，需要承擔(dān)離線+實(shí)時(shí)的生產(chǎn)，要求這個(gè)集群要高吞吐。

為了適配這兩類MQ做了不同的事情：

對(duì)于線上的MQ，期望去做一次同步，多次消費(fèi)，目的是避免對(duì)線上的業(yè)務(wù)造成影響。

對(duì)于的生產(chǎn)類的Kafka就是線下的Kafka，做了一些地址的屏蔽，還有基礎(chǔ)的一些配置，包括一些權(quán)限的管理，還有指標(biāo)的采集。

?

3.Flink在美團(tuán)的應(yīng)用

下面會(huì)給大家講兩個(gè)Flink在美團(tuán)的真實(shí)使用的案例。

第一個(gè)是Petra，Petra其實(shí)是一個(gè)實(shí)時(shí)指標(biāo)的一個(gè)聚合的系統(tǒng)，它其實(shí)是面向公司的一個(gè)統(tǒng)一化的解決方案。它主要面向的業(yè)務(wù)場(chǎng)景就是基于業(yè)務(wù)的時(shí)間去統(tǒng)計(jì)，還有計(jì)算一些實(shí)時(shí)的指標(biāo)，要求的話是低時(shí)延，他還有一個(gè)就是說(shuō)，因?yàn)樗敲嫦虻氖峭ㄓ玫臉I(yè)務(wù)，由于業(yè)務(wù)可能是各自會(huì)有各自不同的維度，每一個(gè)業(yè)務(wù)可能包含了包括應(yīng)用，通道，機(jī)房，還有其他的各自應(yīng)用各個(gè)業(yè)務(wù)特有的一些維度，而且這些維度可能涉及到比較多，另外一個(gè)就是說(shuō)它可能是就是業(yè)務(wù)需要去做一些復(fù)合的指標(biāo)的計(jì)算，比如說(shuō)最常見(jiàn)的交易成功率，他可能需要去計(jì)算支付的成功數(shù)，還有和下單數(shù)的比例。

另外一個(gè)就是說(shuō)統(tǒng)一化的指標(biāo)聚合可能面向的還是一個(gè)系統(tǒng)，比如說(shuō)是一些B端或者是R段的一些監(jiān)控類的系統(tǒng)，那么系統(tǒng)對(duì)于指標(biāo)系統(tǒng)的訴求，就是說(shuō)我希望指標(biāo)聚合能夠最實(shí)時(shí)最精確的能夠產(chǎn)生一些結(jié)果，數(shù)據(jù)保證說(shuō)它的下游系統(tǒng)能夠真實(shí)的監(jiān)控到當(dāng)前的信息。右邊圖是我當(dāng)一個(gè)Metrics展示的一個(gè)事例。可以看到其他其實(shí)跟剛剛講也是比較類似的，就是說(shuō)包含了業(yè)務(wù)的不同維度的一些指標(biāo)匯聚的結(jié)果。

?

?

在用Flink去做實(shí)時(shí)指標(biāo)復(fù)核的系統(tǒng)的時(shí)候，著重從這幾方面去考慮了。

第一個(gè)方面是說(shuō)精確的計(jì)算，包括使用了FLink和CheckPoint的機(jī)制去保證說(shuō)我能做到不丟不重的計(jì)算，第一個(gè)首先是由統(tǒng)一化的Metrics流入到一個(gè)預(yù)聚合的模塊，預(yù)聚合的模塊主要去做一些初始化的一些聚合，其中的為什么會(huì)分預(yù)聚合和全量聚合主要的解決一類問(wèn)題，包括就剛剛那位同學(xué)問(wèn)的一個(gè)問(wèn)題，就是數(shù)據(jù)傾斜的問(wèn)題，比如說(shuō)在熱點(diǎn)K發(fā)生的時(shí)候，當(dāng)前的解決方案也是通過(guò)預(yù)聚合的方式去做一些緩沖，讓盡量把K去打散，再聚合全量聚合模塊去做匯聚。那其實(shí)也是只能解決一部分問(wèn)題，所以后面也考慮說(shuō)在性能的優(yōu)化上包括去探索狀態(tài)存儲(chǔ)的性能。

下面的話還是包含晚到數(shù)據(jù)的容忍能力，因?yàn)橹笜?biāo)匯聚可能剛剛也提到說(shuō)要包含一些復(fù)合的指標(biāo)，那么復(fù)合的指標(biāo)所依賴的數(shù)據(jù)可能來(lái)自于不同的流，即便來(lái)自于同一個(gè)流，可能每一個(gè)數(shù)據(jù)上報(bào)的時(shí)候，可能也會(huì)有晚到的情況發(fā)生，那時(shí)候需要去對(duì)數(shù)據(jù)關(guān)聯(lián)做晚到的容忍，容忍的一方面是說(shuō)可以設(shè)置晚到的Lateness的延遲，另一方面是可以設(shè)置窗口的長(zhǎng)度，但是其實(shí)在現(xiàn)實(shí)的應(yīng)用場(chǎng)景上，其實(shí)還有一方面考慮就是說(shuō)除了去盡量的去拉長(zhǎng)時(shí)間，還要考慮真正的計(jì)算成本，所以在這方面也做了一些權(quán)衡，那么指標(biāo)基本就是經(jīng)過(guò)全量聚合之后，聚合結(jié)果會(huì)回寫(xiě)Kafka，經(jīng)過(guò)數(shù)據(jù)同步的模塊寫(xiě)到OpenTSDB去做，最后去grafana那做指標(biāo)的展示，另一方面可能去應(yīng)用到通過(guò)Facebook包同步的模塊去同步到報(bào)警的系統(tǒng)里面去做一些指標(biāo)，基于指標(biāo)的報(bào)警。

指標(biāo)---全量聚合---kafka---OpenTSDB---grafana

?

下圖是現(xiàn)在提供的產(chǎn)品化的Petra的一個(gè)展示的機(jī)示意圖，可以看到目前的話就是定義了某一些常用的算子，以及維度的配置，允許用戶進(jìn)行配置話的處理，直接去能夠獲取到他期望要的指標(biāo)的一個(gè)展示和匯聚的結(jié)果。目前還在探索說(shuō)為Petra基于Sql做一些事情，因?yàn)楹芏嘤脩粢脖容^就是在就是習(xí)慣上也可以傾向于說(shuō)我要去寫(xiě)Sql去完成這樣的統(tǒng)計(jì)，所以也會(huì)基于此說(shuō)依賴Flink的本身的對(duì)SQl還有TableAPI的支持，也會(huì)在Sql的場(chǎng)景上進(jìn)行一些探索。

?

MLX機(jī)器學(xué)習(xí)平臺(tái)

第二類應(yīng)用就是機(jī)器學(xué)習(xí)的一個(gè)場(chǎng)景，機(jī)器學(xué)習(xí)的場(chǎng)景可能會(huì)有依賴離線的特征數(shù)據(jù)和實(shí)時(shí)的特征數(shù)據(jù)。

一個(gè)是基于現(xiàn)有的離線場(chǎng)景下的特征提取，經(jīng)過(guò)批處理，流轉(zhuǎn)到離線的集群。

另一個(gè)就是近線模式，近線模式出的數(shù)據(jù)就是現(xiàn)有的從日志收集系統(tǒng)流轉(zhuǎn)過(guò)來(lái)的統(tǒng)一的日志，經(jīng)過(guò)Flink的處理，就是包括流的關(guān)聯(lián)以及特征的提取，再做模型訓(xùn)練，流轉(zhuǎn)到最終訓(xùn)練集群，訓(xùn)練集群會(huì)產(chǎn)出P的特征，還有都是Delta的特征，最終將這些特征影響到線上的線上的特征的一個(gè)訓(xùn)練的一個(gè)服務(wù)上。

總結(jié)

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

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