欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

PyFlink在聚美優(yōu)品的應(yīng)用實(shí)踐是怎樣的

PyFlink在聚美優(yōu)品的應(yīng)用實(shí)踐是怎樣的，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)整合營(yíng)銷推廣、網(wǎng)站重做改版、東遼網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、成都h5網(wǎng)站建設(shè)、購物商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為東遼等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

下面將跟大家分享 PyFlink 在刷寶的應(yīng)用，包括：背景介紹、架構(gòu)演進(jìn)、技術(shù)選型以及一個(gè)問題的解決思路分享。

1.背景介紹


業(yè)務(wù)場(chǎng)景

刷寶有許多重要的業(yè)務(wù)場(chǎng)景，其中之一是為用戶實(shí)時(shí)推薦短視頻。其中  推  薦的實(shí)時(shí)性，決定了用戶在視頻上的停留時(shí)長(zhǎng)、觀看視頻時(shí)長(zhǎng)、留存等指標(biāo)，進(jìn)而影響到廣告位的收益，比如廣告的單價(jià)等。
刷寶從 2019 年開始，業(yè)務(wù)飛速發(fā)展，截止到 2020 年 5 月份，用戶行為數(shù)據(jù)峰值每秒過百萬，每天有 200 億數(shù)據(jù)。這個(gè)業(yè)務(wù)量，對(duì)我們現(xiàn)有的技術(shù)架構(gòu)、數(shù)據(jù)計(jì)算的實(shí)時(shí)性提出了挑戰(zhàn)。

實(shí)時(shí)化挑戰(zhàn)


我們的數(shù)據(jù)流程  整個(gè)環(huán)節(jié)完成需要1小時(shí)左右時(shí)間，遠(yuǎn)達(dá)不到實(shí)時(shí)的要求。如何更快速的根據(jù)用戶瀏覽習(xí)慣實(shí)時(shí)推薦相關(guān)視頻  會(huì)對(duì)用戶觀看視頻時(shí)長(zhǎng)、停留時(shí)長(zhǎng)、留存等有重大的影響，比如在現(xiàn)有基礎(chǔ)上提升10-20%。

我們更期望數(shù)據(jù)的計(jì)算實(shí)時(shí)化，也就是將原有技術(shù)架構(gòu)中的批量計(jì)算（hive）變成實(shí)時(shí)計(jì)算（Flink SQL），架構(gòu)圖如下。
          

2.架構(gòu)演進(jìn)


架構(gòu)演進(jìn)

PyFlink在聚美優(yōu)品的應(yīng)用實(shí)踐是怎樣的

     

  • 第一層：最開始是離線計(jì)算，完成一次計(jì)算需要30分鐘，還不包括后續(xù)的模型處理;

  • 第二層：考慮實(shí)時(shí)計(jì)算后，我們打算采取 Flink 架構(gòu)來處理，整體主件過程如圖;

  • 第三層：考慮到人力和時(shí)間等成本，還有技術(shù)人員技能匹配度，最終選擇第三層;

   
我們成員更多的是對(duì) Python 和 SQL 熟悉，所以 PyFlink 更加適合我們。我們用   PyFlink    開發(fā)了    20    個(gè)業(yè)務(wù)作業(yè)，目前每秒  過百萬，每天有    200    億，業(yè)務(wù)平穩(wěn)運(yùn)行(P  yF  link    1.10)。

3.技術(shù)選型


面對(duì)實(shí)時(shí)化的業(yè)務(wù)和架構(gòu)升級(jí)需求，我們團(tuán)隊(duì)本身沒有 Spark、Flink 等框架的背景積累，但是一個(gè)偶然的機(jī)會(huì)，我們觀看了金竹老師的直播，了解到了 PyFlink 是 Flink 的 Python API 和我團(tuán)隊(duì)現(xiàn)有的開發(fā)人員語言技能比較吻合。所以就想利用 PyFlink 進(jìn)行業(yè)務(wù)的實(shí)時(shí)化升級(jí)。

