不了解邊緣計算，你可能就要被「邊緣」了

2018 年伊始，我們的朋友圈就被人工智慧、區塊鏈刷屏，但是朋友，不要忘記，下一個風口，物聯網必不可少。在這個萬物互聯、萬物智能的新時代，智能物聯網通過網路賦予萬物感知，在雲端形成大量數據，並通過智能化落地應用。

2018 年 1 月 18 日，百度雲天工發布國內首款邊緣計算產品「智能邊緣」，融合百度 ABC（AI、Big Data、Cloud），打造「一站式、全託管」的智能物聯網平台，提供從數據採集、傳輸、計算、存儲、展現到分析全系列物聯網基礎雲端服務，賦能合作夥伴與開發者構建各類智能物聯網應用。

4 月 21 日，由百度開發者中心、百度雲智學院主辦、極客邦科技承辦的第 78 期百度技術沙龍邀請了來自百度資深架構師百度雲物聯網部 TC 主席李樂丁，百度雲物聯網部高級產品經理黃淼，百度雲物聯網部前端開發工程師鍾姿艷三位講師，從端到雲，為大家解讀百度雲邊緣計算和百度雲物可視，探討 IoT 的應用場景和發展趨勢。

1

邊緣計算——物聯網的下一個主戰場

百度資深架構師、百度雲物聯網部 TC 主席李樂丁做了開場演講。他強調，百度雲物聯網部一直致力於讓互聯網使萬物互聯，讓雲使萬物賦予智能，讓複雜的生產生活變得更加簡單的理想。在過去的一年中，他們與各行各業進行深入合作和探索，積極提升企業的運行效率。

物聯網發展的新浪潮

物聯網在各個領域蓬勃發展，萬物互聯的時代漸行漸近。但是隨著業務的發展，逐漸發現基於公有雲中央數據中心的方式無法滿足很多場景的實際需求。例如，基於傳統設備連接中央伺服器，網路延遲和帶寬會產生巨大成本；隱私保護和合規性越來越重要；以及今天所用的很多設備在功率和網路條件上受到限制，而這些帶來的基本問題就是你的設備很可能無法通過網路即時連接到雲和中央伺服器。

雲上的物聯網解決方案

為了解決上述問題，百度雲提出了雲上的物聯網解決方案。上圖為百度雲天工整體架構，支持通過多種協議，將設備連接至雲端，使用天工智能物聯網平台的「一站式全託管」的平台服務。百度雲天工傳送門：

https://cloud.baidu.com/solution/iot/index.html

在端雲一體的時代，能不能提供新一代物聯網的方式在本地得到福利呢？百度雲就此進行了新的探索：邊緣計算——IntelliEdge。

IntelliEdge，智能邊緣計算服務

IntelliEdge，智能邊緣計算服務，以軟體的形式呈現。如上圖所示，設備分為兩個類型，一種類型稱之為是核心設備，安裝了 IntelliEdge 軟體，充當整個本地物聯網的中心；另一種類型為關聯設備，無論是車、生活設備、還是工業設備，都可以將消息傳遞到上面，實現消息的出發，並進行一系列的計算，發現設備的智能所在。但是這樣的 IntelliEdge 也不可能完全將雲和一些設備的隔離，於是百度雲將核心設備與雲進行連通，經過連通使邊緣產品無縫介入設備，將雲端的能力、設備的能力進行同步。

感興趣可以去這裡看看產品詳細內容：

https://cloud.baidu.com/solution/iot/intelligent_edge.html

我們一起往下看看百度雲天工的邊緣計算，一探究竟～

邊緣計算核心功能

「智能邊緣核心」主要負責本地計算、消息收發、安全認證、雲端交互等工作，具體功能如下所示：

本地消息收發

關聯設備使用 MQTT 協議連接至核心設備

Pub/Sub 消息模式，支持至多一次和至少一次兩級 QoS

面對應用的場景支持，支持會話保留，掉線不丟消息

保持雲同步能力，支撐百度無窮的運力和存儲

支持消息 Pub 到雲端，支持 Sub 雲端消息

強制使用 TLS，保證數據安全

本地提供函數計算引擎

深度集成百度雲函數計算（CFC），雲開發測試，本地執行

內置 SQL 和 Python 運行時，支持自定義擴展，輕鬆寫出高速錄處理能力

本地規則引擎

通用的 source->target 轉發模式

