企业级数据平台云原生转型之路｜社区征文 - 文章 - 开发者社区

企业级数据平台构建背景

在没有大数据生态之前，企业内部大多数据量沉淀是有上限的，大多数的企业报表分析通过 Excel、Mysql、SqlServer 就可以满足相关的业务分析，随着互联网的蓬勃发展以及移动互联网浪潮的冲击下，数据量呈现了指数级的增长趋势，在原有的技术实现路径中已经无法满足这种大数据量场景的分析需求，于是，随着大数据开源技术的发展，以 Hadoop 生态体系为根基的大数据技术栈得以填补了这块的不足。

从技术上虽然实现了，但是组织上来讲大数据不像传统的分析工具那么轻量化、易操作、人员要求没那么高，反观大数据场景下，要维护很多组件、集群搭建、集群运维等等很多繁重的工作，更更重要的是人员成本比较高，在当时技术的稀缺性来看，人员成本较高是必然出现，所以，不可能按照传统的 BI 分析每个部门都有独立的数据分析团队路线的走，更多的是从公司角度成立一个大数据 BI 部门，来统一对大数据方面进行分析、计算、展示等等。

于是乎，这时候公司都会成立一个叫做数据平台的部门，简单来讲就是承接了 BI 的工作，只不过使用的是大数据的技术栈，能够处理的数据量级更大，满足的需求更加的丰富等等

picture.image

多元化业务场景驱动

上面背景中，提到技术升级提高了更加丰富的业务场景，比如推荐引擎、多维数据分析、历史行为分析、广告推荐策略、实时处理能力提升等等，这些在大数据背景下都得以实现。

随着业务场景越来越多、数据复杂度越来越高、衍生的技术组件也日益增多增强，以垂直单体的大数据架构显然是无法满足更灵活的业务场景能力的，所谓的垂直架构指的就是一个独立团队，支撑所有业务应用部门，来进行数据查看、数据提取等等，当有技术升级或者复杂度提升的时候，这种架构下很难来灵活转型，因为不具备通用性，从软件设计上来讲就是一种耦合架构。

在过去 10 年里，大部分公司都在做数字化转型，显然，数字化是以数据为支撑，辅助业务、战略、人力等进行全面提升的过程，那么在这时候就不仅仅是为了满足当下业务需求为主了，而要考虑未来企业数字化转型所面对的一系列问题，为了企业转型、人员效率提升等方面进行充分的考虑，这时候，组织上期望的一种效果是大部分的业务部门可以像使用 Excel 一样来使用大数据技术，大数据团队也希望更加的专注于技术优化和运维的角度，去构造一个稳定的地基。

picture.image

从技术架构上来看，过往从人为的进行分析、处理的大部分工作，都抽象成平台功能来实现，比如数据采集，在没有数据平台能力之前，每个业务做的数仓分析都需要单独配置一个 Sqoop 或者其它采集组件来进行数据采集，往往是人为去配置和监控，将数据采集能力抽象为平台能力之后呢？我们可以在平台上进行灵活的配置数据源、定时调度采集，也可以做一些简单的 ETL 的事情。

数据平台能力扩展

上面有提到数据平台的能力简单来讲就是一种功能的抽象，从数据采集、数据开发、作业调度、集群运维等这些集群组件来进行统一管理、统一使用，避免各自团队独立部署一套集群来维护，同时也为了消除数据孤岛问题，那在数据平台技术组件层面作为根基部署完成之后，对于平台来讲，就需要独立的基础架构团队来维护根基的稳定性，包括如下几点：

组件性能优化
组件功能扩展
权限控制
稳定性维护

只有在平台根基比较稳定的前提下，上层才能做更多的事情，那在根基之上，要做哪些事情呢？我们可以想象一下，平时在使用组件开发时会有哪些问题？包括数据采集、数据分析、数据调度、数据管理等等，简单了来罗列一下：

组件不统一，难以维护
代码本地开发，研发效率比较低
环境不统一，数据割裂
人为配置，效率比较低
组件繁多，版本不可控
缺乏安全管控，风险较高

基于以上种种，最终导致的问题就是严重影响了研发效率，业务部门就会天天跟在身后催促着，而且也会经常性的出现数据不一致问题，数据校验问题，从企业角度来看，这种技术架构难以实现数字化转型的要求，那么就必然会对整个技术体系进行升级改造，通常按照独立的单元模块来划分，如下功能来拆解：