初識(shí)與困難

雖然 PyFlink 和團(tuán)隊(duì)的語言技能比較 match，但是其中還是涉及到很多 Flink 的環(huán)境、文檔、算子等的使用問題，遇到了很多困難：

  • PyFlink 的知識(shí)文檔、示例、答疑等都非常少，除了官網(wǎng)和阿里云，基本無其他參考。

  • PyFlink 官方文檔缺少很多細(xì)節(jié)，比如：給了方法不給參數(shù)格式。

  • PyFlink 的內(nèi)容不明確，官網(wǎng)上沒有明確具體寫出哪些 PyFlink 沒有，哪些有。沒法將 Flink 和 PyFlink 清晰的區(qū)分開。

  • PyFlink 本身等局限性，比如:left/rigint Join 產(chǎn)生 retraction 無法寫入 Kafka，要寫入需要改寫 Flink SQL 讓流改為 append 模式，或者修改 kafka-connector 源碼支持 retraction。


所以一時(shí)感覺利用 PyFlink 的學(xué)習(xí)時(shí)間也比較漫長(zhǎng)。大家比較擔(dān)心短時(shí)間內(nèi)很難滿足業(yè)務(wù)開發(fā)。
 
機(jī)遇

在我和團(tuán)隊(duì)擔(dān)心開發(fā)進(jìn)度時(shí)候，我也一直關(guān)注 Flink 社區(qū)的動(dòng)態(tài)，恰巧發(fā)現(xiàn) Flink 社區(qū)在進(jìn)行 “PyFlink 扶持計(jì)劃”，所以我和團(tuán)隊(duì)都眼前一亮，填寫了 PyFlink 調(diào)查問卷。也和金竹老師進(jìn)行了幾次郵件溝通。最終有幸參與了 PyFlink 社區(qū)扶持計(jì)劃。
 

4. OOM 報(bào)錯(cuò)解決思路分享


其實(shí)了解下來 PyFlink 的開發(fā)是非常便捷的，在完成了第一個(gè)作業(yè)的開發(fā)之后，大家逐漸熟悉 PyFlink 的使用，3周左右就完成了 20 個(gè)業(yè)務(wù)邏輯的開發(fā)，進(jìn)入了測(cè)試階段。這個(gè)快速一方面是團(tuán)隊(duì)成員不斷的熟悉 PyFlink，一方面是由社區(qū) PyFlink 團(tuán)隊(duì)金竹/付典等老師的幫助和支持。這里，不一一為大家分享全部?jī)?nèi)容，我這里列舉一個(gè)具體的例子。

■ 背景：  

從接觸到 Flink 開始，有個(gè)別 job，一直有 running beyond physical memory limits 問題。多次調(diào)整 tm 內(nèi)存，修改 tm 和 slos 的比例，都沒用，最終還是會(huì)掛。最后妥協(xié)的方案是，增加自動(dòng)重啟次數(shù)，定期重啟任務(wù)

■ 現(xiàn)象：  

Flink job 通常會(huì)穩(wěn)定運(yùn)行5-6天，然后就報(bào)出這個(gè)錯(cuò)誤。一直持續(xù)和反復(fù)。

■ 詳細(xì)信息：  

