ArchSummit2021年寰球架构师峰会于4月25日-26日在上海举办，袋鼠云运维开发技术专家沙章利（花名：浣熊）应邀出席此次峰会，并在4月26日下午的《弹性架构实际》专题会场上为大家带来《弹性云原生大数据系统架构实际》的演讲。本次演讲次要介绍袋鼠云基于数栈、联合数年大数据基础设施建设教训，打造云环境下的大数据基础设施的实际和案例，局部架构细节首次对外颁布，以下内容整顿自本次架构峰会。

大家好，我是来自袋鼠云的浣熊，感激这次会议的讲师们给咱们带来了云原生技术利用的分享，感觉又关上了几个新脉门，解锁了新的武魂。在接下来的分享中，心愿大家跟着咱们的实际案例做一些探索性的思考。

首先咱们疾速回顾下大数据技术的倒退，而后重点给大家分享咱们最近几年做的一些零碎云化架构，最初再做个回归总结，心愿能给大家带去有价值的思考。

大数据技术的倒退

大数据技术的发展史也是大数据架构的发展史。

云原生大数据技术是否是新一代大数据处理技术？

1964年，IBM公布了System360，这是计算机发展史上的里程碑事件，System360上装备的磁盘驱动器(DASD)减速了数据库管理系统（DBMS）和关系型数据库的倒退，DBMS和关系型数据库的呈现使数据处理的效率大大晋升，一些规模较大的银行、航空公司开始引入数据库软件解决业务数据，这能够追溯为第一代(大)数据处理技术。

随着寰球经济的疾速倒退，须要解决的数据量也越来越大，单解决架构曾经无奈满足数据处理需要，有问题就有解决方案，针对这个问题美国Teradata公司推出了并行计算的架构，就是咱们明天常说的MPP架构，在MPP架构的技术根底上，Teradata的数据仓库建设技术一直倒退，在与过后的巨头IBM的强烈竞争之下，Teradata依靠沃尔玛建设了过后世界上最大规模的数仓。这一代技术的关键词咱们总结为MPP+数据仓库。

Hadoop生态的呈现多少有点意外（眼前一亮），Hadoop、HDFS及其开源生态圈能够应用更低廉的X86机器，通过疾速横向扩容的形式就能满足PB级别数据处理的需要。十多年的工夫，从Hadoop（MapReduce）到Spark、Flink等，开源生态的计算框架一直演进，基于内存的Spark、Flink计算架构曾经与具体的存储解耦，奠定了开源生态大数据系统计算与存储拆散架构的根底，咱们把开源生态这一系列看作是新一代大数据技术。

在云计算红利的推动下，大数据系统上云是必然的趋势，Teradata在2016年把本人的数据仓库搬到了私有云上，AWS也在2014年上架了数据仓库型产品Redshift，阿里云上的MaxCompute（晚期叫ODPS）是国内云上高性能并行大数据处理技术的里程碑。

去年9月份Snowflake的上市，把云原生数据仓库的话题推上了风口，私有云厂商开始从自家云产品的角度做出对云原生数据库、数据仓库、大数据平台等的解答。相比拟前几代大数据处理技术，云原生大数据处理技术是否能称为新一代大数据处理技术呢？带着这个问题，咱们来看下在大数据系统云化方面咱们的一些架构实际。

大数据系统云化实际

私有云上的大数据产品曾经倒退成熟，因为社区倒退成熟、技术自主可控等特点，开源生态大数据体系曾经在国内外头部私有云平台上先后上架，各家私有云厂商配套上架了成熟的数据开发套件。

通过了数年大大小小生产级实际测验，间接选型私有云大数据产品，即可享受按需创立、秒级弹扩、运维托管和海量的大数据处理能力。然而因为种种限度，一些传统大型企业、金融行业等的外围业务并没有到私有云上。各行业在谋求云计算红利的过程中，又心愿把更多的业务零碎上云。在这种抵触下，公有云和混合云失去一直倒退，这类云上的产品状态也日渐丰盛，曾经由晚期的ECS自在逐步倒退成中间件自在。

大数据时代，大数据处理和剖析是企业的共性需要，以批处理和流解决为代表的数据处理平台逐步下沉为企业的大数据基础设施，若能实现大数据基础设施自在，即实现大数零碎的按需创立、按需扩缩、运维托管，即可为企业内和行业客户提供疾速可复制的大数据处理能力。

