阿里专家分享：企业级大数据轻量云实践

最新推荐文章于 2024-06-17 22:31:37 发布

gaokeke

最新推荐文章于 2024-06-17 22:31:37 发布

阅读量319

点赞数

文章标签：大数据

点击▲关注 “数据库技术大会” 置顶公众号

作者 | 井诚

编辑 | 谢涛

本文根据井诚老师于第九届中国数据库技术大会 (DTCC 2018) 的现场演讲《把大象装进冰箱企业级大数据轻量云的实践》内容整理而成。

讲师介绍：

井诚

阿里巴巴技术专家，2004 年毕业于哈尔滨工业大学，有着多年的商业 IT 软件系统与互联网行业的研发、测试与交付经验。目前服务于阿里集团计算平台事业部，主要从事大数据云服务工程化方面的工作。

分享大纲

1. 源起：阿里的象群们;

2. 轻量化过程中遇到的挑战;

3. 解决之道：切割象群;

4. 未来之路　

一、阿里的象群们

首先给大家简要介绍一下阿里的象群，阿里的大数据服务比较多样、丰富，第一块就是我们的大数据计算服务 MaxCompute，MaxCompute 是用来做离线计算和处理的，第二块就是一个分析型的数据库，大概就是一个 online 或者 MPP 的数据库，然后第三块也是业内比较常见的流计算引擎，第四块就是数据通道服务 DataHub，第五块就是阿里最著名的数据中台 DataWorks。阿里的象群主要由这五块服务组成。

以下是这些服务在功能特性方面分别对应的开源界的一些生态的小伙伴，有些对比不一定恰当。最后一块 DataWorks 比较特殊，它是一个数据中台，这个概念是阿里率先提出的。基于阿里自身这么多年业务积累了非常丰富的海量数据，然后如何把这个数据利用好，阿里可能是——我们夸大一点说——业内甚至全球首先遇到相应挑战的，所以在数据中台建设上我认为开源社区并没有一个很好的对比的场景。

我重点介绍一下 MaxCompute，MaxCompute 的发展也很有意思。其实我遇到很多朋友在问我，MaxCompute 是不是基于 Hadoop 去改的或者开发的? 其实不是。2010 年到 2012 年的时候，阿里的数据栈已经非常大了，那时还用的是 Hadoop，在集群规模变得非常大、阿里打算把 BU 之间的数据完全打通的背景下，发现当时的 Hadoop 确实有很多各种各样的问题，主要就是性能问题，然后在内部经过了一个很激烈的、长时间的、甚至是痛苦的决策，最后决定自己做一套东西，所以从 2010 年左右就彻底放弃了 Hadoop 这条路，完全从头自己开发了一套系统，当年是叫 ODPS。从 2010 年开始就一直沿着自研这条路去走，发展到 2013 年的时候集群规模超过了 5 千台，发展到今天 MaxCompute 已经完全在阿里内部所有的事业部，包括蚂蚁金服、高德完全落了地。我来自的这个部门就是在做 MaxCompute，我们服务的就是整个集团的大数据引擎部分。目前我们的单集群已经过万了，去年双十一当日就处理了 320PB 的数据，非常惊人。另外，在公有云和专有云上也做了很多输出。

AnalyticDB 是阿里巴巴自主研发的能够满足海量数据实时多维分析的大数据产品。分析型数据库主要是应用的一个场合是在海量数据下去做 CRM 的报表分析，阿里也是一个数据公司，很看重商业数据挖掘，所以 AnalyticDB 在海量数据下做频繁的交互和查询的 BI 报表有很好的效果，其响应的速度是非常快的，基本都是秒级的响应。在去年双十一和双十二两天，整个集团是批量导入了 1 万亿条的数据，然后实时落盘 Optimize 的数据是 1 千亿条。我们集团内部落地的集群的规模也是突破了 1 千台，性能非常高，那这两个是我们当前大数据比较核心的地方。

二、遇到的挑战

