2. 程式人生 > >滴滴實時計算髮展之路及平臺架構實踐

滴滴實時計算髮展之路及平臺架構實踐

阿新 • • 發佈：2019-11-05

toc: true
title: 滴滴實時計算髮展之路及平臺架構實踐
date: 2019-08-25
tags:

  • Flink

  • 大資料

滴滴的核心業務是一個實時線上服務，因此具有豐富的實時資料和實時計算場景。本文將介紹滴滴實時計算髮展之路以及平臺架構實踐。

實時計算演進

隨著滴滴業務的發展，滴滴的實時計算架構也在快速演變。到目前為止大概經歷了三個階段：

  • 業務方自建小叢集階段；

  • 集中式大叢集、平臺化階段；

  • SQL化階段。

下圖示識了其中重要的里程碑，稍後會給出詳細闡述：

在2017年以前，滴滴並沒有統一的實時計算平臺，而是各個業務方自建小叢集。其中用到的引擎有Storm、JStorm、Spark Streaming、Samza等。業務方自建小叢集模式存在如下弊端：

  • 需要預先採購大量機器，由於單個業務獨佔，資源利用率通常比較低；

  • 缺乏有效的監控報警體系；

  • 維護難度大，需要牽涉業務方大量精力來保障叢集的穩定性；

  • 缺乏有效技術支援，且各自沉澱的東西難以共享。

為了有效解決以上問題，滴滴從2017年年初開始構建統一的實時計算叢集及平臺。

技術選型上，我們基於滴滴現狀選擇了內部用大規模資料清洗的Spark Streaming引擎，同時引入On-YARN模式，並利用YARN的多租戶體系構建了認證、鑑權、資源隔離、計費等機制。

相對於離線計算，實時計算任務對於穩定性有著更高的要求，為此我們構建了兩層資源隔離體系：

  • 第一層是基於CGroup做程序（Container）級別的CPU及記憶體隔離；

  • 第二層是物理機器級別的隔離。

我們通過改造YARN的FairScheduler使其支援Node Label。達到的效果如下圖所示：

普通業務的任務混跑在同一個Label機器上，而特殊業務的任務跑在專用Label的機器上。

通過集中式大叢集和平臺化建設，基本消除了業務方自建小叢集帶來的弊端，實時計算也進入了第二階段。

伴隨著業務的發展，我們發現Spark Streaming的Micro Batch模式在一些低延時的報警業務及線上業務上顯得捉襟見肘。於是我們引入了基於Native Streaming模式的Flink作為新一代實時計算引擎。

Flink不僅延時可以做到毫秒級，而且提供了基於Process Time/Event Time豐富的視窗函式。基於Flink我們聯合業務方構架了滴滴流量最大的業務閘道器監控系統，並快速支援了諸如乘客位置變化通知、軌跡異常檢測等多個線上業務。

實時計算平臺架構

為了最大程度方便業務方開發和管理流計算任務，我們構建瞭如圖所示的實時計算平臺：

在流計算引擎基礎上提供了StreamSQL IDE、監控報警、診斷體系、血緣關係、任務管控等能力。各自的作用如下：

  • StreamSQL IDE。下文會介紹，是一個Web化的SQL IDE；

  • 監控報警。提供任務級的存活、延時、流量等監控以及基於監控的報警能力；

  • 診斷體系。包括流量曲線、Checkpoint、GC、資源使用等曲線檢視，以及實時日誌檢索能力。

  • 血緣關係。我們在流計算引擎中內建了血緣上報能力，進而在平臺上呈現流任務與上下游的血緣關係；

  • 任務管控。實現了多租戶體系下任務提交、啟停、資產管理等能力。通過Web化任務提交消除了傳統客戶機模式，使得平臺入口完全可控，內建引數及版本優化得以快速上線。

實時規則匹配服務建設

在滴滴內部有大量的實時運營場景，比如“某城市乘客冒泡後10秒沒有下單”。針對這類檢測事件之間依賴關係的場景，用Fink的CEP是非常合適的。

但是社群版本的CEP不支援描述語言，每個規則需要開發一個應用，同時不支援動態更新規則。為了解決這些問題，滴滴做了大量功能擴充套件及優化工作。功能擴充套件方面主要改動有：

  • 支援wait運算元。對於剛才例子中的運營規則，社群版本是表達不了的。滴滴通過增加wait運算元，實現了這類需求；

  • 支援DSL語言。基於Groovy和Aviator解析引擎，我們實現瞭如下圖所示的DSL描述規則能力：

  • 單任務多規則及規則動態更新。由於實時運營規則由一線運營同學來配置，所以規則數量，規則內容及規則生命週期會經常發生變化。這種情況每個規則一個應用是不太現實的。為此我們開發了多規則模式且支援了動態更新。

