计算和存储分离是近几年大数据架构领域颇受关注的一个技术风向。在对刚刚过去的 2019 天猫双 11 技术进行总结时,阿里巴巴 CTO 行癫也特别提到了阿里在计算存储分离上的进展。大数据最初兴起之时,主流网络带宽只有 100Mb,通过网络远程访问数据实在太慢了。为了解决数据快速访问的问题,Google 创造性地提出了计算和存储耦合的架构,而 Hadoop 延续了这个架构,风光一时无两。但十年过去之后,如今的网络带宽相比当时已经增长了一百倍,达到了 10G 以上,IO 不再是大数据的瓶颈,计算才是。
近日,InfoQ 有幸采访到了阿里巴巴计算平台资深技术专家胡月军(花名一浪),聊了聊阿里搜索与广告引擎的技术演进脉络、阿里新一代交互式分析引擎以及大数据领域近几年的技术趋势和变化。在采访中,胡月军表示:“计算存储分离使存储和计算资源可以各自根据需求进行伸缩,较好地节约了成本,但也给高效引擎的设计与实现带来了不少挑战。”他还将在即将召开的ArchSummit全球架构师峰会上2019(北京站)上担任「实时计算的平台化实践」专题的出品人,感兴趣的读者可以关注。
InfoQ:您曾经负责阿里巴巴多个不同业务线的搜索与广告引擎,能否请您给我们整体梳理一下这几年阿里不同搜索与广告引擎的技术演进脉络?比如可以分成哪些阶段?不同阶段技术上的侧重点有何不同?
胡月军:近年来,伴随着电商平台商品量的大量丰富,基于实时推荐的智能化运营兴起以及对提升购物体验和促成交持续优化的业务背景下,搜索和推荐的引擎技术也大致经历了三个阶段。第一阶段主要关注点在引擎检索性能的提升,当时我们做了很多关于索引构建、查询流程以及算分等组件的优化来提升引擎的 QPS;随着业务实时化需求越来越迫切,第二阶段我们引擎在在线和离线都做了不少工作,在线引擎实现了内存索引以及辅表关联,离线基于 Flink 孵化了 Blink 的流计算引擎和 Porsche 在线机器学习平台,大大缩短了端到端的处理延迟,大幅提升了搜索和推荐的实时性购物体验;第三阶段引擎的进步主要来自于支持算法的高效迭代和持续提升搜索和推荐的精准性,我们将引擎的召回和算分进行了分离,抽象出了 RankingService 服务,从而支持各种搜索和推荐召回场景的统一打分,同时支持在线深度学习计算,较好地提升了购物体验和成交引导。
InfoQ:阿里云新一代交互式分析产品诞生的背景是什么样的?为什么你们要在阿里的 MaxCompute 大数据计算平台、EMR 开源大数据计算平台、实时计算平台之外再打造一个新的交互式分析引擎?是为了解决哪些问题?
胡月军:阿里云计算平台交互式分析引擎的高效存储在 16 年就开始研发了。一开始开发交互式分析引擎的目标是为了解决 HBase 的稳定性和性能问题,基于存储计算分离和纯异步的 runtime 我们实现了高性能的存储引擎,上线以后性能是原 HBase 的 3~10 倍。后来基于业务需求,演进成了兼容 PG 生态的大数据实时数仓系统。
它和阿里的其他大数据平台有着不一样的定位:MaxCompute 平台是阿里自研的高效离线数仓系统,主要 focus 在高吞吐的批处理;EMR 平台主要是为了方便公有云上的客户快速搭建自己的开源大数据解决方案;实时计算平台主要关注流处理这块的业务;至于交互式分析,我们主要是为解决实时数据存储和 OLAP 分析的高效即席查询问题,同时实现对 MaxCompute 的离线数仓进行直接查询加速。
这些不同的平台通常会合在一起给客户提供一个完整的大数据解决方案。一个典型的场景是:数据通过 Flink/Blink 进行实时 ETL 处理后写入交互式分析的存储系统,然后用户在交互式分析引擎中进行各种 Ad Hoc 的查询;如果用户需要执行批处理任务,再把数据导入到 MaxCompute 中进行处理;此外,对于已经在 MaxCompute 中的数据,可以使用交互式分析进行直接加速查询。
InfoQ:阿里云的交互式分析产品是否有对标的商业化产品或开源产品?如果有的话,它跟这些对标产品相比,有哪些技术上的差异和亮点?
胡月军:在业界和阿里云交互式分析对标的一些产品有 Redshift、Snowflake、GaussDB 和 Hermes。阿里云交互式分析的主要技术亮点有:基于存储计算分离的高效行列混合存储,基于 Orca 和支持联邦查询的优化器,纯异步高性能的查询引擎,以及 PG11 生态兼容等特性。
InfoQ:近 3 年来,您主要从事存储与计算引擎的设计与研发工作,如果从大数据存储层和计算引擎这两个层面来看,您认为最近这三年有哪些值得一提的新技术或项目?技术趋势上有哪些变化?
胡月军:个人认为近 3 年大数据存储和计算领域比较有意义的新技术就是存储和计算分离的兴起,比如 Snowflake 等,它使存储和计算资源可以各自根据需求进行伸缩,较好地节约了成本,当然这也给高效引擎的设计与实现带来了不少挑战。比如怎么设计专门的存储机型和高效 I/O 实现?怎么优化网络连接?怎么在计算节点 I/O 延迟可能会增大的情况下保证 query 处理的低延迟?
技术趋势上,个人看到的一个趋势就是大家对存储层的重视,比如 Databricks 开源了 Delta Lake,对于阿里云的交互式分析引擎来说底层存储引擎也是一个非常重要的竞争力,事实上只有做好了存储引擎和数据的统一管理才能使得上层的计算更高效和统一。
InfoQ:有观点认为“17-18 年是计算引擎火热的一年,现在这块已经是红海了”,您是否认同这一观点?您认为当前大数据计算引擎处于什么样的发展阶段?市场是否已经饱和?接下来计算引擎这块还有什么值得关注的技术方向?
胡月军:这两年各种开源的计算引擎确实发展得很快,比如 Flink SQL 的流批统一处理,Spark Structured Streaming 的完善以及 MPP 引擎 Greenplum 的 6.0 的发布。但红海可能还不至于,据我们调查了解,目前很多公司的大数据解决方案还是基于 Hadoop/Hive,新引擎的市场普及度还处于早期阶段。
对于计算引擎本身,个人认为图计算和图像、视频处理的高效支持可能会是值得关注的技术方向。随着当下推荐、信用和安全等需求的兴起,对于关系的存储和处理越来越重要,目前各家引擎对图计算的支持还处在各显神通的阶段,后面的发展值得关注;图形和视频处理带来向量计算应用目前也原来越来广泛,目前已经有几家陆续将自己的技术开源。
InfoQ:计算引擎之外,大数据存储层今年出现了不少热门话题,比如数据湖、实时数仓。您怎么看今年实时数仓和数据湖的火热?
胡月军:实时数仓的火热本质上还是来自于业务的驱动。当下,智能推荐和精准运营等业务都依赖于对实时数据的快速挖掘。小时级别,或者天级别的数据分析对于很多业务来说再也回不去了。
再说数据湖,当前的数据仓库一般存储的是经过 ETL 清洗过的数据,原始的数据信息会有一定的缺失,所以现在有人提倡也存储各种原始的数据,从而进行各种灵活的分析。数据湖就是这样一个解决方案,提供统一的数据同步、存储和管理机制,以及计算任务的提交和调度,它强调对数据更全面和系统化的管理和应用。按我个人的理解,数据湖就是一个概念,像数据仓库一样,只不过其提倡保存更多的原始数据以及加强对数据管理的控制。底层的相关技术应该还是基于当下的存储和计算技术,没有太大的革命性变化。
InfoQ:2019 年 6 月,谷歌以 26 亿美元收购数据分析公司 Looker。同月,Salesforce 宣布以 157 亿美元收购 BI 企业 Tableau。2019 年 9 月,Cloudera 宣布收购商业智能实时分析厂商 Arcadia Data。这几场收购对于大数据领域来说意味着什么?统一数据分析平台会是大数据领域下一个技术爆发点吗?
胡月军:个人理解这些收购反映的是大数据公司对上层数据分析业务系统的渗透和把控,这样的整合应该会给用户带来更好的分析系统使用体验,比如数据分析服务的云化,从而使得公司能更好地占领 PaaS 和 SaaS 市场。
一体化的数据分析平台会实现数据的统一存储和管理,以及各种分析任务的调度和执行,在避免数据搬迁开销的同时给用户提供统一的使用体验,个人认为这将会是一个水到渠成的结果。
活动推荐:
流批处理合一的时代,多数公司还停留在实时计算平台化的起步阶段,要解决很多技术问题。12 月 6 日北京 ArchSummit 全球架构师峰会上,由胡月军老师出品的实时计算平台专题,邀请了网易、阿里、Uber、Freewheel 公司的讲师来分享 Kudu 应用、数据中台、Kafka、Flink 实践内容,帮助大家更好地理解平台搭建、实时数据处理等技术内容。感兴趣参会的可以联系票务经理 灰灰 15600537884(同微信)
评论