深挖价值,让数据“说话”,你准备好了吗?

版权声明: https://blog.csdn.net/sch881226/article/details/82872271

随着AI技术的深入发展,近几年来与企业级数据相关的讨论层出不穷。

如何存储?怎样调用?调用的时候又该如何确保隐私不被泄露?

……

尽管数据专家一波接着一波,但针对企业如何理解、存储、使用数据,并通过其实现更大商业价值的探索从未改变。

对此,百度云早就get到了开发者们的数据痛点。

就在刚刚结束的、由百度云主办的“百度云ABC Tech Day —— AI时代的智能存储分发技术实践”的活动中,来自百度云内部的诸多专家现场针对存储、数据分发、媒体数据处理等领域的数据技术以及AI能力布局等方面与到场百余名开发者展开了深入的交流与探讨,现场气氛热烈。

本次沙龙中被探讨的诸多内容,也十分值得相关领域的开发者们认真学习与总结!

百度云BOS在AI时代的探索和实践  (百度云高级产品经理 崔剑)

沙龙初始,百度云高级产品经理崔剑首先为与会的开发者们带来了《百度云BOS在AI时代的探索和实践 》的主题演讲。他表示,百度云的存储产品其实具备了几种特质。

众所周知,企业数据要上云,必然要区分不同的类型,目前百度云按照三种类型,分别是结构化、非结构化以及半结构化来归类企业级数据,充分满足多样化的需求。

据了解,百度云BOS产品大概整体的数据量已经超过了2000TB,这个产品在内部已经有万亿的记录。兼顾存储的性能以及成本,崔剑表示,百度云BOS整体底层的基础设施也已经提供了不同档次的存储设施,最基本的为蓝光,高端的有HDD以及SSD盘等。

随着数据发展,百度云的存储业务不单单是将数据“存上来”,未来更需要将数据放在云上让其“说话”,也就是存储+AI 的概念。

相比于国内各种存储竞品,百度云对象存储BOS在自动触发机制,例如通过消息队列、函数计算等“链接”其他云上产品的能力很强大,主要取决于百度BOS的智能处理架构。

此外,崔剑指出,对象存储很大程度上会成为未来的一个表现卓越的存储产品,因为相比文件存储或者块存储,对象存储具备一些独特的性质。例如能够支持更加海量的数据存储,可以提供更高的性能以及数据可靠性等。

在BOS的层面,面向开发者,如何使用才能更方便?

关于这个问题,崔剑表示,百度云为此开放了比较规范的VPI接口。

由于BOS分为几种产品概念,无论是图片、内容处理的相关接口,还是图片旋转、设置,甚至是对图片进行一些涉恐、涉黄的检测等,各有区别。

除了接口外,在前端存在的不同开发语言,开发者希望提供包装的SDK,而百度云的SDK语言覆盖比较全,例如java、安卓、iOS等都会涉及。

BOS架构演进实践 (百度云研发总监 段立国)

从对象存储产品BOS的架构出发,段立国认为,从本质出发,其实BOS是一个多租户共享系统,如何做到用户级别的KOS和用户相互访问的隔离,其实是一个很大的挑战。

从根源上看,存储系统的流量很大,例如百度云机房的BOS 入口已经达到了TB级别。如何把数据cache到用户最近的地方,也就是整个IDC的范围内?是个问题。

通常来看,IDC并不只是局限在一个地域范围内,在大流量的背景下IDC之间的访问很容易成为制约存储系统的瓶颈,所以cache就变得非常重要了。

“我们的cache分为两层,在AZ级别会有一个用户的热点开启,这个cache会与后面的存储打通,对cache的一致性要求会从前端一直到后端,尽量将这个数据cache到离IDC入口最近地方;第二层cache是当用户的访问量很大时,会启动一个本机开启,但是连接AZ的cache都不会被提取,而是直接在wep service建立一个cache,尽管这个cache要牺牲一致性。”段立国补充道。

很多开发者们会有疑问,BOS 如何做到在低成本的前提下保持如此高的可用性?

他对此总结道,做到“多运营、多地域接入;四层负载均衡集群无单点;数据接入层、访问层无状态且水平扩展;数据EC编码多冗余读写”四方面就可以。

所谓四层负载均衡设备,主要实现的是自行调写的功能,调写期间并不会把大量的半连接的状态推迟到之后的业务处理逻辑中。

提到BOS的高安全性,段立国介绍,关于最外层流量入口,百度云会做一层全流量的旁路检测机制。

“大概的原理是,在外网核心的地方会通过分装镜的方式,把所有数据流量复制到一套旁路的检测系统中,这套旁路的检测系统负责某个IP的流量是否根据预设的值,是否超过预设值等。如果有超过的情况,就会接入后面的流量清洗系统,将其清洗掉,然后再转发给后面的设备。例如,设置的同一个IP的流量不能超过两万QBS,如果超过两万,就会在这个旁路数据清洗中被清洗掉。”

关于数据服务端加密、落盘加密、KMS密钥管理等细节,据悉百度云是较早能够提供用户自定义证书产品的企业,具体就是提供用户绑定BOS运营的业务,然后用户将自己的证书上传到BOS,如此上传链路就可以做到用HITPS覆盖。