除了功能拓展之外，為了應對大規模運營規則的挑戰，滴滴在CEP效能上也做了大量優化，主要有：

  • SharedBuffer重構。基於Flink MapState重構SharedBuffer，減少每次資料處理過程中的狀態互動。同時剝離規則和使用者資料極大降低每次匹配的時候從狀態中反序列化的資料量；

  • 增加訪問快取（已貢獻社群）。快取SharedBuffer資料中每次處理所需要更新的引用計數，延緩更新；

  • 簡化event time語義處理。避免key在很分散情況下每次watermark更新時要遍歷所有key的資料；

  • 複用conditionContext（已貢獻社群）。減少條件查詢時對partialMatch元素的反覆查詢。

以上優化將CEP效能提升了多個數量級。配合功能擴充套件，我們在滴滴內部提供瞭如圖所示的服務模式：

業務方只需要清洗資料並提供規則列表API即可具備負責規則的實時匹配能力。

目前滴滴CEP已經在快車個性化運營、實時異常工單檢測等業務上落地，取得了良好的效果。

StreamSQL建設

正如離線計算中Hive之於MapReduce一樣，流式SQL也是必然的發展趨勢。通過SQL化可以大幅度降低業務方開發流計算的難度，業務方不再需要學習Java/Scala，也不需要理解引擎執行細節及各類引數調優。

為此我們在2018年啟動了StreamSQL建設專案，在社群Flink SQL基礎上拓展了以下能力：

擴充套件DDL語法。如下圖所示，打通了滴滴內部主流的訊息佇列以及實時儲存系統(StreamSQL內建打通訊息佇列及實施儲存)：

  • 通過內建常見訊息格式（如json、binlog、標準日誌）的解析能力，使得使用者可以輕鬆寫出DDL語法，並避免重複寫格式解析語句。

  • 拓展UDF。針對滴滴內部常見處理邏輯，內建了大量UDF，包括字串處理、日期處理、Map物件處理、空間位置處理等。

  • 支援分流語法。單個輸入源多個輸出流在滴滴內部非常常見，為此我們改造了Calcite使其支援分流語義。

  • 支援基於TTL的join語義。傳統的Window Join因為存在window邊界資料突變情況，不能滿足滴滴內部的需求。為此我們引入了TTL State，並基於此開發了基於TTL Join的雙流join以及維表join。

  • StreamSQL IDE。前文提到平臺化之後我們沒有提供客戶機，而是通過Web提交和管控任務。因此我們也相應開發了StreamSQL IDE，實現Web上開發StreamSQL，同時提供了語法檢測、DEBUG、診斷等能力。

目前StreamSQL在滴滴已經成功落地，流計算開發成本得到大幅度降低。預期未來將承擔80%的流計算業務量。

總結

作為一家出行領域的網際網路公司，滴滴對實時計算有天然的需求。

過去的一年多時間裡，我們從零構建了集中式實時計算平臺，改變了業務方自建小叢集的局面。為滿足低延時業務的需求，成功落地了Flink Streaming，並基於Flink構建了實時規則匹配（CEP）服務以及StreamSQL，使得流計算開發能力大幅度降低。未來將進一步拓展StreamSQL，並在批流統一、IoT、實時機器學習等領域探索和建設。

關注我

微信公眾號：zhisheng

另外我自己整理了些 Flink 的學習資料，目前已經全部放到微信公眾號（zhisheng）了，你可以回覆關鍵字：Flink 即可無條件獲取到。另外也可以加我微信 你可以加我的微信：yuanblog_tzs，探討技術！

更多私密資料請加入知識星球！

Github 程式碼倉庫

https://github.com/zhisheng17/flink-learning/

以後這個專案的所有程式碼都將放在這個倉庫裡，包含了自己學習 flink 的一些 demo 和部落格

部落格

1、Flink 從0到1學習 —— Apache Flink 介紹

2、Flink 從0到1學習 —— Mac 上搭建 Flink 1.6.0 環境並構建執行簡單程式入門

3、Flink 從0到1學習 —— Flink 配置檔案詳解

4、Flink 從0到1學習 —— Data Source 介紹

