数据中台，难吗？

数据中台经常使用分布式计算框架和存储框架以保证大数据分析工作的高性能，但在传统方式下，这些分布式框架面临诸多挑战。与此同时，云原生架构改变了软件的开发模式，加速了软件的开发、迭代、测试和部署，节省了软件开发人员和 IT 运维人员的时间和精力，让他们得以专注于解决业务层面的问题。同样，采用云原生架构的应用能力基础平台对于数据中台的建设也有着重大的意义。

一、传统方式下搭建数据中台的难点

前文中我们明确了数据中台的定义，并给出了一些数据中台的技术要求。这里我们回顾一下这些技术要求。

● 易用：提供大数据应用开发的低代码平台。

● 快速：数据应用的开发及新的大数据技术可以快速落地、 快速迭代。

● 安全：数据安全是第一考虑。

● 可衡量：所有工具的使用都有统计数据。

● 可审计：所有工具和数据的使用情况都可审计。

● 协作：所有工具都有协同工作的属性。

● 健壮：完善的多租户管理，确保资源隔离、数据隔离。

● 自助：业务人员经简单培训，可自助完成绝大部分功能。

● 性能：数据分析及数据服务的性能有保证。

在传统方式下建设数据中台，想要达到以上技术要求有不少难点。我们可以从以下几个方面来分析这个问题。

1）单体架构的应用开发模式很难做到数据应用的快速落地、 快速迭代，也很难保证数据应用能力的快速复用。

在前面介绍微服务架构的时候已经提到了这个问题，把所有功能模块都放到一个应用中的开发模式会使系统越来越复杂，升级迭代的成本越来越高。把一个单体应用的某些能力复用到其他系统也很困难，因为要想从一个庞大而复杂的应用中分离出某些 功能模块并进行重构几乎是不可能的。

2）新的大数据技术的快速落地是非常困难的。

传统方式下，我们部署一个 Hadoop 生态圈的新组件，对其进行 POC 验证（证明该组件能够完成我们要做的工作），经常碰到的问题是新组件与安装节点上的某些软件发生冲突，需要调整原来安装好的软件才能解决这些冲突。一般这样一个 POC 工作需要花上几天时间，而部署到生产系统中则是一个更费时的过

程，往往需要几周时间。

3）多租户的环境导致数据安全及性能问题。

传统方式下，各业务部门开发的应用都运行在一个统一的平台上，经常会出现这样一个问题：某一个部门开发的应用占据过多的资源，导致同一台服务器上的其他应用得不到应有的资源而性能下降，从而影响了其他部门的业务。产生这些问题的根本原因是没有对这些应用进行资源隔离。另一个问题是没有对这些应用的内存空间和本地数据存储空间进行数据隔离，因而存在潜在的安全漏洞，如果有应用处理的是敏感数据，则可能会造成敏感数据泄露。

4）业务人员很难自助完成新的数据分析及探索工作。

传统方式下，业务人员基本都需要大数据工程师团队为他们建设好数据分析和探索工具，他们经过培训后使用这些工具。如果业务人员想要试用数据平台上没有的新数据分析工具，那他们就要向大数据工程师团队申请硬件资源，提出安装要求。运气好的话，等上几天就可以试用这个新工具；运气不好的话，可能要等上几个月。因此，在传统方式下，业务人员几乎不可能自助试用新的数据分析工具。

5）数据中台经常使用分布式计算框架和存储框架以保证大数据分析工作的高性能，但在传统方式下，这些分布式框架面临如下挑战。

第一，运维工作困难，运维人员仍需要使用 Ansible 或Puppet 这些工具，手动进行节点间的配置同步、服务暂停、服务重启等日常维护工作。

第二，升级风险很大，整个升级工作涉及的工作复杂，持续的时间很长，经常会影响业务的正常运行。

第三，不同分布式系统的日志信息分散、故障排除困难、故障恢复代价很高，经常要手动地重新搭建故障节点或模块，重新同步配置文件和数据。

综上所述，在传统的 IT 架构下建设数据中台是非常困难的。如何解决这些难点呢？我们给出的答案是云原生架构。云原生架构不仅可以解决传统方式下应用软件开发、测试和部署的难题，还可以解决传统方式下建设数据中台的难点。

二、云原生架构对于数据中台建设的 5 大意义

云原生架构改变了软件的开发模式，加速了软件的开发、迭代、测试和部署，节省了软件开发人员和 IT 运维人员的时间和精力，让他们得以专注于解决业务层面的问题。同样，采用云原生架构的应用能力基础平台对于数据中台的建设也有着重大的意义。

1. 数据中台的快速迭代需要云原生架构