picture.image

数据采集：从单一数据源到多种复杂数据源

数据采集通常来讲，是作为数据开发中相对比较简单的，但是在平台能力中，它是相对比较复杂的一个环节，在我们常规的数据开发中，可能仅仅采集一个或者几个数据源就可以了，但是在平台能力之上，它集成了 N 多种数据源，并且还要包含实时数据源、离线数据源、结构化数据和非结构化数据，同时还要在数据采集的基础之上做一些简单的清洗过滤的工作（有些敏感数据，业务不希望原样加载到平台中，就会在采集时配置脱敏、字段转义等等事情），那么对于整个数据采集的要求就很高了，简单的 Sqoop、Flume 这种组件很难以满足，通常会选择一个开源分布式高性能的数据集成系统来进行实行，这里可以选择的有 DataX、SeaTunnel、StreamSet、FlinkX（现在名字为：ChunJun）等等，他们都可以使用基于 Json 格式的配置文件方式来进行数据源的配置和采集，也支持一些 Transform 的工作，我们可以通过自己生成 json 文件来采集对应的组件即可。

在数据平台中，数据集成可以说是一个持续在迭代优化的工程项目，它的复杂点在于要保证数据的一致性、完整性、容错性，这就不仅仅是简单的拿过来就可以了，还要对比数据是否有缺失，数据转换异常之后应该怎么处理异常数据，是直接丢失还是单独保存？幸好，在很多开源的数据集成软件中（如上面提到的）都做的相对成熟，我们可以借助引擎的能力来保障数据的准确性，同时我们也需要针对性的做一些监控工作，来查看数据同步的最终结果是否是一致的

数据开发：从本地开发到拖拉拽算子模式

数据开发可以说是每个大数据开发人员都在做的事情，无论是 OLAP 开发、还是流计算开发、还是 BI 分析开发等等，以往基本都是在本地写一个 SQL，然后提交到环境中进行查看是否准确，这样的话其实开发效率很低，而且对环境有严重的污染（想想你的 SQL 里面是不是有很多临时表），那么通过平台能力开做的话就可以很容易并且高效了。

picture.image

数据平台提供了三个方面能力：

第一：拖拉拽算子的方式来生成计算脚本。

第二：Ad-Hoc（即席查询）的能力，可以在可视化页面中输入 SQL 语句来预览结果。

第三：自己写计算脚本，然后提交到平台中运行。

以上三种在不同的实现上可以满足不同使用人群的需求，比如业务分析人员不太擅长写 SQL，可以通过拖拉拽的方式来生成，开发人员可以使用 Ad-Hoc 或者自己写脚本上传的方式，因为平台本身提供了环境隔离，会定期的来清理一些脏数据，所以，开发人员不需要担心集群环境方面的问题

数据调度：从单独配置到开发和调度一体化

数据调度系统是整个数据平台中的中轴力量，属于数据平台四大支柱之一（数据采集、数据开发、数据调度、数据管理），数据采集的任务需要定期来同步数据，数据开发的作业需要定期来运行，这些核心功能底层都会通过调度系统来调度运行起来。

从过去我们一般使用开源的 oozie、azkaban、DolphinScheduler 等作业调度系统，来提交运行作业，那在平台实现中，通常会选择将开源组件来包装一下，然后在控制台中提供相应的调度策略，比如在配置完数据开发的任务之后，紧接着就会配置调度策略，是立即执行，还是周期性执行等等

数据管理：从数据量到数据质量的转变

数据管理是做数据平台中比较核心的功能，上面提到做数据平台使用于解决研发效率和数据质量的问题，那么如何对数据进行管控以及对于数据质量的分析就需要依赖数据管理的能力，数据管理严格意义来说是一个比较抽象的词，不像数据采集，就是用来同步数据的，数据开发就是用来做开发的，数据调度就是用来做调度的，但是数据管理无法从字面上来自己数据管理的标准是什么？具体的作用有哪些？

基于过往的设计经验，以及企业内部对于数据管理方面的诉求，我们将数据管理分开定义为以下几个模块：

元数据管理
数据质量
数据生命周期
数据热点管理
主数据管理
数据地图
数据血缘
数据预览

