本次云栖大会的主题是驱动数字中国,以阿里集团和阿里云的先进技术帮助中国更多的中小企业实现数字化转型,或者更好的利用数据、技术来提高自身的产能和行业竞争力。而传统企业的数字化转型的必经路线是:数字化 -> 在线化 -> 智能化,根据这个主题,我们来看本次云栖大会的议程,这些议程基本可以划分为数字化、在线化、智能化三个方面:
结合大会议程及四天的现场参会见闻,有以下两个大的方面的感受:
大数据和计算能力是智能化的基础设施,在这方面,阿里云做了大量工作:
由于分身乏术,只能选择参加一些场次,作为高德的技术同学,我的参会场次选择是:
日期 | 上午 | 下午 |
---|---|---|
19日 | Flink专场 | 大数据计算专场 |
20日 | 人工智能峰会 | 自动驾驶车路协同专场 |
21日 | 高德专场 | 电商平台专场 |
22日 | Severless存储专场 | 数据中台专场 |
下面对我参会了的场次做个简要的总结。
Flink主要适用于流式数据处理,在阿里的应用场景很多,举几个例子:
Flink最早是在2009年就有了,但是到2014年正式提交到Apache后开始流行起来,主要用在流式数据处理场景,以cluster或者standalone的方式部署,目前Flink是一个流式计算的Framework。未来Flink开源社区有计划:除了现有的Framework方式以外,Flink也可以作为一个Library的方式提供给各业务应用。
阿里在Flink开源代码基础之上,形成了自己的Blink项目,同时也将部分功能回馈给了Flink社区。主要贡献有:
Flink的原理在本专场里没有太多介绍,其和其他大数据产品体系其实是非常类似的。可以参考一个比较好的对比文章。
另外我想说的是类似于在Blink这种在开源基础上优化的方式是很值得推荐的一种方式,这也是利用Java生态体系的一个天然优势,深入理解一些开源产品这也是我们的工程师们在进阶道路上的一个必须要求。
从ODPS到MaxCompute,核心功能扩展了不少,使用过MaxCompute的应该都有一些感受,我们感受到的几个主要的新扩展功能有:
自动优化功能,基于对数据和历史运行情况的分析,MaxCompute做自适应优化。例如通过自动分析后,自动在某些业务表上建立Hash cluster索引。这个功能非常有用,能节省费用并能加快速度。自动优化功能的主要分析点有:
之所以我将上述这些功能扩展归纳为辅助功能扩展,是因为我认为如果没有这些功能,MaxCompute的核心功能不受影响,但是有了这些,让这个产品更好用了,而很多时候产品的成败,对用户是否好用,产品的辅助功能对产品的成功性影响甚至要超过50%。对于我们的开发同学,也要思考这个问题,在做好产品的核心功能之外,是不是也可以考虑一些“辅助功能”呢,可能很多时候,辅助功能花费的人力较少一些,但是效果比核心功能改进还大,RIO很高。
会上提到的统一计算平台这个概念,我觉得是个非常好的想法,这个统一计算平台,指的是统一MaxCompute,Flink,PAI。为什么能统一或者说为什么应该统一,因为他们本质上都是一个有着大量服务器资源的平台,其本质是将这些服务器资源共享出来供大家使用,按使用收费。不管是开源的Flink还是我们自己的MaxCompute,其技术架构非常的类似,本质上都要解决两个问题,一是要解决调度问题,如何管理好这些大量机器,更有效率的调度。二是要解决Shuffle及任务分片的问题。当然这里两个问题也不简单,要不然我们的MaxCompute进化史也不会是一部血泪史。
此外其实我们现在的大规模分布式在线架构也和离线大数据计算架构也类似,本质也是一个资源管控、注册调度问题,所以其实在线和离线的服务器也是能统一管控的,通过统一管控,进一步提高能效,因为在线业务一般是白天高峰,离线业务一般是晚上高峰。实际集团已经这么做了,通过这个技术为集团提高了能效,同时间接降低了数据计算的成本。
人工智能实验室发布的几款产品可以考虑体验一下,天猫精灵2.0看起来不错,值得拥有~_~
个人感觉人工智能其实还有很长的路要走,目前都还需要大量的人工训练,有多少智能就有多少人工,其本质仍然还是暴力计算能力。有很多挑战性问题待解决,但是这也是一个好事,我们的孩子们可以继续搞这个了~_~。不过就算是现阶段的人工智能技术已经很有价值了,已经能大大的提高生产力了,例如语言识别、智能客服、汽车保险的自动定损、无感刷脸支付等等场景,未来这个场景还能够更多。未来随着人工智能技术的发展,会给人们的日常生活带来更多的便利。
自动驾驶是智能化方面的典型应用场景,也是非常有挑战的应用场景。以前以为自动驾驶就只是在车上下功夫,此次参会听到的新思路是车路协同,在路网上部署传感器,解决死角的问题,并且这些传感器通过共用统一的协议可以被路上的所有智能汽车使用,降低车上的传感器数量,降低智能汽车的成本(不过如果这些车开离了城市到了广大的郊外怎么办,还是要依靠传感器,只不过郊外的路况没有城市那么复杂)。车路协同方式的准确率仍然还没有到100%。而自动驾驶对安全的要求很高,还需要整个业界继续努力。
地图行业是一个技术很有挑战性的行业,涉及到数字化、在线化、智能化的所有方面。地图的基础数据采集是数字化;如何支持亿级DAU是对在线化的挑战;智能化方面的应用也很多:例如如何利用智能化提高地图数据采集生产的效率,如何自动识别路牌等等,地图领域存在不少的智能化应用场景。
本次会上听到了一个比较有意思的智能化应用场景,我们现在的交通状况,都是当时实时的交通状况,路线规划也是基于当时的交通状况来给出的,可能有些同学(尤其是北京的同学)有过这种经验:出发前明明规划了一条不赌的路线,可是按这条路线开着开着就发现堵起来了。这是因为求路的时候只是考虑了当时实时的交通路况,没有考虑到一段时间之后的路况(实际路是有关联的,路况会联动变化)。清华大学的教授联合高德做了一个《基于深度学习的大规模城市路网旅行时间预测》就是为了解决这个问题的。和其他的机器学习场景类似,这个问题的复杂性也比较高,T+N时刻的交通状况预测问题复杂性高,其次就算这个问题解决了,给路径规划又提出了新的算法挑战。
高精地图是自动驾驶的必不可少的基础设施,自动驾驶离不开高精地图 + 高精定位 + 高精终端。高精地图的首要要求是高精定位,有了高精定位,地图采集才能精确到厘米级,高精定位用的是由千寻提供的高精定位服务。千寻的高精定位服务是通过卫星 + 基站的交叉定位方式来最终实现高精定位的。
未来一切专而精的能力都是以云服务的方式来提供。高精定位服务就是一个很好的佐证。高精定位服务需求量大,特别适合放到天然具备弹性能力的云端,作为一个SaaS服务。同样,高精地图未来也比较适合以SaaS的方式提供服务。
因为我本人以前的工作经历(当当、京东),所以选择了电商平台专场。
如前文所述,电商能力SDK有非常大的SaaS潜力。这是一个非常复杂的事情,业务上没有先例可参考,在如何提供SaaS服务这个主题上,建议可以参考参考Salesforce @侯前明
我在团队内部和大家讨论过AWS的 Lambda(函数式计算,FaaS产品)的可能实现方式(虽然我们Snowman技术小团队主要是做业务的,不是做云或者中间件的,但是YY猜测一下技术实现也是有裨益的~_~),其中有一个问题是:FaaS的负载升高情况下的自动扩容是如何实现的?猜测有两种可能的方式:一是代码的热加载,二是启动容器的方式,在上传Func的时候就制作好容器镜像。当时我们觉得可能是前一种方式(虽然这种方式有很多问题要解决,比如多种开发语言的问题);因为后一种方式,容器启动太慢,根本无法满足FaaS对20ms启动的性能要求。本次Severless专场也有一个阿里云函数式计算专题,给出的答案是后一种方式:启动容器的方式。
不过阿里云用了个改进的方法来解决这个延时问题:容器预启动。具体来说是:根据负载预测来提前启动容器,多启动出来的容器不收取用户的费用。虽然有点资源浪费的问题,但是延迟问题、用户体验问题解决了。当然做好这个的前提是要求准确的负载预测。阿里云的Bazaar平台来解决了这个问题(我认为在负载暴增的极端场景下,这种方式有点问题)。
数据中台专场是将集团的数据中台建设经验,OneData理念共享给阿里云的外部客户,让他们少走弯路。Dataphin是一个集成了集团OneData理念的产品,再加上Quick BI产品,帮助客户快速在阿里云上搭建自己的数仓,快速挖掘数据资产的价值。
最后发两张本次2018杭州云栖大会展厅图片,给没有去现场的同学感受一下高大上(抱歉没带摄影师,大家凑合看~_~)
赞整个大会的组织,很成功,从会场返回的班车上遇到数据库专场的组织MM,了解到他们为了这个会议做了大量的幕后工作,真的是很辛苦,给他们点赞!