Source 和 target 均支持消息主題、雲主題和函數

端雲一體化

在百度雲來看，私有雲雖然對很多場景和企業非常有用，但是私有雲把企業的 IT 設施與公有雲之間的關係進行隔離。我們都知道人類對於計算的需求是無窮無盡的，如果與雲脫離連接，企業將會失去雲帶來成本節省的特性，所以私有雲不是唯一的解決方案。真正的解決方案是將私有條件、私有環境與公有環境之間恰當連接，進行端雲一體化。

在物聯網環境當中，我們可以認為設備的增刪改查、規則的創建和修改、函數的編寫與測試不會嚴重危害安全，可以交由公有雲，於是百度雲提供了雲端的管理，將邊緣計算軟體都到共享到同一個百度雲，用戶只需要在雲上進行編寫即可。但同時，由於數據隱私的需求、延遲的需求和帶寬的限制，所有的計算應當發生在本地。

上圖為百度雲的端雲一體化方案，通過點擊進行下發，遠程獲得配置，保證用戶數據安全。也正是經由端雲的一體化，實現設備離線工作，在連接的瞬間設備自動與雲進行必要的同步，通過規則確定什麼樣的數據與雲同步，什麼的樣數據進行保留本地，以及升級提醒。

IntelliEdge 特性

第一，IntelliEdge 基於本地計算可以實現即時響應，消息產生可能只需要一毫秒。

第二，超輕量級，今天的物聯網設備種類繁多，可能需要採購一台巨大的伺服器，也可能是在家裡用一個 PAD，但是 IntelliEdge 只需要一個 10mb 內存和磁碟，不會產生任何的外部依賴。

第三，超可移植，軟體支持 Linux、Windows、MacOS，硬體支持 X86、arm、還有 mips。IntelliEdge 既可以在數字 PAD 低耗能運行，也可以在大工控機支持數十萬的級的運算。

邊緣計算的實現和設計

李樂丁在介紹百度智能邊緣計算服務之外，還和大家分享百度邊緣計算技術方面的問題，對如何做出一款 IntelliEdge 軟體及架構的結構等進行了詳細解讀。

基礎拓撲

首先，李樂丁認為架構師應該具備抽象能力，不應該先進入細節，而是要從最高層次審視業務的完成到底需要哪幾個層面。在這裡，百度雲認為邊緣計算由三個簡單的部分組成，分別是設備、消息中轉和應用。邊緣計算在消息的中轉服務中心完成消息通訊、路由轉發，在應用里進行整理分析，進行函數計算。

設備鑒權

有了上面的基礎架構，邊緣計算就完成了 50%，那麼怎麼做到另外的 50% 呢？首先第一件事是安全，所有的軟體第一步一定是安全。在設備鑒權中百度雲採用了 MQTT 內部鑒權的功能，包括 Principal 和 ClientID 兩部分，Principal 告訴你允許發布希么信息，收集什麼信息，以及管理許可權集合，即允許 PUB 和 SUB 的消息主題；ClientID 則代表設備名稱，每一個 ClientID 代表一個實實在在的設備，或者是一個應用程序，同一個身份可以擁有不同的 ClientID，但是多個 Client 不能用同一個 ClientID 同時登陸。

消息中轉

結果安全之後，下一步就是消息中轉。這裡需要面對 2×2 的情況，一是發布端負責發布消息，二是訂閱端需要訂閱消息。無論是發布還是訂閱都有 QoS，由於低功耗設備或過載等問題，就會出現 QoS0，QoS0 意味著發消息是有丟棄的；有 QoS0 就有 QoS1，QoS1 表示發布重複，但不一定會丟。熟悉 MQTT 協議的開發者可能知道，MQTT 還有一個 QoS=2，語意是有且只有一次。這裡之所以沒有提到，是因為實際應用中僅有一次這樣應用場景會使成本過高，以至於沒有特別的應用使用。因此除了簡化架構，更主要的是處理必要的工作，把 QoS2 暫時擱置。但是隨著物聯網的深入，QoS2 也會不斷得到支持。

