音視頻領域的新技術應用非常多,但是在工業和IoT領域,新技術的應用卻鮮有耳聞。本次上海站大會我們邀請到了熹樂科技YoMo框架負責人——洪小堅,為我們分享熹樂科技和YoMo會為工業和IoT帶來哪些新鮮血液。
大家好,今天分享的主題是可編程的流式計算框架。大家可能都比較關心音視頻領域,我們YoMo面對的場景比較偏向工業、IoT等領域。雖然是不同的場景,但是仍然有很多技術的共同點。大家聽完以后會有不少收獲。
今天的大綱分為自我介紹、YoMo項目背景、YoMo典型用例、YoMo技術亮點、對邊緣計算的理解以及總結。
關于我和熹樂科技
01
首先做一個自我介紹。
我是從2007年開始做技術研發,做了12年歐洲用戶的電商平臺。因為對邊緣計算和工業互聯網都很感興趣,所以2019年加入了現在的創業公司——熹樂科技。目前我正在維護今天的主角——YoMo項目。
熹樂科技很多朋友都是第一次聽到,下面做一個簡單的介紹。熹樂科技專注于工業互聯網和邊緣計算,打造了YoMo開源計算框架和YCloud云服務。我們從2015年開始將人工智能技術應用于工業制造領域,例如計算機視覺對于地板的質量檢測。熹樂科技目前持續服務了40余家工業企業。在2019年與“中國輕工集團”共同成立了“中輕工互聯網有限公司”,主要是將邊緣計算等工業互聯網技術在輕工行業落地。
YoMo項目背景
02
下面介紹YoMo的項目背景以及設計的原理。
首先要介紹的是開放性。隨著網絡的基本設施,例如5G的普及,想要實現低時延看起來還是唾手可得的。5年以后,企業之間比拼的可能就是QUIC協議這種具有開放性的、基于User Space的可以作一些靈活擁塞控制的算法。未來的軟硬件可能都是可編程的、開放性的。
回過頭看看目前業內一些主流的技術,說到實時流式計算就會聯想到像Flink這種、消息隊列會想到Kafka。甚至我們微服務部署很多人會想到Docker,但這些技術其實都是幾年前開始設計的,都屬于消費者互聯網。未來會進入IoT的時代,之前的技術雖然現在還是主流,但是不一定會適合未來。我們在做產品的時候就想通過新的技術,來創造一些新的機會。
近幾年新聞報道了很多工業的事故,造成了巨大的人員傷亡和經濟損失。加之現在國家政策一直在鼓勵安全生產,所以我們的客戶就想做安全生產,例如數字化檢測和預警系統等。“中輕工互聯網”去年就服務了一家化工企業。
安全生產的最高等級就是實現本質安全的理論。本質安全就是不論是設備故障還是人為操作不當,都可以提前預測事故的發生。要做到本質安全,就需要做到計算連續3s的數據變化趨勢。同時AI算法會對不久將來可能發生的事故做出反應。例如未來30s后可能會爆炸,這時就需要提前向化學反應堆里加阻燃劑。
要做到這樣的操作,還需要在1s內做到30次的計算,一次大約為33ms。如果這個計算節點部署在云計算中心,那么光數據的傳輸可能就已經超過該時限了。上面提到的33ms不僅僅包括數據傳輸,還要包括AI計算的時間。因此想要做到本質安全,就需要對傳感器的數據進行實時的采集和計算。
要做到實時采集就需要低時延的傳輸,一是利用類似QUIC的協議,二是隨著5G、WiFi6的普及,對保障低時延傳輸有很大的幫助。另外,我們需要對采集到數據進行毫秒級的計算,這就需要在邊緣端部署才能實現。如果部署在云端,即便計算速度很快,但因為傳輸速度的不足也會導致毫秒級計算無法實現。除了以上兩點,還需要在邊緣端部署一個Edge AI進行全維度的計算來實現預緊預測。
根據現在的趨勢,將來實時計算比例會越來越高,IDC預測2025年實時數據計算將會占比30%。
這是目前IoT領域的一些主流協議。TCP是1983年誕生,距離現在已經快40年。另一個主流的MQTT協議也已經誕生20多年。隨著5G的普及,這些老舊技術就像在動車鐵軌上跑的綠皮火車。Google在2012年就提出QUIC協議,在2016年進行 IETF的國際標準化。但是因為極大的升級成本,所以目前在工業領域目前用QUIC的并不是很多,但是在音視頻領域國內外用應用的卻很多。熹樂的目標就是將QUIC技術方便的應用到工業領域。
我們提出gRPC for IoT的理念。gRPC是一個很主流的微服務RPC框架。gRPC for IoT就是希望在邊緣端可以實現全鏈路的QUIC Transport。例如Client/Server服務可以通過QUIC建連從而變成P2P的模式。傳統Client/Server的問題在于只有在Client請求以后Server才會響應,這種模式是單向的。而用QUIC建連之后,就是雙向連接Peer to Peer,同時又是長鏈接。為什么是長鏈接?因為IoT設備數據是24小時不間斷的,如果每次請求都斷開、重新建連會造成時延的影響。
另外我們針對IoT領域推出自研的Codec。熹樂科技在IoT領域很重視網絡傳輸編解碼的效率方面。IoT數據的實時采集并通過長鏈接發送的模式和視頻直播是很相像的。
IoT的設備到2025年將達到750億。這意味將有越來越多的設備需要進行數據采集,由此產生的APP應用也會越來越多。
現在市場對APP的開發要求越來越快,time to market越快越好,現在很多低代碼、無代碼就是為了縮短開發時間。YoMo框架十分重視開發者友好,以便開發者使用時可以節省時間。
為了節省開發時間我們提出了Streaming Serverless的概念。Serverless的優勢在于只需要專注幾行核心代碼、無需關心 DevOps、自動彈性伸縮,以及按需計費,低成本。IoT領域的數據是24小時不間斷產生的、沒有邊界,是典型的streaming場景,雖然現在已經有很多比較成熟的Serverless框架,但市面上大多數 Serverless 框架是面向傳統的HTTP Request/Response 模式。因此我們針對該場景提出了Streaming Serverless。
這是一條比較有意思的推特。這個推特是Docker的創始人在2019年提出來的,他在推特中提到,如果2008年出現WebAssembly,那么他們都沒有必要去創建Docker了。WebAssembly之前跑在瀏覽器端比較多,現在的趨勢卻是跑在服務端。
WebAssembly和Docker相比具有哪些優勢呢?WebAssembly的Cold Start會比Docker快100倍。其次前者執行時間較后者也快10%-50%。另外WebAssembly 占用的空間更小。最后WebAssembly有更靈活的安全策略,可以根據不同模塊,在實例化時指定不同權限。
因為在邊緣節點資源會比較受限,所以WebAssembly綜合了輕量級、更優的性能、更高的安全性和多語言的特點。多語言對于Serverless尤其重要,因為現在很多主流的開發語言都支持把程序編譯成WebAssembly,具有這樣的特點會有很多的好處。
綜合上述的方方面面,我們做了YoMo開源框架。
YoMo應用案例
03
再來分享幾個典型的案例。
我們在辦公室部署了一個實時噪聲傳感器,來測試YoMo框架是否能達到低時延。因為MQTT協議需要安裝MQTT Broker,所以我們在數據采集端做了一個MQTT兼容的API,這樣可以減少用戶的負擔,無需安裝 MQTT Broker 即可接入 YoMo。為了測試實驗,我們將Serverless的節點部署在寧夏的AWS,來測量北京到寧夏,再從寧夏返回北京的時延。
我們的測試結果顯示時延基本能穩定在30ms以內。另外像屏幕上顯示的分貝值,傳統的做法是把傳感器數據先保存到數據庫,然后再進行查詢顯示,這樣就會造成時延的損失,所以YoMo采取通過WebSocket直接顯示到屏幕上。同時用另外一個 Serverless服務把數據落地到 DB。
白酒智能釀造平臺是一個工業級的應用。白酒行業的一大特點是很多釀酒工藝是通過老師傅的經驗傳授,這樣是非常主觀的。我們在和一個研究白酒幾十年的專業研究院——中國食品發酵工業研究院合作后,獲得了他們提供的硬件和相關的工業算法。接著我們對這些設備進行了實時的工藝采集和計算,把老師傅的經驗數字化,從而獲得穩定的工藝,提高了出酒率和效率。
海外有一個用戶想做用戶行為的跟蹤,分析一些網站上用戶什么樣的行為會導致轉換率的降低等問題。針對這樣的場景,我們做了Geo-Distributed的分布式解決方案,將傳統的中心化架構拆分成多個靠近用戶的邊緣節點。
最后一個案例是分布式的爬蟲。我們服務了一個海外提供物流查詢的SaaS公司。之前這個公司的查詢都是通過 proxy去獲取,這樣會造成很高的時延,同時穩定性也不高,更加嚴重的是數據隱私可能泄露。通過YoMo框架,我們在更靠近快遞公司的節點部署了一個爬蟲服務,通過QUIC協議,把請求通過長連接返回給美國的用戶。這些服務器都是部署在用戶自己的機器上,數據隱私得以保障,也節省了proxy代理的開支。
YoMo features
04
通過之前的講座,在座的嘉賓多少對QUIC協議有一定的了解,這些內容就快速通過。
QUIC優點是非常多的。最好的就是最下面的兩點。一個是User space,我在開頭開放性那里也提到過User space,可以更方便的進行軟件升級。TCP內核態的升級就沒有那么方便。二是擁塞控制算法。根據不同的場景進行靈活的控制,具有更高的可編程性。
QUIC在業內的應用實踐音視頻方面比較多。國內很多的大廠在兩三年前就開始研究音視頻方面的應用。QUIC對性能的提升幫助很大,包括卡頓率等等。因為看好QUIC 的前景,加之工業領域應用很少,所以我們想推動QUIC在工業、IoT領域的運用。
這里視頻借用了阿里手機淘寶的視頻,左邊采用多通道的QUIC,右邊沒有采用。如果WiFi出現抖動的,左邊可以通過蜂窩網絡流暢運行,而右邊只用到 WiFi 就出現卡頓的情況。
自研的 Y3 Codec我們稱它為faster than real-time。如果是傳統的JSON的話,就需要拿到完整數據以后進行解碼。針對IoT,例如之前提到的噪聲,只要獲取噪聲分貝的字段即可。對此,我們使用了TLV的結構。結構里的Tag相當于 JSON的key。通過監聽Tag是不是用戶關心的,如果是就直接獲取,不是則skip,再根據Length判斷需要skip多少字節。
性能測試中Y3 Codec相比JSON提升超10倍以上,與Protobuf相比也有明顯的提升。下表所展示的是一些性能報告。
響應式的編程用excel的應用來形象的說明。假設a=b+c,那么對b、c進行修改a也會有動態的響應,這種模式是十分適合數據隨著時間變化的場景。
ReactiveX也針對異步數據提供了一個良好的編程模型。ReactiveX最早是由微軟提出。在操作異步數據時可以使用一些通用的方法,就會像操作同步數據一樣方便,只要組合幾個常用的函數就可以操作異步數據流。
假設每30ms都會傳遞一次數據,可實際場景可能是連續兩個30ms都沒有數據,第三個30ms突然出現三個數據。針對這種場景我們實際只要獲取最新的數據即可。使用 Rx 可以簡化這個問題,使用 debounce 即可獲取每 30ms 內的最新一條數據。
Streaming Serverless讓用戶不需要操作QUIC Stream,只需要操作Rx Stream。可以根據業務需求進行Operator方法的組合即可。另外市面上很多Serverless服務在本地調試比較麻煩,所以YoMo支持CLI的方式本地運行和調試。
邊緣計算
05
邊緣計算各位多多少少也有一定了解
整個行業的趨勢是從之前的大型機通過終端連接變成PC端去中心化場景。發展到移動互聯時代又回到了中心化的云計算中心。到IoT時代因為數據量的巨大,需要邊緣端進行分布式來緩解云計算中心的壓力。邊緣計算雖然越來越重要,但是邊緣計算并不會取代云計算,他們會共同存在。
邊緣計算的優勢一是降低傳輸距離。二是就近計算更快的響應。第三,比較重要,邊緣計算可以保護安全隱私。很多工業企業并不是很愿意把數據傳輸到公有云服務上,所以隱私保護顯得格外重要。最后一點就是低成本。邊緣計算可以減少帶寬傳遞的成本。
云計算和邊緣計算的對比發現,云計算的性能更強但時延、帶寬成本較高,邊緣計算恰恰相反。云計算和邊緣計算在使用上互補,以滿足不同場景的使用需求。
對此我們做了Geo-Distributed Edge Cloud。用戶可以根據時延需求來部署在不同的地方。低時延可以部署在城市級節點。如果有數據監管要求則可以部署在私有云。另外部署在云計算中心也是可以實現的。
總結
06
最后對今天的匯報進行一個總結。
YoMo的項目背景是面向未來可編程的開放性。針對網絡傳輸提出gRPC for IoT——全鏈路采用QUIC以及Y3 Codec 高性能編解碼。另外為了加快用戶開發APP的速度,提出了Streaming Serverless的框架。針對YoMo的使用場景,運行在WebAssembly會比Docker更加具有優勢。最后邊緣計算方面YoMo可以基于Geo-Distributed Cloud進行就近部署。
以上就是YoMo的開源計劃,希望對YoMo感興趣的朋友們可以多多關注。
謝謝大家!
編輯:jq
-
IDC
+關注
關注
4文章
391瀏覽量
37256 -
云計算中心
+關注
關注
0文章
10瀏覽量
7330 -
5G
+關注
關注
1355文章
48479瀏覽量
564856 -
IOT
+關注
關注
187文章
4217瀏覽量
197082 -
邊緣計算
+關注
關注
22文章
3104瀏覽量
49156
原文標題:可編程的流式計算框架:YoMo
文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論