城市級實時計算的力量

做者：閔萬里

整理：趙慧

本文整理自閔萬里博士在Flink Forward China 2018上的演講。

城市中,像上圖空中小麻雀同樣的攝像頭遍及各地，地面上的車流川流不息，高德地圖等APP經過技術手段採集了愈來愈多的攝像頭、車流的數據。但空中與地面這兩條平行的河流，彷佛永遠沒有交匯的時刻。愈來愈多的攝像頭採集數據，但道路卻愈來愈擁堵,這偏偏反映出智慧的缺失。

三年前，當咱們從新審視「智慧城市」這個概念的時候想到：在這個數據量很大，上下游特別多的典型場景，可否用最新的技術，從新在技術上把它往前推動一步？因而城市大腦應運而生。而今天，城市大腦不只走進城市，還走進了各個垂直產業，如：製造業、零售業。這些行業都有一個鮮明的特色：擁有至關密集的數據流。

Date Flow Intensive若是須要作到更加智慧，首先須要很是強大的Computational power；第二是須要更加智能的算法處理實時數據流。當這兩種能力放在一塊兒的時候，數據不只僅能夠用來作過後分析追責，並且擁有了實時解決當下問題的能力，甚至能夠把將來可能出現的問題作預先介入，提早化解。這個過程當中離不開優秀的計算引擎，所以，今天， Apache Flink 技術有很是具體的能夠落地的實戰的場景，並且是能夠量化價值的場景。

接下來給你們一 一介紹幾個場景，帶領各位更有體感地瞭解：代碼，是怎麼給老百姓創造價值的？

首先，咱們要了解的問題是如何衡量技術的價值？不管多麼領先的技術，最終要回歸到上圖這個公式當中，公式右邊的三個要素分別爲：行業知識、技術和已經沉澱的數據（包括正在發生的數據），這三個要素帶來的是左邊能夠量化的價值。

今天，城市大腦要作的事就是把包括 Flink 在內最早進的技術填到這個公式當中。找準行業，找到痛點，而後去產生左邊可量化的價值增量，而非價值存量。如今，咱們推出了一系列的ET大腦，它們到底是如何運行的？如何從流計算的角度把它從一個理想的 Design 變成了一個在生產過程中能夠用起來的System ？接下來，咱們將一一爲你們解答。

在這個架構圖中你們能夠看到 ET 大腦底層有各式混合調度等基礎技術系統，中間層是用Flink的方式對結構化、非結構化甚至半結構化的數據，作混合的雙流、多種流的實時Join。

上圖是2018年9月份正式公佈的杭州城市大腦2.0，今天，在杭州420平方千米的土地上，有着近1300個的路口，不管是天上的攝像頭，仍是地下傳感器的線圈，產生的數據都是經過實時流計算的方式收集到城市大腦當中，並進行實時的處理。某種程度上來講，咱們把城市想象爲一個生命體，經過每個毛細血管（傳感器）傳遞來的實時流數據，咱們得以精準地瞭解這個智慧體的每一次脈搏，而這背後就是計算的威力。

這張圖從左往右看，從最外場的卡口攝像頭以及傳感器用於採集過車速度、車牌類型等數據，這些數據實時進入Flink計算引擎以後在RDS當中Dim Table 進行彙總，彙總後咱們能夠獲得一個移動的時間窗口（Hop Window）。這個時間窗口的長度大概是15分鐘，每隔兩分鐘咱們就把它往將來移動一次，所以，你會發現這個時間窗口每兩分鐘就會產生一次過去15分鐘內所統計到的數據。

這是一個典型的Batch 和 Streaming結合的案例，經過這些 Table 的 join後，咱們能夠獲得在每個路段上過去幾分鐘內，過車通行量、過車速度以及道路佔有率、飽和度等等，這些都是交通工程中至關重要的參數。過去只能經過傳感器來獲取。而如今，攝像頭、傳感器、高德APP的數據將所有進行彙總計算，單一渠道帶來的數據不肯定性問題，經過三流合一獲得了有效彌補。

如今在杭州交警指揮中心所收到的報警當中，95%的來源並不是人工，是城市大腦從海量流數據當中混合調度任務進行計算，並實時同步給交警指揮中心而來的。

這個過程當中有各類各樣的 Group Aggregation、Window Aggregation，咱們設定了一個移動的窗口，它有固定的長度，可是在不斷地移動，至關於掃描系統，在掃各個流上面的事件。甚至是幾個流合一以後的事件流，咱們看上下兩個點位（攝像頭）、上下三個點位，上下四個點位之間是否造成了某一輛車的特定事件，好比持續的闖紅燈、持續超速等等，這些都要實時計算出結果並馬上同步，而這些數據 Join 到最後會獲得什麼呢？假設咱們在某一個匝道上開車，出現了大面積的排隊現象，如今經過城市大腦同步到指揮中心，基本能夠實現所有自動化的處理，不再須要靠過去靠指揮中心呼叫機的方式來處理。 因此，流對流之間再也不是對牛彈琴，取而代之的是無縫的握手銜接，實現總體系統效率的提高。系統效率提高以後帶來了什麼好處？給你們看下面這一個案例：

2018年7月份，城市大腦落地馬來西亞吉隆坡，經過城市大腦，救護車的行駛時間壓縮了48.9%。經過上圖你會看到，在這個案例當中，既要把救護車司機的位置信息，一秒內上傳一次，也要跟周邊信號燈之間的車流速度、車隊速度、排隊長度進行對比。精準地判斷幾點幾分幾秒，救護車將會到達哪一個路口，而後去計算所經路口變成綠燈的時間點。在這種模式下，不再須要像過去同樣讓交警鳴笛開道。

有時候一秒的時間對急救車來講就是生與死的差異。縮短48.9%的時間，就是公式最左邊能夠量化的價值。當有一天咱們可能要坐上救護車的時候，就會體會到這個沒法用金錢衡量的價值。這時候，技術也再也不那麼骨感，那麼枯燥，老百姓能夠真正感知到它的普惠。

今天咱們作的這些探索，包括團隊在過去幾年作的ET大腦的探索，在開始的時候實際上是很艱難的。團隊中有些人懂 Flink ，有些人懂其餘技術，內部也有過技術的爭論。但你們都有一個共同的目標：選擇最合適的技術、最合適的場景，去迅速拿到結果。

如今，還有不少有價值的場景等待咱們開發，可是咱們人數有限，所以，咱們但願能與更多的開發者們一塊兒參與到這件事情當中來，成爲生態的一部分，成爲25萬開發者中的一個（25萬是咱們建的一個大數據人才、大數據開發者、大數據科學家，來自全球93個國家的開發者生態）。

咱們的團隊用Flink取得了上述的成果。若是你也相信數據力量，歡迎你們一塊兒參與到這件事當中來，成爲25萬中的一份子，把25萬發展成250萬，作出更多48.9%的價值！

更多資訊請訪問 Apache Flink 中文社區網站