從架構的方面如何實現 2×2 的表格呢？虛線是消息的 Broker 代理器，當消息發布的時候，首先進入統一內存隊列，之所以選擇放到統一內存隊列中有兩個原因，第一降低系統消耗，第二提高性能。之後就是路由，它是一個內存隊列，雖然可配但是有限，超出這個長度可直接丟棄，所以這裡可以使得訂閱段防止過載。另外消息可以寫到重試隊列，重試隊列不斷向 QoS1 發消息，直到確認收到消息。當 QoS1 確定消息後，依然進入內存隊列，那麼這裡為什麼選擇先使用內存隊列呢？如果將 QoS1 先分到內存隊列，在宕機的時候可能使消息丟失，之所以選擇承受這樣的風險，是因為物聯網設備可能安裝在一個性能極低的情況下，這種情況下我們就必須使用內存隊列。緊接著批量寫入 KV 存儲，主要原因也是為了輕量級，一旦進入 KV 存儲，就保證數據落盤不會丟。然後進入路由系統，同樣分為兩個後端，一個是允許丟棄寫出隊列，另外一個是不允許丟棄的重試隊列，通過這樣的消息中轉架構完成 2×2 的表格。

函數計算

這裡引入函數計算的方式。將一個函數計算用 Runtiem 進行連接，發送到運行室，可以是 SQL、Python 或者是 ETC，之所以選擇獨立就是防止 Runtime 出現問題。然後用 STDIN 將消息反序列化，可以選擇任意 OK 的序列化機制，通過反射的方式找到函數的處理器。經過計算之後，將計算結果再序列化，通過 STDOUT 寫回消息終端，再傳走，這就是函數計算。

資源控制

另外一個必要的事情就是資源控制，因為代碼可能不是你寫的，而是由第三方或者合作夥伴寫的，這個代碼可能存在缺陷，也可能佔用巨大資源，怎麼辦呢？如何精確控制一次計算所佔用的資源呢？百度利用 Linux Namespace。首先通過 Linux Namespace 進行網路隔離，然後依次通過 AUFS,Croups，經由網路轉發大集群進行網路處理。

reload

邊緣計算的設計和實現通過 Reload，有可變的過程和不變的過程。不變的是 Listener 可以持續發送消息，同時 Broker 可以繼續工作，設備管理也會持續不變。可變的是什麼？首先是鑒權，當你的新配置與原來的設備不想連接了，或者是你有新的設備連接，或者許可權改變，鑒權也需要做出相應改變，這意味著有一些設備要丟掉。其次函數也會因為新的布局可能發生改變。再有路由的改變，在 App Old 的同時，建一個 APP New，把原來的服務轉移到新的設備上，原來的就由 App New 處理，其他的用 App Old 處理，處理完之後再丟掉，通過這個較為平緩的 Reload，企業可以獲得穩定的系統。

設計原則

百度雲邊緣計算有許多新的設計原則，比如：

軟體不同於互聯網產品，質量遠重於效率

高移植性

物聯網設備多樣性程度很高，硬軟體差異巨大

選擇 Golang，純靜態編譯消除外部依賴，內建交叉編譯

強伸縮性

需橫跨從樹莓派、路由器到工控機和伺服器的使用環境

響應和吞吐都不是必要的性能指標，可接受 GC，無需零成本抽象

利用語言內建的 M:N 線程模型

單機化

保持無狀態性，將狀態約束在最小化集合內

保留 P2P 形式的分散式擴展，廣播同步路由表，互相傳遞消息

2

解析時序資料庫的技術構建和行業應用

萬物互聯的時代是數據量激增的時代，每天要採集上億級別的數據點，每月累要積至少百 G 數據量。如何實現 IoT 設備的高並發寫入，如何在 TB 級別數據中秒級響應並畫出變化曲線等，百度雲物聯網部高級產品經理黃淼做出了詳細解答。

時序資料庫

黃淼首先對時間序列數據的概念進行了解讀，時間序列數據是指在不同時間點上收集到的數據，這類數據反映了某一事物、現象等隨時間的變化狀態或程度。

時間序列數據特點

時間序列數據具備很多特點。以上圖為例，第一個是寫多讀少，每 10 秒上載一個數據點，其中 90% 的場景是寫的場景。第二個是讀寫正交，每一個黃點代表一個實時數據，寫的時候往往是同一個時間戳將配電櫃的電流、電壓、功率都寫進去，而讀的時候最常見的場景是讀取一段時間之間電壓的值，將這些值做查詢出來畫一條曲線或者做聚合運算。第三個是新舊有別，分為熱數據和冷數據，半年之內的數據一般會比較頻繁的進行查詢和計算操作，半年之外不會進行查詢的數據一般會放到冷處理分析。第四個是極少刪除，舊的數據不會刪除，因為這個數據即使不做查詢操作，也會存下來，對機器學習有很大幫助。第五個是一般以一定條件做聚合分析，比如對配電櫃 2 的電流、電壓、功率進行分析，會以配電櫃 =2 作為條件，查詢出來做聚合運算，。第六個是事務性弱，對於傳統型關係型資料庫來講，事務性要求比較弱的。

