可编程的流式计算框架:YoMo

Posted LiveVideoStack_

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了可编程的流式计算框架:YoMo相关的知识,希望对你有一定的参考价值。

音视频领域的新技术应用非常多,但是在工业和IoT领域,新技术的应用却鲜有耳闻。本次LiveVideoStackCon 2021 上海站大会我们邀请到了熹乐科技YoMo框架负责人——洪小坚,为我们分享熹乐科技和YoMo会为工业和IoT带来哪些新鲜血液。

文 / 洪小坚

整理 / LiveVideoStack

大家好,今天分享的主题是可编程的流式计算框架。大家可能都比较关心音视频领域,我们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感兴趣的朋友们可以多多关注。

谢谢大家!

讲师招募 LiveVideoStackCon 2021 北京站

LiveVideoStackCon 2021 北京站(9月3-4日)正在面向社会公开招募讲师,欢迎通过 speaker@livevideostack.com 提交个人及议题资料,无论你的公司大小,title高低,老鸟还是菜鸟,只要你的内容对技术人有帮助,其他都是次要的,我们将会在24小时内给予反馈。点击[阅读原文]了解大会更多内容。

以上是关于可编程的流式计算框架:YoMo的主要内容,如果未能解决你的问题,请参考以下文章

Flink流式计算从入门到实战 四

音视频技术开发周刊 | 198

轻量级边缘流式计算框架Creek实战

Flink通用流式计算框架Flink

分布式流式计算框架vortex使用介绍

百度智能云推计算框架Creek 让流式计算能力延伸至每个边缘节点