开源大数据处理系统以简单著称，以数栈为例，底层的存算层兼容支流的Hadoop发行版，两头的的计算层可凋谢集成支流的批流、算法、图计算框架，既反对传统的MapReduce计算框架，也反对存算解耦的内存计算框架，下层应用层建设在数据共享、数据资产治理、数据可视化治理等外围数据利用之上。

在VM/PM环境下，部署和运维这样一套大数据基础设施零碎，也不是一件容易的事件，晚期须要咱们1-2名中高级施行工程师，间断1-2周工夫，能力实现这样一套零碎的部署和调试。如何实现整套零碎的云上自动化交付，成为咱们零碎云化架构的第一个指标，即实现大数零碎的云上体验、按需创立。

1、第一套云化架构

第一指标达成要害是云化部署架构和自动化部署技术。

1）首先要考量的是云化模式，模式的不同如共享模式、独享模式等，将间接影响云化部署架构。

共享模式下个别以多租户的形式反对，一个机构共享一套基础设施，套内共享存储、计算和数据利用，资源之间以多租户的形式进行逻辑隔离，共享模式的长处是部署简略，毛病是租户间资源会互相抢占。

独享模式的隔离性会更好，然而按需创立的自动化部署技术是个难点。

2）第二个要考量的是公共零碎对接，例如对接IaaS获取动静IaaS资源，对接用户、降级、监控、计费等公共模块，这部分不多说。

3）第三要思考云环境下的网络环境，比方治理网（underlay）和VPC（overlay）网络划分状况，网络拜访策略在制订部署架构前须要清晰。

4）最初也是最重要的，在环境筹备好之后，如何高效的实现零碎的自动化部署、服务发现、健康检查、监控数据接入等就比拟要害了。

为实现零碎的自动化部署和监控运维，从2018年开始，咱们自研了部署运维管家EasyManager（以下简称EM），EM的外围能力之一是实现对资源的治理和服务的编排、管控。

把EM的Agent和服务编排模版打进零碎镜像是自动化部署的最佳实际，VM启动的过程就是服务启动的过程，服务启动后主动注册至EM-Agent-Server，下层管理网络通过Agent-Server以服务的粒度实现对系统服务的管控，同时基于主动的服务发现机制，配套施行监控数据主动采集汇总、供查。

零碎主动部署起来后，在独享模式下，为实现动静集群（实例零碎）的拜访，咱们引入Traefik来解决动静代理问题，Traefik是一个不错的免开候选，Traefik反对从Zookeeper、Redis等配置核心动静加载路由配置，自动化部署模块拿到集群（实例零碎）地址信息后写入配置核心，Traefik热加载配置并依据路由规定进行申请转发。联合Traefik动静路由的能力，拜访申请能够通过对立的IP或域名进入，经由Traefik依据全局惟一的集群（实例零碎）ID进行申请转发。

解决了以上几个关键问题之后，第一指标根本能够达成，配套上订购（创立）页、实例控制台，就实现了大数零碎云化架构的第一个实际摸索。这个实际的后果是能够实现5-10分钟疾速创立一套独享的（云化）大数据系统，且反对在线扩容，根本实现了上云体验、按需创立的零碎云化指标。

这套云化架构没有动业务零碎自身的架构，容易落地是长处。当然毛病也很显著，首先不是标准化的云化计划，各个依赖零碎如IaaS的对接须要依据具体云化环境定制，革新老本高；其次零碎上云后的弹性能力并没有失去晋升，勉强能够在线扩容，无奈实现闲时缩容。基于这两个毛病的思考，咱们尝试了第二个云化架构。

2、第二套云化架构

为实现IaaS层对接标准化，咱们做了零碎的容器化革新和Kubernetes部署对接，并自研了无状态利用和有状态利用部署Operator。在零碎组件全面容器化的根底上，联合一套自定义的Schema，构建面向Kubernetes的制品包，这个制品包能够通过EM一键部署到Kubernetes集群。

为实现零碎弹性能力的晋升，依靠开源社区计算框架对Kubernetes的适配，咱们做了产品层的封装，实现了把Spark和Flink的计算工作提交到Kubernetes执行。利用Kubernetes弱小的资源管理能力，实现计算资源的弹性扩缩。

这套架构的另一个特点是兼容On Yarn模式，这个点很受企业的欢送，起因是即能拥抱Kubernetes大法，又能持续应用已有的Hadoop基础设施进行生产，兼容并蓄，领导开心。