2016 年的时候国内正好是私有云或者说大数据云计算风起云涌的一年，市场上涌现了很多轻量化的大数据云平台。对阿里而言，阿里从来是大规模到超大规模，单集群规模过万; 从单机房到多 region 的方向发展; 拥有日益强大的基础与运维服务; 精通阿里大数据运维技术的 SRE 团队; 7*24 小时高效处理平台问题。此时私有云和专有云客户的挑战在于：只有小至 10 台左右的规模诉求; 缺乏完善的底层基础设施; 对阿里大数据开发 / 运维技术都不甚了解; 能最终解决平台问题的人，难以快速访问平台。

所以到 2016 年想做这个事儿的时候就发现，阿里手上并没有一个很确定的解决方案去解决它。大家都是基于轻量级的，但是阿里当时是反过来的，我们有超大规模的工程能力，因此怎么把它布小就变成了一个挑战。所以我们当时遇到的挑战就是，怎么去把刚才讲到的这些大象，一块一块割小，割到一个 10 台左右的规模然后去推给客户。

我们大数据轻量云的产品理念就是，以私用云的形态，将 MaxCompute、AnalyticDB 与 DataWorks 为代表的阿里大数据计算能力，用尽可能低的门槛输出给客户，普惠各行各业。、所以当时的产品矩阵是，底层基于飞天分布式操作系统 Apsara，然后去把大数据引擎，刚才讲的 MaxCompute、AnalyticDB 都输出去。再上面就是阿里常用的一些大数据应用，比如说 DataV 还有 BI 报表。产品架构就是这样。

关于期望达到的技术目标，我们总体列了五点。第一点肯定是要轻量化的，将公有云上 20 + 的管控服务器规模，压缩至 7 台以内; 第二是从商业角度考虑，1 台服务器损坏不停服，2 台服务器损坏不丢数据，提高可用性; 第三个目标是可升级性，有能力升级至专有云企业版，提供全量云计算服务能力; 第四是可扩展，易于扩展增加新产品; 最后一块就是易运维，对于新接触阿里大数据技术体系的人，能快速掌握基本运维操作。

三、解决之道

我现在来讲一下我们当时是怎么做这件事情的。首先是飞天，飞天是阿里云产品底层的分布式操作系统，由盘古 / 伏羲 / 女娲三大部分组成。这个盘古是一个分布式的稳健操作系统，有很强的容错性，很高的性能; 女娲是一个协调服务，有点类似社区的 ZK; 伏羲就是资源管理和任务调度。当时在公有云和集团内部，我们每一个集群的规模是总共 13 台服务器，盘古是 5 台服务器，女娲是 5 台，伏羲是 3 台。因此在管控上，只是一个 MaxCompute 就有 13 台服务器。

在解决方案上，我们当时考虑用一个最流行的方式，就是把它 Docker 化，第一步 Docker 化我们把它挤到虚拟机上去做。还有一点就是考虑减少它的节点，因为 5+5+3 是非常过量的一个配置，所以我们经过一些容量的规划和测评，最后把它全部 Docker 化，用 3+2+3 的模式部署在了 4 台物理机上。所以在这一点上我们极大的把飞天管控压下去了，包括 MaxCompute 和 AnalyticDB 都是基于飞天的，如果不压缩的话这两者合起来就是 26 台物理机，但是压完以后在 4 台物理机上就可以搞定。

第二块是对运维管控服务做了一个极大的精简。天基是阿里云的核心基础运维系统，管理云平台中的硬件生命周期与各类静态资源。在我们的云体系中，天基上面管控了 60 多个服务，但是这个解决方案在我们轻量的方案中是不成立的。我们在轻量云里只有三个产品，AnalyticDB、MaxCompute 和 DataWorks。当时我们梳理了一遍这个整体的管控服务，还有他们互相之间的依赖关系，然后从里边认真筛选了一遍，把所有没有必要的依赖全部都砍掉了，同时也做了一些改造，最终从 60 多个服务压到了 10 个服务。然后天基的迷你版原来在公有云还有专有云中可能要 10 台服务器，压缩完以后就减少到了 3 台左右，在整体的硬件成本和规模上都节省了一倍以上。

还有一个就是比较常见的套路就是服务混布，这个概念其实在业内不是特别新鲜，就是我们把计算密集型，还有网络密集型，还有没有资源竞争关系的服务尽可能的布到一个服务器上。