5、Flink 從0到1學習 —— 如何自定義 Data Source ？

6、Flink 從0到1學習 —— Data Sink 介紹

7、Flink 從0到1學習 —— 如何自定義 Data Sink ？

8、Flink 從0到1學習 —— Flink Data transformation(轉換)

9、Flink 從0到1學習 —— 介紹 Flink 中的 Stream Windows

10、Flink 從0到1學習 —— Flink 中的幾種 Time 詳解

11、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 ElasticSearch

12、Flink 從0到1學習 —— Flink 專案如何執行？

13、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 Kafka

14、Flink 從0到1學習 —— Flink JobManager 高可用性配置

15、Flink 從0到1學習 —— Flink parallelism 和 Slot 介紹

16、Flink 從0到1學習 —— Flink 讀取 Kafka 資料批量寫入到 MySQL

17、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 RabbitMQ

18、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 HBase

19、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 HDFS

20、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 Redis

21、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 Cassandra

22、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 Flume

23、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 InfluxDB

24、Flink 從0到1學習 —— Flink 讀取 Kafka 資料寫入到 RocketMQ

25、Flink 從0到1學習 —— 你上傳的 jar 包藏到哪裡去了

26、Flink 從0到1學習 —— 你的 Flink job 日誌跑到哪裡去了

27、阿里巴巴開源的 Blink 實時計算框架真香

28、Flink 從0到1學習 —— Flink 中如何管理配置？

29、Flink 從0到1學習—— Flink 不可以連續 Split(分流)？

30、Flink 從0到1學習—— 分享四本 Flink 國外的書和二十多篇 Paper 論文

31、Flink 架構、原理與部署測試

32、為什麼說流處理即未來？

33、OPPO 資料中臺之基石：基於 Flink SQL 構建實時資料倉庫

34、流計算框架 Flink 與 Storm 的效能對比

35、Flink狀態管理和容錯機制介紹

36、Apache Flink 結合 Kafka 構建端到端的 Exactly-Once 處理

37、360深度實踐：Flink與Storm協議級對比

38、如何基於Flink+TensorFlow打造實時智慧異常檢測平臺？只看這一篇就夠了

39、Apache Flink 1.9 重大特性提前解讀

40、Flink 全網最全資源（視訊、部落格、PPT、入門、原理、實戰、效能調優、原始碼解析、問答等持續更新）

41、Flink 靈魂兩百問，這誰頂得住？

42、Flink 從0到1學習 —— 如何使用 Side Output 來分流？

43、你公司到底需不需要引入實時計算引擎？

44、一文讓你徹底瞭解大資料實時計算引擎 Flink

原始碼解析

1、Flink 原始碼解析 —— 原始碼編譯執行

2、Flink 原始碼解析 —— 專案結構一覽

3、Flink 原始碼解析—— local 模式啟動流程

4、Flink 原始碼解析 —— standalone session 模式啟動流程

5、Flink 原始碼解析 —— Standalone Session Cluster 啟動流程深度分析之 Job Manager 啟動

6、Flink 原始碼解析 —— Standalone Session Cluster 啟動流程深度分析之 Task Manager 啟動

7、Flink 原始碼解析 —— 分析 Batch WordCount 程式的執行過程

8、Flink 原始碼解析 —— 分析 Streaming WordCount 程式的執行過程

9、Flink 原始碼解析 —— 如何獲取 JobGraph？

10、Flink 原始碼解析 —— 如何獲取 StreamGraph？

11、Flink 原始碼解析 —— Flink JobManager 有什麼作用？

12、Flink 原始碼解析 —— Flink TaskManager 有什麼作用？

13、Flink 原始碼解析 —— JobManager 處理 SubmitJob 的過程

14、Flink 原始碼解析 —— TaskManager 處理 SubmitJob 的過程

15、Flink 原始碼解析 —— 深度解析 Flink Checkpoint 機制

16、Flink 原始碼解析 —— 深度解析 Flink 序列化機制

17、Flink 原始碼解析 —— 深度解析 Flink 是如何管理好記憶體的？

18、Flink Metrics 原始碼解析 —— Flink-metrics-core

19、Flink Metrics 原始碼解析 —— Flink-metrics-datadog

20、Flink Metrics 原始碼解析 —— Flink-metrics-dropwizard

21、Flink Metrics 原始碼解析 —— Flink-metrics-graphite

22、Flink Metrics 原始碼解析 —— Flink-metrics-influxdb