这套云化架构能够解决上一套遗留的问题，通过集成Kubernetes，实现对底层IaaS资源对接的标准化，同时晋升了计算资源的扩缩能力，实践上是秒级的。当然也产生了新的问题：

计算工作提交至Kubernetes后，计算资源的弹性失去保障，但同时计算真正意义上的远离了数据，这对计算性能是否有不良影响？计算的弹性解决了，那存储的弹性怎么办？

第二套云化架构上，架构调整的角度曾经从部署架构转移到零碎架构层面，咱们开始调整零碎的计算架构，即用Kubernetes代替Yarn作为计算资源管理者，这是在面向云环境做零碎架构适配。

在咱们进一步思考存储架构调整的时候，咱们从新扫视零碎云化实际的过程，咱们发现咱们的实际思路产生了扭转，总结下来就是从构建云（云化）到基于云构建的思路转变。大数据系统的弹性能力也是数据的解决能力，从弹性的诉求登程 ，利用云化或者云原生技术对立治理资源池，实现大数零碎产品、计算、存储资源池化，实现全局化、集约化的调度资源, 从而实现降本增效。

咱们再回到大数零碎云化架构上，产品和计算资源曾经能够通过Kubernetes实现资源池化治理，思考云化环境下实现存储能力的弹性诉求，依靠计算框架对底层存储的解耦合，参考对象存储在私有云上的实践经验，咱们把底层存储切换成分布式对象存储，这个架构选型上次要考量以下三点：

在公有云环境下，基于OpenStack、Swift、Ceph这些能够提供对象存储服务的开源软件架构曾经在生产实践了多年;开源生态的计算框架兼容对象存储服务；兼顾数据湖存储选型，而后咱们尝试了第三种云化架构。

云原生技术驱动下的大数零碎云化架构演进

3、第三套云化架构

为满足存储的弹性和海量存储的需要，咱们引入对象存储，为兼容私有云、公有云和现有其余成熟的对象存储服务，同时尽可能进步读写性能，在计算和底层存储之间咱们加上一层缓存（选型参考JuiceFS、Alluxio）。其中存储层，在私有云环境上间接选型私有云的对象存储，在公有云环境下选型OpenStack Swift、Ceph、MinIO等成熟的开源计划。

这套架构重点是从存储的角度，尝试革新零碎的存储架构，同时兼容现有的HDFS存储，相比之下更适宜在动静的云环境中落地，实现利用、计算、存储三层弹性可扩缩。目前这套架构还在外部性能测试中，如下是们其中一组性能测试数据（大文件词频统计），加上性能和缓存优化后的存储性能合乎预期。

总结和瞻望

参考云原生基金会（CNCF）对云原生的定义，“云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用”，从定义上看跟咱们大数零碎云化的需要不约而同。

利用容器化、服务网格、微服务、申明式API等云原生技术，实现在私有云、公有云和混合云等云化环境下构建和运行弹性可扩大的大数据系统，这是咱们对大数据云原生的了解，也是咱们拥抱大数据系统云原生的形式。

明天通过三个具体的大数零碎云化架构，给大家出现一个残缺的架构过程，心愿能给大家带去思考和帮忙。而后咱们再回到结尾那个问题，云原生大数据技术是否是新一代大数据处理技术，置信大家曾经有了本人的答案。

每一代大数据技术根本都是为了解决上一代技术存在的问题，云原生的方法论和技术路线符合了大数据系统云化过程中求弹性、求扩大的诉求，对大数据系统云化具备领导和实际意义。当然云原生不是银弹，只有联合本身业务零碎的倒退诉求，能力更好的享受其带来的红利。

最初做一点瞻望，因为种种限度和云化技术积攒不平衡（私有云的技术积攒大于公有云、混合云）等起因，私有云和公有云混合架构场景有待进一步摸索和实际。数据湖和大数据云原生的架构出现一种架构交融的趋势，咱们会在云原生的湖仓一体的新型交融架构上做更多的尝试，谢谢大家。

数栈是云原生—站式数据中台PaaS，咱们在github和gitee上有一个乏味的开源我的项目：FlinkX，FlinkX是一个基于Flink的批流对立的数据同步工具，既能够采集动态的数据，也能够采集实时变动的数据，是全域、异构、批流一体的数据同步引擎。大家喜爱的话请给咱们点个star！star！star！

github开源我的项目：https://github.com/DTStack/fl...

gitee开源我的项目：https://gitee.com/dtstack_dev...