以上，有些是作为独立功能模块来定义的，有些则是在模块内的一个具体功能实现，数据管理是企业中实现高效数字化的基础，所以，在过去几年很流行的一个词叫：数据治理，我记得 2017 年在主导数据平台时，因为公司整个数据质量很差，有些 10 几年的数据没有人维护，也没有标准化定义，于是，我们花了很长时间来做数据标注，后来随着平台体系化建设逐步完善，对于数据的要求越来越高，才会出现了数据治理方面的专项内容。

通常，数据治理是作为一个企业内部战略来定义的，如果没有将数据治理工作作为从上到下来推动执行，那么，很难说会取得什么效果，基本上就是步步维艰，公司有很多业务线，不同的业务线都有很多数据库表，如果没有业务配合来执行数据团队根本就无法执行下去，所以一般会有 COO 或者 CTO 来牵头处理。

集群运维：从故障频发到可持续运维保障能力

如果企业内部使用的是自建的大数据集群，然后多个大数据开发来使用这个集群的话，那么大概率你会遇到很多如下的问题：

任务跑着资源不够了
组件异常停止了
计算作业和组件出现了兼容性问题
任务一直卡住不动了

等等类似上面很多运维层面的问题，每次基本上都是简单粗暴的重启恢复，我当年也是苦于这种状况困恼了半年之久，于是，花费了大力气构建了整个大数据的运维体系，先从任务监控开始，发现任务异常之后先重试，重试不行就开始告警，总之就是优先保障第二天报表能出来，所以，当时那段时间每天半夜三四点起来处理任务失败问题，再后来随着运维体系的完整建设，补充了日志采集、异常告警、自动恢复、任务优先级、集群巡检等等方面的措施，才得以有一个安稳的睡眠，到这里可以稍加补充一句：技术的本质是降本增效，降本增效是通过逐步探索和不断通过系统化的方式来解决各种现实中的问题沉淀出来的，所以，无论是平台建设、系统搭建、自动化/智能化等措施都是遇到了耗费人力的问题从而想到的一种解决方案去处理，这样能够极大的释放人力的消耗，也就达到了降本增效的目的。

安全管控：从无权限到字段级权限管控

安全管控是为了解决多个数据团队共用平台时，实现信息隔离的一种手段，一般不通的团队会划分不同的项目，每个项目会划分不同的角色，不同的角色有不同的权限，比如开发者可能只有数据采集、数据开发、数据调度权限，但是没有资源管控、运维管理的权限，BI 人员可能只有数据可视化方面的权限，没有数据采集、数据开发权限等等，这个具体的权限定义要根据不同公司对于业务岗位、平台能力的实现不同而设定，总之，这是一个比较灵活的定义。

在大数据组件中，也有对应的权限管控的组件，目前使用比较多的还是以 Ranger+Kerberos 为主，通过平台可以申请对应的认证信息，然后在作业执行时加载到对应的任务里面，他们也可以做到数据表和字段层面的权限控制，对于数据敏感度较高的企业来讲，这是很重要的一个功能点。

资源管理：从资源割裂使用到按需分配

资源管理通常是和运维管理一体的，运维系统会负责资源方面的统一分配和纳管，对于集群的扩容、缩容、不同项目的资源分配比例等，同时，资源管理可以最大化的实现集群资源的利用率，可以根据不同时间段、不同任务优先级来动态调用资源大小，这里一般还是以 Yarn 为资源调度器，在云原生大数据平台中，通常会选择以 yarn + Kubernetes 来实现资源调度，Kubernetes 相比 Yarn 来说具有更加灵活和多样的调度策略，后面我们会详细讲到

好了，上面内容中，简单回顾了整个数据平台构建的背景，以及数据平台所能支撑的能力有哪些，因为本文更多的数据平台到云原生转型问题，所以，很多功能就不在展开讲解了。

基于以上，可以发现其实这些能力已经能满足绝大部份的需求场景了，是的，平台的功能上面其实是趋于完善的，但是平台的底座来讲，其实无法长期来支撑平台的良好运转，当稳定运行一年时间之后，就会发现基于 Hadoop 生态为底座的平台会暴露出一些问题

基于 Hadoop 生态构建面临的不足

picture.image

数据量持续增长，存储成本不断上升