功能调整。在轻量的条件下，一些原有的功能失去了意义，因为我们只有 12 台。所以这倒是一件干得很痛快的事情，就是看哪些服务没有用的就把他全部砍掉，刚才讲到的同城同灾，多 region，还有我们之前整个机群管理，因为有很多内部管理有很多变更的流程，还有很多智能监控分析我们都砍掉了。智能监控分析这一块我说一下，大家知道这个智能往往都是基于数据的，如果你的集群量非常大的时候，能产生大量数据的时候，这个智能是有意义的，但是当机群只有 10 台或者 20 台的时候，这个时候去搞基于数据化的智能运维也是没有太大的价值。所以当时也是梳理了一番，把很多的业务都砍掉了。

轻量化的中间件服务。SLB 当时物理机是 6 台，RDS 当时也是基于物理机去部署的，最少要两台服务器。在轻量的场景中，我们去找 miniLVS 或者 miniRDS 这种非常小巧的服务去替代原来庞大的物理机，在这个场景下我们节省了十多台服务器。

还有一点，白屏化运维。可能客户的运维的同学跟阿里运维的同学背景其实也不太一样，一个是技术体系的差异，还有一些习惯的差异。我们在做运维系统的时候经常会给很多很花哨的一些图表、性能趋势、性能变化，但是这些图表或者说有一些缩略语，指标的变化是什么含义，其实在解读上是很偏经验化的。当时考虑到这一点，我们紧急的梳理了一遍在运维上的有价值的指标，把太技术化的这种英文缩略语全部转换成一个更容易懂的术语。在系统故障检测上我们除了常见的自检排查、指标分析、日志分析、服务器状态监控之外，我们还利用这些数据去做故障发现，通过这些比较有规律的特征和指标，往往能够比较及时准确地发现一些常见的问题。

最后一块是比较重要的，就是全链路性能压测与稳定性测试。因为这个云平台上面有比较核心的两个组件，一个是 MaxCompute，一个是 AnalyticDB。我们单独去测它其实不会发现太多问题，很多时候是结合业务场景，在做全链路的时候发现一些瓶颈。包括我前面说到的裁减、删减，那么裁到什么比例是一个比较合理的比例，是需要经过一些验证的。我们根据客户的一些典型应用，比如离线计算的数据量、作业值、任务数，还有就是在 AnalyticDB 的数据存储等等，最终经过多轮的测试我们把刚才提到的优化点差不多都找到了一个最优的中间数值，最后实现了我们的原始目标。

还有其他的切割技术。如合理合并中间件资源，适度降低监控轮询频率，合并优化有重复的监控方案，调整日志 rotate 策略等等。

目前我们前三个目标都顺利得到了实现，第四块我们初步完成了运维操作的白屏化、傻瓜化，但我们的目标还没有完全的实现，因为运维目前更多还是偏经验去做的，我们为了弥补，也写了很多运维指南，然后在前端界面上也补充了很多操作指导，希望能够让用户快速掌握一些简单的问题处理方式。

四、未来

最近我们也有一些思考，这个思考更多的是偏这种业务方面的。因为我们当前讲到的东西都是一个云平台的，但其实前方传来更多的需求是偏应用平台的，应用平台跟我们做的这个平台比较大的一个差别，如下：

在这种场景下云平台这个底座——也就是天基这个底座，很多的能力和威力在应用平台上其实是很难发挥出来的，所以在这种应用平台场景下，我们当前考虑的就是要基于天基再进一步去做一些优化和删减，将它与应用平台富余出来的功能接着往下砍。

还有一块是可运维性。因为阿里集团内部很多时候运维工程师考虑的是怎么高效去处理一些问题，但是在应用平台上产生了一些特性可能会导致可运维性没有那么高，比方说有个东西坏了，他不需要现场修，也许拿回去返厂修了，没有那么强的当场解决的特性需求，所以在这种场景下，可能我们整个运维系统的一些设计目标和理念都会发生变化，对应的技术也会跟着去调整。

以上就是我的分享。在 (把大象塞进冰箱的) 这个过程中，我们从初始的一个很大的规模逐渐的裁到了很小，大概裁减到了 15 台服务器。