数据中台的核心目的是快速洞察市场变化并响应变化。要快速响应市场的变化，就需要能够快速地开发、测试、迭代和上线大数据应用。云原生架构下的软件开发模式正好能满足这样的需求。在云原生架构下构建数据中台，要以容器化的方式来部署大数据的基础组件，如Hadoop、Kafka、Spark 等。除了大数据基础组件以外，其他大数据应用也应该在微服务架构下进行开发，并以容器的方式在数据中台中运行。DevOps 和 CI/CD 流程也可以使开发团队快速、频繁地迭代和更新大数据应用。

2. 数据中台的数据共享和复用需要云原生架构

我们知道，数据中台的核心是要实现数据的共享、抽象和复用。而数据的共享和复用一般都是通过把公共数据能力发布成数据服务来实现的。数据服务应该以微服务的架构来开发，每个单独的服务功能都可以是一个微服务，而以容器方式发布数据服务可以实现数据服务的高可用。

此外，我们可以轻松地增加容器的数目来进行横向扩展，支撑日益增长的数据服务访问。云原生架构数据和资源的隔离的另一个优势是，在这一架构下，各个业务部门可以放心地开发自己的数据应用，将敏感数据交由容器隔离来进行保护，同时资源的隔离保证其他业务部门的应用不会影响自己部门的应用。这样，业务部门就更有意愿在数据中台中进行数据应用开发，并把数据能力共享出来，供其他部门复用。

3. 云原生架构可以实现数据中台组件的标准化配置和管理

数据中台组件的发布不只是发布一个容器应用，还涉及其他的方面。一个新组件发布到数据中台中，它一定要是能被监控的。一般来说，数据中台有一个统一的监控体系，例如用Prometheus 和 Grafana 框架实现的监控系统。一个新组件要能够被这样的监控系统监控，首先它要内置一个类似 Java 程序里JMX 工具的 exporter 程序，通过一个端口持续对外发布监控指标，其次它需要配置一个 Grafana 监控面板，这样我们就能够在Grafana 的界面上使用这个监控面板来浏览该应用的监控指标。此外，新组件还应该有出错报警配置，这样当它的监控指标达到某个阈值时，我们会收到报警邮件或短信。除了监控之外，这个新组件所产生的日志还应该接入数据中台统一的日志系统，这样当它产生故障的时候，应用开发人员很容易诊断，这也是前面提到的 DevOps 流程必须提供的功能。

总结一下，要将一个新组件发布到数据中台，需要将它通过自动化的方式接入其应用基础能力平台的监控、报警和日志系统当中。在容器方式下发布一个新组件，我们可以很容易地将这些监控、报警、日志系统等配置信息标准化，以配置文件的方式随着容器一起提交给发布系统，发布系统根据这些配置文件进行监控、报警、日志系统的对接。

4. 云原生架构可以轻松集成新的开发工具

为了快速应对市场的变化，我们经常需要在数据中台上尝试和使用新的功能组件，比如H2O、KNIME、SimpleCV 等机器学习框架。运行这些新组件是应用基础能力平台的任务，而云原生架构可以帮助我们轻松实现这个目标。目前 GitHub 上的主流开源软件基本都提供了容器化部署的支持，我们几乎不需要做太多额外工作就可以将这些软件发布到数据中台、接入已有系统当中，进而快速验证这些软件能否满足我们对业务的需求。

5. 云原生架构可以轻松实现分布式架构

数据中台的一些重要组件是以分布式架构运行的，比如Hadoop、Spark 和 Kafka 等 基 础 架构，Redis 和 Elasticsearch 等存储架构，以及 PMLS 和 TensorFlow 等分布式机器学习系统。 在云原生架构下，Kubernetes 和 Mesos 等工具为云原生应用提供了强有力的编排和调度能力，它们使在云平台上部署和运行分布式系统变得更快捷、方便和稳定。

例如计算框架 Spark，其原生的编排环境就是在 Mesos 上开发的。另外，容器化运行组件使计算和存储资源得到有效隔离，我们可以实现对不同类型的程序的支持，而不会发生某一类程序占据系统所有资源的情况。同时，云原生架构可以让我们轻松实现计算和存储资源的分离，从而提高资源的使用率，例如，我们可以用 Kubernetes 作为资源管理器来管理计算资源，使用分布式文件系统HDFS 来管理存储资源。对多云和混合云架构而言，首先要解决的是弹性伸缩和异构的问题，而云原生架构对弹性伸缩的敏捷支持以及标准化的容器应用可移植性，大大简化了多云和混合云的部署。

以上内容摘自《云原生数据中台：架构、方法论与实践》部分章节。