Closing TaskExecutor connection container_e36_1586139242205_122975_01_000011 because: Container [pid=45659,containerID=container_e36_1586139242205_122975_01_000011] is running beyond physical memory limits. Current usage: 4.0 GB of 4 GB physical memory used; 5.8 GB of 32 GB virtual memory used. Killing container.    Dump of the process-tree for container_e36_1586139242205_122975_01_000011 :    |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE    |- 45659 45657 45659 45659 (bash) 0 0 115814400 297 /bin/bash -c /usr/local/jdk//bin/java -Xms2764m -Xmx2764m -XX:MaxDirectMemorySize=1332m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/test.bin -Dlog.file=/data/emr/yarn/logs/application_1586139242205_122975/container_e36_1586139242205_122975_01_000011/taskmanager.log -Dlogback.configurationFile=file:./logback.xml -Dlog4j.configuration=file:./log4j.properties org.apache.flink.yarn.YarnTaskExecutorRunner --configDir . 1> /data/emr/yarn/logs/application_1586139242205_122975/container_e36_1586139242205_122975_01_000011/taskmanager.out 2> /data/emr/yarn/logs/application_1586139242205_122975/container_e36_1586139242205_122975_01_000011/taskmanager.err     |- 45705 45659 45659 45659 (java) 13117928 609539 6161567744 1048471 /usr/local/jdk//bin/java -Xms2764m -Xmx2764m -XX:MaxDirectMemorySize=1332m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/test.bin -Dlog.file=/data/emr/yarn/logs/application_1586139242205_122975/container_e36_1586139242205_122975_01_000011/taskmanager.log -Dlogback.configurationFile=file:./logback.xml -Dlog4j.configuration=file:./log4j.properties org.apache.flink.yarn.YarnTaskExecutorRunner --configDir .
    Container killed on request. Exit code is 143    Container exited with a non-zero exit code 143

我們的解決思路：

        1. 從內(nèi)容上看是 oom 問題，所以一開始調(diào)整了 tm 大小，直接到最大內(nèi)存，2調(diào)整 tm 和 slot 的比例，盡量做到 1v1.
        2. dump heap 的內(nèi)存，分析占用情況。
        3. 調(diào)整 backend state 的類型

結(jié)果：以上手段都失敗了，在持續(xù)一段時(shí)間后，依然一定報(bào)錯(cuò)。

PyFlink 團(tuán)隊(duì)處理思路：

1.分析當(dāng)前作業(yè)的 state 情況，作業(yè)情況，作業(yè)環(huán)境參數(shù)情況  。通過 flink-conf 可以看 backend state 情況，通過 flinkdashboard 可以知道作業(yè)圖和環(huán)境參數(shù)。
 
2. 由于 1.10 中，rocksdb statebackend 占用的內(nèi)存默認(rèn)為非 managed memory，通過在 PyFlink 作業(yè)中增加如下代碼，可以將其設(shè)置為 managed memory：env.get_state_backend()._j_rocks_db_state_backend.getMemoryConfiguration().setUseManagedMemory(True)
 
3. 為了分析 OOM 是否是由于 rocksdb statebackend 占用的內(nèi)存持續(xù)增長(zhǎng)導(dǎo)致的，開啟了關(guān)于 rocksdb 的監(jiān)控，因?yàn)槲覀兪褂玫氖?rocksdb，這里需要在 flink-conf 中增加如下配置：

state.backend.rocksdb.metrics.block-cache-capacity: truestate.backend.rocksdb.metrics.block-cache-usage: true                            state.backend.rocksdb.metrics.num-running-compactions: truestate.backend.rocksdb.metrics.num-running-flushes: truestate.backend.rocksdb.metrics.size-all-mem-tables: true
 
然后通過自建的 metrics 系統(tǒng)來收集展示和分析，我們使用的 grafana。
 
4. 通過前面的步驟，觀察到 rocksdb 的內(nèi)存基本是穩(wěn)定的，內(nèi)存占用符合預(yù)期，懷疑是“rocksdb 超用了一點(diǎn)點(diǎn)，或者是 jvm overhead 不夠大”導(dǎo)致的。這兩種問題，都可以通過調(diào)整 jvm overhead 的相關(guān)參數(shù)來解決。于是在 flink-conf 中添加了配置：

taskmanager.memory.jvm-overhead.min: 1024m
taskmanager.memory.jvm-overhead.max: 2048m

用大佬的原話：rocksdb 超用了一點(diǎn)點(diǎn)，或者是 jvm overhead 不夠大，這兩種情況調(diào)大 jvm overhead 應(yīng)該都能解決。
 