需要提及的一点,对象存储BOS可以实现透明加密,这样所有的数据都是加密之后才会落盘。

段立国表示,在落盘之前,通过NS在最上层进行数据加密,BOS 的技术人员在最前端做解密,通过KMS管理密钥。此外,对象存储BOS还提供了十分丰富的认证和鉴权机制,相对国内以及国际都比较领先。

精彩的技术干货分享之余,百度云人力资源部的经理还就百度人才观、招聘体系以及招聘职位等信息同与会开发者展开了交流与探讨。

百度云音视频直播+AI的产品化探索 (百度云高级产品经理 程鸿)

如今音视频的直播火热不断,无论是一月之前全民乐看的世界杯比赛,还是人们每天玩到不停歇的快手抖音,百度云对新的内容分发形式有何见解呢?

基于此话题,百度云高级产品经理程鸿认为, 如今互联网直播平台的兴起确实在很大程度上促进了互联网直播服务的革新。

对此,百度云将互联网直播1.0,也就是传统的直播转变成为云化的服务。例如LSS。提供了一个端到端的、即开的云化服务,主要由三个模块组成,分别是主播的推流端、中间进行接流处理和分发的环节、最后用户在播放端观看直播。

据了解,在推流端,百度云会提供一些实时美颜、滤镜以及特效等功能, 同时还会涉及到实时转码、鉴黄等功能,最终用户在观看的时候,比例如首屏秒开、推帪播放、码率自适应等这功能也会被一一呈现。

谈及百度云有关直播的关键点以及技术,程鸿进一步总结道:“目前主流的是RTMP、HLS、HTTP-FLV三种协议,但协议在使用上也是有区别的。例如,RTMP协议由于数据的立刻转发性,所以延迟比较低,但在H5的使用中却需要首插件,所以在通常H5页面的一些直播会使用HLS协议;HLS协议因为生成ts文件切片,更新m3ue索引,又会导致延迟比较低,大概5-10秒,所以目前主流采用flv协议比较多,因为延迟比较低,并且穿透性比较好,方便调度。”

据了解,百度现在又自研了一种HLS+协议,能够达到与FLV延时,并与ap一致的互动体验。此外,程鸿表示,百度云将互联网直播2.0与AI结合,在效果增强、审核监督、精细运营、简化人工四个方向做了相关优化,能够为现在的直播带来更多的新鲜元素。

百度云流媒体CDN的演进  (百度云高级架构师 沈慧峰 )

紧接着直播的话题,百度云高级架构师沈慧峰为现场热情的开发者们带来了百度云关于CDN的技术创见。

有关直播CDN,本质上需要探究的还是一个系统架构的事儿,主要就是边缘的接流转发到多个源站进行处理,然后根据用户请求再进行边缘分发。

了解直播的人都清楚,直播的协议中主要就是RTMP。

“如果从上行来看,其实就是RTMP推到我们的边缘节点,然后就会有一个接流集群,再转发到主源站和备源站,根据级别的配置转发到一个播放的集群。任何一个直播系统都会有一个播放集群去缓存流,其实内存缓存就是缓存最新的数据,源源不断。”沈慧峰说。

如果涉及使用转码的话,百度云可能会使用一些转码单,但是转码也是基于播放请求。转码和转发以后的数据就缓存在刚才提到的播放集群,仅供下游播放。这样来看,整个上行环节就是视频从主播端通过边缘节点一直转推到中心节点的过程。

直播CDN是一个庞大的网络,由边缘节点和源站组成,除此之外还需要依靠监控系统和波测系统确保可用性,例如调度系统。

通过调度系统去调度节点,主要可分为策略层以及执行层。所谓策略层就是掌握这些数据以后怎么去调度?

沈慧峰表示,其中涉及到容量和质量策略计算,还有回源链路的选择,这也是决策系统中的一部分,此外还有故障动态容灾,就是一个节点挂掉后,自动从DNS中及时将坏节点移动。所谓执行层,就是执行者就会利用策略完成调度,对于直播、点播“一视同仁”,主要是DNS调度以及HTTPDNS。

关于CDN延迟问题,沈慧峰认为客户之间的认知和接受程度大不相同。

例如,在线教育对于延迟要求高一些,因为涉及到学员间的很多互动环节;而对于泛娱乐,卡顿方面就会要求比较高。

“所以针对不同的客户场景就要有与之区别的技术设计,一个是针对小于GOP的延迟要求,在服务器上会追赶播放技术;如果对于游戏直播,延迟可以放宽到大于一个GOP,就会有一个帪级别的缓存控制。”沈慧峰补充道。

此外,百度云还会为客户考量如何监控自己的直播服务体验,为此提供了一个APM SDK,也就是在直播APP中加入SDK,同时提供多维度的云端数据分析。

具体来说,就是从直播请求开始,将打点的数据放到准备好的SDK 中。如果过程中出现卡顿,直播结束后SDK 就会将数据上报给相应的服务器,随后进行汇总,进而去细致统计计算这场直播的卡顿率、首屏时间、可用性、下载速度等,甚至可以区分维度。

如今企业越发重视数据层面的技术,深挖企业级数据价值在很长一段时间内都将成为不容忽视的重点。

猜你喜欢

转载自blog.csdn.net/sch881226/article/details/82872271