百度雲時序資料庫（TSDB）

百度雲 TSDB 給用戶提供的服務分為三個層次。第一個是記錄變化，也是資料庫最樸素的職責，認認真真把每個數據記錄下來，讓用戶業務產生的海量的數據存儲好。不發生變化。這就需要 TSDB 做到高並發的寫入、三備份保證可靠性、防 DDOS 攻擊、冷熱存儲分離等。第二個是理解變化，TSDB 有極速的查詢能力和每秒對億級數據點聚合能力，都能幫助客戶快速從 TSDB 的得到想要的數據；另外還支持 Web 圖表可視化、還有 BI 工具。最後是喚醒變化，也叫賦能變化，進入到 TSDB 中的數據可以無縫對接百度大數據 AI 能力，幫助你在業務發揮更大的價值。

TSDB 技術發力點

作為一個技術產品，百度雲 TSDB 給用戶可靠性高、性能高的商業化產品，其中幾個重要的技術方案如下：

存儲。存儲有兩點，一點是採用分散式分片的存儲，可以分成片，利用時序數據的特點，基於時間序列對數據進行分片存儲。另一點是分級存儲，將數據基於業務條件進行分析，比如把最近一天使用的數據放在 Cache 里，最近一年的數據放到 SSD 里，一年以上不是非常頻繁查詢的數據放到 HDD 里。進入了 Cache 的數據通過寫回和寫通策略寫到 SSD 裡面，而 SSD 的數據也可以定期遷移到 HDD 里。

壓縮。壓縮目標有兩點，第一是降低成本，第二是無損壓縮。數據如果不經過壓縮存儲的話，只是一個車廠用戶每天就會產生上百 G 的數據，機器成本一定是很高的。所以要進行壓縮處理，關於壓縮要先明確兩個前提，第一，不存在一個通用的壓縮演算法對所有字元串都能壓縮；第二，不存在一個公式或者函數，告訴我們某一個字元串壓縮到最短是多少個字元。這兩個結論有嚴密的數學公式去論證，在這裡不做贅述了，我們只要記住這兩個結論。那麼基於這兩個結論呢，我們來看，對於我們的壓縮會有什麼挑戰。首先，我們無法判斷哪一個壓縮演算法是最優化的；其次在某些場景下一定會有不會被壓縮的字元串存在。所以壓縮是一件很有挑戰的事情，其實越是有技術挑戰越適合百度去做這件事情，因為百度在互聯網和物聯網時代都積累了大量的數據，我們對數據的含義是有深刻理解的。所以才會在不同的場景和數據形式中採用更合適的壓縮方式，將壓縮和存儲效率提高，讓我們在壓縮這件么有最優解的事情上無限逼近極限。

查詢。採用分片的方式，分為 ShardA、ShardB、ShardC 及 ShardD，根據分片的結果合成最後的值，可以達到儘可能讓計算做到本地化和多並發的效果。

下面介紹幾個 TSDB 的特色能力：

插值查詢。針對網路帶寬、計算性能等問題，用戶以一定的頻率上傳值，通常是數據發生變化了才上報，所以 TSDB 提供不同的差值演算法，將未上報的值補齊，按照多種演算法補齊缺失數據，節省存儲和上傳的成本，並且不會損害數據價值。

預處理。TSDB 針對多種嵌套複雜查詢場景，對返回時間提出較高要求，也可提前設置規則，自動聚合歷史數據。

TSDB 案例

黃淼在演講最後以電力服務公司為例，說明 TSDB 的工作流程。如圖是一個採集電櫃，把數據發到物接入，物接入是我們在雲端做的數據接入消息的對外服務，可以接收海量大規模數據，接入以後經過雲端的接收的能力，做流式計算，進行數據的過濾、變形、轉發，經過規則引擎直接到 TSDB，形成可視化展示、用電分析、能耗管理、節能預測。這個架構解決了僅能查詢 2 個月的熱數據的問題，現在的時序資料庫可以進行實時查詢，半年的數據 2 秒以內返回。