23、Flink Metrics 原始碼解析 —— Flink-metrics-jmx

24、Flink Metrics 原始碼解析 —— Flink-metrics-slf4j

25、Flink Metrics 原始碼解析 —— Flink-metrics-statsd

26、Flink Metrics 原始碼解析 —— Flink-metrics-prometheus

26、Flink Annotations 原始碼解析

27、Flink 原始碼解析 —— 如何獲取 ExecutionGraph ？

28、大資料重磅炸彈——實時計算框架 Flink

29、Flink Checkpoint-輕量級分散式快照

30、Flink Clients 原始碼解析
原文出處：zhisheng的部落格，歡迎關注我的公眾號：zhish

相關推薦

滴滴實時計算髮展之路及平臺架構實踐

toc: true title: 滴滴實時計算髮展之路及平臺架構實踐 date: 2019-08-25 tags: Flink 大資料 滴滴的核心業務是一個實時線上服務，因此具有豐富的實時資料和實時計算場景。本文將介紹滴滴實時計算髮展之路以及平臺架構實踐。 實時計算演進 隨著滴滴業務的發展，滴滴的實時

計算機器前傳：結繩、算籌、算盤等手動計算髮展史(公號回覆“手動計算”下載PDF資料，歡迎轉發、讚賞、支援科普)

科學Sciences導讀：計算機前傳之結繩、算籌、算盤等手動計算，到加法機、乘法機、分析機等機械計算，重點講述算盤和機械加法機的原理，展示分析機複雜圖樣。本期鋪墊，下期紙帶機、電傳紙帶機、單任務電子計算機是理解圖靈機、圖靈完備理論基礎之一和實物背景知識。此文為“科學Sciences”公號作業系統

e訊丨中國信通院釋出《雲計算髮展白皮書（2018年）》（附PPT解讀）

目錄 一、雲端計算市場發展狀況及分析 （一）全球雲端計算市場規模及發展趨勢 （二）我國雲端計算市場規模及發展趨勢 （三）雲計算髮展熱點分析 二、雲端計算技術發展特點 （一）GPU雲化降低高效能運算使用門檻 （二）服務網格開啟微服務架構新階段 （三）無服

工信部印發：《雲計算髮展三年行動計劃（2017-2019年）》

發文機關：工業和資訊化部 標　　題：工業和資訊化部關於印發《雲計算髮展三年行動計劃（2017-2019年）》的通知 發文字號：工信部信軟〔2017〕49號 成文日期：2017-04-06 釋出日期：2017-04-10 文章來源：工業和資訊化部 分　　類：資訊化和軟體服務 《工業和資訊化部關於印發

閒話雲端計算(一) 雲計算髮展史

說到雲計算曆史，很多人腦海裡第一個彈出的詞就是AWS（Amazon Web Service，亞馬遜推出的雲端計算服務）。的確，AWS是目前為止商業上最成功的雲端計算公司，也是業界的一個標杆，以至於很多IT業內人士提起亞馬遜，首先冒出的概念就是這是一家雲端計算公司，但卻忘了亞馬遜的老本行是電子商務。在

運營商雲計算髮展戰略探討

文/朱行健 李常偉 　　雲端計算使全球ICT產業出現重整機會窗，各方勢力紛紛發力佈局雲端計算。對運營商而言，面對日益滯漲的傳統電信市場，發力雲端計算和ICT服務是實現未來持續增長的大好機會，實現管道運營向資訊服務運營的轉型。華為作為運營商的長期戰略合作伙伴，將充分發揮和

不管人工智慧和雲計算髮展如何，程式設計師受益最大

繼阿里、騰訊、金山、美團等相繼宣佈“AI雲平臺“戰略後，華為也高調宣佈：”將與在計算機視覺領域的大佬英偉達展開深度合作，在人工智慧、機器學習、深度學習方面共同構建公有云AI平臺。無獨有偶，近日雲端計算廠商UCloud也被曝出，成為由創新工場、搜狗和今日頭條聯合宣

關於美國聯邦政府的雲計算髮展戰略

Turnaround or terminate at least one-third of underperforming projects in IT portfolio within the next 18 months.

實時計算-多級訂單金額，及下級人數

1 系統概述 人物關係為代理模式，一級代理包含二級代理，二級代理包含三級代理。 需求為實時計算每個使用者的訂單金額，並取出金額的TOP100。 並實時計算當天下級人數。 1.1 指標使用方式 單使用者訂單列表查詢：查詢訂單表，不限定日期。 當天訂單額top100：查詢指標表對金額排序取前100