随着企业持续发展，同时大数据所带来的价值也更加的明显，那么就会有更多的渠道数据进来，比如日志分析、用户行为分析、埋点数据，同时随着机器学习和 AI 技术的演进，往往需要持续几年的数据重新清洗然后通过机器学习进行训练，那么就需要持续不断的进行机器扩容，并且对于磁盘存储的介质选型也要求 HDD+SSD 这种高性能的存储，那么数据量的增长加上数据本身多副本机制，所带来的成本是非常高的

存算一体，存储扩容计算也要扩容

整个 Hadoop 生态体系的发展，从初期设计受限于网卡带宽和磁盘吞吐大小，所以整个技术栈都是以存算一体架构来设计的，那么在我们扩容存储节点时，对应的机器配置要和现有集群的 Data 节点配置一致，比如现有大数据集群节点是 32C128G10T 配置，那么新扩容的节点也要求为 32C128G10T 配置，在这时候存储量支撑下去了，但是计算资源却很浪费。

资源扩容达到阈值，出现资源浪费

我们知道，大数据任务区分为离线计算和流计算，离线计算往往在夜间进行跑批任务，那么这时候如果因为离线资源不足而持续扩容的话，那么白天的时候，这部分资源就会出现明显低峰低谷，整个计算资源浪费的非常明显。同时，我们在已有自建大数据集群中，往往很难做到自动的弹性伸缩。

大数据 &AI 高算力场景下，调度能力跟不上

随着大数据计算引擎的持续发展，比如 Spark、Flink 都支持了机器学习场景下的训练学习能力，但是对于 Hadoop 生态中 Yarn 的组件来说，整个资源管控方面也暴露出来了能力不足，从资源隔离、调度算法支持、弹性能力、成本和性能方面都无法支持更多的计算场景的需求，有问题就会有解决方案，很多早期做的比较好的企业发现之后，会考虑自研新一代的大数据资源调度系统，比如 Volcan、koordinator 等等新一代引擎开始诞生并在近些年随着云原生技术的发展而慢慢流行起来

组件升级困难，组件之间兼容性较差

作为相对早期大数据从业者，这些年也经历了无数次的版本升级，有些是为了新特性而升级，而有些是有了补丁而被迫升级，当每次升级之后，多多少少都会遇到一些新的兼容性问题，大概的计算了一下，一个完整的大数据集群差不多会用到 13 个组件，每个组件按照分布式架构来讲，至少会有 2 个服务（Master、Agent），比如 HDFS 来说就有 5 个服务进程：NameNode、DataNode、HttpFS、JournalNode、ZKFailoverController。

从而导致大数据集群升级和运维越来越困难，大家基本上来说能不动则不动，因为上层跑到任务量有数千个，每天数据增量 TB 级别的上升，稍微出点就出影响全局的稳定性。

基于云原生构建数据平台架构趋势

基于以上种种的问题，大数据团队都在探索一种新的能够替代 Hadoop 生态的解决方案，这时候以 Kubernetes 为代表的云原生技术在大数据场景下也慢慢的逐渐成熟，主流的大数据计算引擎也开始适配 Kubernetes 的调度机制，开始支持基于 Kubernetes 来跑计算作业，而在云原生领域内也诞生了更加强大的资源调度框架，比如上面提到的 Volcan 和 koordinator 作为国内两家大厂开源的云原生调度引擎开始普及开来。

而在存储层，大多数会选择对象存储作为大数据存储的介质，一方面是整个存储成本的急剧下降，另一方面则是不需要担心存储空间扩缩容的问题，可以做到按需灵活使用。

综合来看，大数据平台往云原生方向转型将是一个必然趋势，但是如何做到业务无感知的迁移和转型是大数据技术团队需要重点关注的核心之一，下面从我个人经验来谈一下底层迁移的几个点.

小部分业务进行尝试，迈出一小步

云原生技术的复杂度不比大数据技术低，会涉及到 Kubernetes 生态相关组件的学习和了解，这时候大数据团队需要一个学习成长的过程，不太适合采用激进的方式来进行统一转型，一般会先将一小部分业务数据调度到新的云原生集群中，逐步稳定之后在切一小部分业务过去。

这时候，会遇到很多技术性的问题需要解决，比如资源利用不合理、任务长时间夯住、网络带宽利用率比较大等等一系列问题，这些都是迁移转型过程中所必然要经历的。

资源层面混部，减少一部分成本