3

百度雲物可視的數據可視化實踐之路

百度雲「物可視」無縫對接海量實時數據，零編程設計可視化儀錶盤，支持監控大屏展現，更有定製和嵌入功能，簡化開發數據可視化應用。百度雲物聯網部前端開發工程師鍾姿艷，現場演示儀錶盤的製作、部署，並分享物可視解決方案的數據源與數據表創建。

數據可視化

數據可視化分為科學可視化、信息可視化、可視分析學三個學科方向，涉及信息技術、自然科學、統計分析、圖形學等多種學科領域。此次討論的數據可視化，主要是信息的可視化，即抽象數據的可視化交互表現，通過圖形手段清晰傳達有效信息。

物可視產品特色

物可視產品將可視化工具和 BI 工具進行結合，做出了一款擁有 PPT 交互和設計體驗的數據驅動可視化產品。基於物可視的基本概念，對物可視的產品特色和優勢進行詳細的介紹：

實時展現數據的洞察。物可視支持多種數據接入，比如說靜態的數據、資料庫的數據、流式數據等，使數據傳輸具備更省流量和更低延時的特點。支持對基礎圖表的動態驅動，另外還支持每一種元素像形狀、顏色以及文字各種實時展現。

豐富的可視化圖表。可視化圖表分為五種類型，第一類包含了折線圖、柱狀圖、儀錶指針、時間序列的圖表等；第二類是百度地圖，包括了設備的點跡、軌跡等；第三類是通用的組件，包括像圖片、標籤、副文本、圖表等常用組件；第四類是基本的圖形，包括了圓形、矩形、箭頭等；第五類是組態圖，包括閥門、管道、水泵等工業場景下的組態圖。

應用與可視化的交互。物可視不僅提供了零編程大屏數據的搭建，而且還提供給開發者一個 JavaScript 運行庫，以及配套的 JS API，幫助實現不同應用與可視化在同一頁面中的各種複雜交互。

提高開發效率，10 分鐘完成監控類的可視化應用開發，且提供更多功能適用定製場景 。

物可視適用場景

物可視是一款一站式的數據可視化開發工具，基於百度雲天工平台，以可視化的形式將數據呈現給用戶，那麼在物聯網中，物可視的數據可視化有哪些應用場景呢？

物可視可以做一些物聯網設備的數據監控，例如電力公司，對電量設備進行數據監控；物可視還可以用來管理智能樓宇，比如說可以用來管理當前的溫度、濕度、人流量等；在車聯網的場景中，物可視可用來監控車輛的軌跡或者是物流的情況；也可以通過物可視做一個控制中心或者智慧社區的大屏展示。

物可視實操

鍾姿艷結合實例現場給聽眾演示物可視的兩大使用方法。第一是製作數據大屏，通過使用模板調整一些內容進行快捷的搭建，或者是可以從 0 到 1 在一個空白頁面上搭建出一個自己喜愛的定製化數據可視化大屏。第二是通過製作儀錶盤、物可視 js 包的引入及實現交互邏輯三個步驟將可視化的組件嵌入到 Web 應用中。

物可視還提供豐富的實例模板，以上圖為例，這個模板可以適用於各種監控類的大屏。從左邊開始，最上方是公司的 Logo 以及名稱，下方用數字翻牌器對電量數據進行了放大的突出，往下是顯示完成的進度，再往下是車間溫度通過儀錶指針檢測位置，一旦發現有異常，可以在最下方展示區看到狀態燈以及數字會相應變紅，進行告警。中間是時間序列的圖表，可以看到明顯的走勢情況。面積圖反映了電量購買的一個趨勢，下方的時序柱狀圖體現各個設備之間在同一時間的對比情況。右上角為一個時鐘，還有銷售數據的四個指標，最下面的圖表可以清晰平鋪一些重要的數據。

4

在未來

百度雲天工作為物聯網生態系統中重要的組成部分，對物聯網生態系統有著很好的完善。與此同時，百度雲天工「智能邊緣」將使得雲計算與最終用戶聯繫更加緊密。百度雲深知未來的趨勢將是「大智能」在雲中，「小智能」在邊緣，逐步推出完整的「智能邊緣」一棧式服務，助力客戶打造邊緣設備智能化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！