5. 調(diào)整 flink.size 的大小，讓 flink 自動(dòng)計(jì)算出 process.size，這部分在 flink-conf:
               
taskmanager.memory.flink.size: 1024m
 
完成所有調(diào)整后，經(jīng)歷了14天的等待，job 運(yùn)行正常，這里充分說明了問題被解決了。同時(shí)開始觀察 rocksdb 的 metrics 情況，發(fā)現(xiàn) native 內(nèi)存會(huì)超用一些，但是 rocksdb 整體保持穩(wěn)定的。目前能判斷出某個(gè)地方用到的 native 內(nèi)存比 flink 預(yù)留的多，大概率是用戶代碼或者第三方依賴，所以加大下 jvm-overhead 大數(shù)值，能解決問題。
 
6. 最終需要修改的參數(shù)有:

1) 在 pyflink 作業(yè)中增加如下代碼：
   
env.get_state_backend()._j_rocks_db_state_backend.getMemoryConfiguration().setUseManagedMemory(True)
          
2) flink-conf 修改或增加：

taskmanager.memory.jvm-overhead.min: 1024mtaskmanager.memory.jvm-overhead.max: 2048mtaskmanager.memory.process.size: 6144m

其實(shí)針對(duì)這個(gè)業(yè)務(wù)升級(jí)，老板為了不影響最終的業(yè)務(wù)上線，起初我們準(zhǔn)備了2套方案同時(shí)進(jìn)行：

  • 基于某個(gè)云平臺(tái)進(jìn)行平臺(tái)搭建和開發(fā)；

  • 基于開源 PyFlink 進(jìn)行代碼開發(fā)；


兩個(gè)方案同時(shí)進(jìn)行，最終我們團(tuán)隊(duì)基于 PyFlink 開發(fā)快速的完成了業(yè)務(wù)開發(fā)和測(cè)試。最終達(dá)到了我前面所說的每秒百萬/每天200億的穩(wěn)定業(yè)務(wù)支撐。
重點(diǎn)，重點(diǎn)，重點(diǎn)，參與這個(gè)業(yè)務(wù)升級(jí)的開發(fā)只有2個(gè)人。
 

5.總結(jié)和展望


通過 PyFlink 的學(xué)習(xí)，刷寶大數(shù)據(jù)團(tuán)隊(duì)，在短時(shí)間能有了實(shí)時(shí)數(shù)據(jù)開發(fā)的能力。目前穩(wěn)定運(yùn)行了 20+PyFlink 任務(wù)，我們對(duì)接了多個(gè)需求部門，如推薦部門、運(yùn)營(yíng)、廣告等;在多種場(chǎng)景下，模型畫像計(jì)算、AB 測(cè)試系統(tǒng)、廣告推薦、用戶召回系統(tǒng)等，使用了 PyFlink。為我們的業(yè)務(wù)提供了堅(jiān)實(shí)穩(wěn)定的實(shí)時(shí)數(shù)據(jù)。此外，我們將搭建 Flink on Zeppelin 這樣的實(shí)時(shí)計(jì)算平臺(tái)，擴(kuò)大 Flink 開發(fā)用戶群體，進(jìn)一步簡(jiǎn)化 Flink 開發(fā)成本。Flink 1.11 版本也準(zhǔn)備上線，Python UDF 功能會(huì)有進(jìn)一步的優(yōu)化，Pandas 模塊也會(huì)被引入。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。

網(wǎng)站欄目：PyFlink在聚美優(yōu)品的應(yīng)用實(shí)踐是怎樣的
文章鏈接：http://chinadenli.net/article14/gepide.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、網(wǎng)站設(shè)計(jì)公司、網(wǎng)頁設(shè)計(jì)公司、動(dòng)態(tài)網(wǎng)站、網(wǎng)站改版、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

成都定制網(wǎng)站建設(shè)