上面说到，资源是存在浪费的，那么为了短期内能够看到一些降本的效果，我们可以结合容器技术的弹性来作为大数据集群的补充资源，通过 Yarn on K8s 的方式来将计算作业无感的迁移到容器环境中运行。

甚至说，对于资源空闲比较大的企业来说，通过节点弹性伸缩+离在线混部方案可以最大化的减少资源浪费，提升资源的利用率。

基本上，看到这些成本下降的成效之后，就会给了团队和企业一定的信心，这些才能用更多的时间来做后面一系列的事情，比如统一计算引擎、数据湖架构推进、数仓一体技术落地等等，这些都是需要长期投入，短期比较难以看到好的效果的，所以需要一些短期能让公司看到明显效果的技术方案，才能进一步落地。

存算分离架构，计算轻量化、存储低成本

存储如果采用对象存储，一方面没有副本数的问题，另一方面整个数据成本会有 7-10 倍的下降，然后结合容器技术轻量化的架构设计，整个计算资源是一种无状态、轻量化的设计，就可以达到一种存算分离的架构设计，这时候就不需要担心扩容和缩容的问题，在云原生技术架构下，本身计算的弹性就是很灵活的，借助云原生调度引擎我们可以更大程度的充分利用 CPU 和内存的资源。

云原生数据平台面临的挑战问题

上面比较简单的提到了大数据云原生转型的几个核心设计点，概括起来就是云原生调度、资源混部利用、存算分离架构，但是在实施的过程中，难免会遇到很多的问题，技术层面的具体问题处理还好解决，对于成本效能和性能指标和技术栈选型问题这些我们需要长时间的进行压测和评估才能得到相对完整的结果，那么这些也是整个云原生数据平台转型过程中所面临的挑战性问题

成本效能和性能指标的对弈

存储性能虽然得到了大幅度的下降，极大的减轻了企业数据存储的成本压力，但是对于计算性能上将带来比较大的影响，我们知道计算和存储分离之后，有两个关键的性能瓶颈点，第一：网络吞吐，虽然现在网卡都是万兆级别的，但是对于大数据量的计算来讲，也是很容易达到瓶颈，第二：对象存储作为 K/V 的存储类型，在进行大数据量查询计算过程中，整个数据目录的 List、Rename 等会有严重的性能瓶颈。

在一些云厂商中都有推出基于对象存储大数据场景下的加速缓存能力，比如阿里的 jindofs、腾讯的 GooseFS、字节跳动 CloudFS、百度的 RapidFS、金山云的 KS3-HDFS 等等国内的云厂商都针对大数据和 AI 大模型的场景来解决数据加速计算和数据缓存的能力，但是整个存算分离的效果目前相对存算一体还是有一些 GAP。

同时，对应的开源社区也有对应的方案，比如 JuiceFS、Alluxio 都可以用于做存算分离架构下的提供数据加速缓存层，后面所挂载的都是对象存储系统。

Alluxio 的定位是在现有的存储系统之上提供缓存加速层，在实际项目中存储系统大多是对象存储系统。JuiceFS 的定位是为云环境设计的分布式文件系统，可以通过缓存机制加速数据访问。

JuiceFS 用对象存储做数据持久层，对象存储可以看做是 JuiceFS 的一个内部组件，打比方说对象存储好像一块容量无限大的硬盘，JuiceFS 对这块「硬盘」进行格式化，JuiceFS 的元数据服务就是分区表，结合在一起形成完整的「文件系统」概念。

对于大部分的离线计算场景下，性能指标要求是没有那么高的，延迟基本都是在可以承受的范围之内，只不过我们要单独的维护一套类似 Alluxio 和 JuiceFS 的系统，通过中间层的能力来加速数据计算。

技术栈的选型与业务的适配

一个合适的技术栈选择不仅仅关系到业务未来发展是否满足，同时也考验技术本身的演进方向，我们所选择的技术演进方向是否是符合我们架构设计规划的这很重要，比如要逐步替换掉 Hadoop 生态之后，存储层选择哪些组件，计算层 OLAP 选择哪些组件、资源调度框架怎么来选择，以及，是否要整体上云还是采用混合云架构还是自建模式等等，这些都是在架构设计中要规划清楚的。

InfoQ文章链接地址：https://xie.infoq.cn/article/fd13ab8125455e888ad9fefa4