滴滴資料通道服務演進之路

![](https://img2020.cnblogs.com/other/1632886/202008/1632886-20200826153328287-1441500352.png) ![](https://img2020.cnblogs.com/other/1632886/202008/1632886

架構師之路：一個架構師需要掌握的知識技能

沒有設計的思想，你就不能成為一名架構師。架構師是一個能擼的了一手好程式碼，畫的了一個漂亮的UML/原型，寫的了一篇技術文件，更加能解決好專案關鍵技術的綜合人才。架構師=前端工程師+後端程式設計師+系統分析師+關鍵技術解決+各種技術搭配+設計模式+部署調優+其他，可見架構師是多面手，在專案當中起到連線

架構師之路---資料庫水平切分實踐

本人一應屆生，在去實習的地鐵上，看了一篇沈劍老師寫資料庫水平切分架構思路，看完人清氣爽。現在寫一篇部落格記錄下。 引言： 涉及到資料庫水平切分問題，主要有以下兩種問題： 第一：專案開始之前進行資料庫架構設計，考核，規劃以後資料庫量大的情況有很好的擴充套

演算法工程師修仙之路：推薦系統實踐（一）

第一章 好的推薦系統 什麼是推薦系統 隨著資訊科技和網際網路的發展，人們逐漸從資訊匱乏的時代走入了資訊過載（information overload）的時代。在這個時代，無論是資訊消費者還是資訊生產者都遇到了很大的挑戰：作為資訊消費者，如何從大量資訊中找到自己感興趣的

打字指法 學習糾正之路（平臺推薦）

打字指法 學習糾正之路（平臺推薦） 難受了 今天被企業老師說了，不是因為技術，原因盡然是，，打字指法看著彆扭。 之前也曾多次想過改變，但是都堅持不下來，因為習慣是很難改掉的，有不知有多少人還有這樣的苦惱。 但是不想以後影響更大，寫篇部落格，下決心改變！ 於是，在網上搜

【程式設計師的遊戲開發之路】 遊戲架構

啊啊啊啊今天去面了鵝廠，結果在實習公司Unity用得太多了，好多基礎都忘得差不多了，看起來要撿起來好好再學習一下O(∩_∩)O莫要放棄，就從遊戲架構開始學起哈。 參考的書是《 遊戲程式設計權威指南 》 遊戲整體架構 總體來說，遊戲中的所有子系統屬於以下

架構師之路(一)-網際網路架構的"高併發"

一、什麼是高併發 高併發（High Concurrency）是網際網路分散式系統架構設計中必須考慮的因素之一，它通常是指，通過設

Sloth：網易流計算服務化平臺架構實踐

網易經歷了多年的發展，眾多業務線沉澱了豐富的資料。大資料平臺除了滿足各業務線的資料儲存、計算需求，還負責集團資料整合，提供全方位的大資料服務。 本文PPT重點分享網易大資料基於Flink研發的流計算服務化平臺Sloth，以SQL為主要開發方式，支援DDL，支援豐富的DML，如Join、Window，支援UD

雲計算之路-虛擬化環境搭建及虛擬機創建

home 應用虛擬化 鍵盤 參考 紅色 翻譯 靈活性 不能 ont 轉載自 靈躍雲 ：原文鏈接 1. 前言 在計算機技術中，虛擬化(Virtualization)是一種資源管理技術，它將計算機相關的各種資源（CPU、內存、磁盤、網絡適配器等）進行抽象、轉換

雲端計算之路-虛擬化環境搭建及虛擬機器建立

1. 前言 在計算機技術中，虛擬化(Virtualization)是一種資源管理技術，它將計算機相關的各種資源（CPU、記憶體、磁碟、網路介面卡等）進行抽象、轉換後重新分配使用，大大增加了使用的靈活性。虛擬化有很多類別，包括硬體虛擬化、作業系統級虛擬化、應用虛擬化、服務

滴滴的大資料計算平臺演進之路

滴滴出行作為一家出行領域的網際網路公司，其核心業務是一個實時線上服務。因此具有豐富的實時資料和實時計算場景。本文將介紹滴滴實時計算髮展之路以及平臺架構實踐。 實時計算演進 隨著滴滴業務的發展，滴滴的實時計算架構也在快速演變。到目前為止大概經歷了三個階段，第一階段是業務方自建小叢集；第二階段是