1.4　数据中台建设方法论总纲

如前所述，数据中台强调的是数据仓库和大数据平台的建设方式。实际上，不能简单地将数据中台当成一个技术问题。建设数据中台必须要有技术和方法论。就像云计算一样，虚拟化是云计算的核心技术，但是如果要将公司上云、IT系统云原生化，还需要一整套以技术为基础的方法论来引导。举例来说，如何理解云原生中的重要概念“微服务”？传统的软件开发是把所有功能放到一个大型软件中，而微服务的概念是解耦，即把相对集中的功能作为一个微服务来开发。微服务的好处是可以单独测试和部署，微服务间通过API进行通信。微服务最好的载体是容器，容器是一项轻量级的虚拟化技术，不仅产生和消亡的代价很低，而且具有提供资源隔离等便于发布和管理的特性。微服务+容器加速了软件的开发、测试、生产和发布流程。但仅有这两项技术还不够，还要有DevOps来实现自动发布和稳定高效的系统运维，以轻松部署微服务和容器应用。同时，需要一个CI/CD架构来持续集成和持续发布，把代码提交到代码仓库后，自动触发微服务构建、容器构建及打包过程，然后发布到半生产系统进行集成测试，最后进入生产系统进行部署。这就是一整套的技术和方法论。

同理，打造数据中台也必须有一整套的技术和方法论的指导。我们先在这里简单介绍一下，第6章会更加详细地阐述。

（1）业务驱动，快速落地

所谓业务驱动，就是在建设数据中台的时候，一定要从企业的业务痛点、开发新业务的需要或者管理的需要出发，一步一步来，而不能期望一蹴而就。这是因为，数据中台的建设应该是先从0到0.1，要很快见效，不断迭代，分阶段地逐渐体现出数据中台的价值。如果能够快速解决各部门的业务痛点和需求，各个部门才会积极响应数据中台的建设。而且从工程师的角度来看，这样开发的服务不仅部门内部可以使用，公司其他部门也能用到。在能力得到大家认可后，其他部门的工程师还会帮助调试这个项目，一举两得。当其他部门的工程师也开始这样发布服务时，就形成了良性循环。贯彻数字化运营的理念，能够不断从数据中提取新的价值，这样才能充分调动各个部门使用数据中台的积极性。

（2）顶层架构设计及数据规范

在确定有业务痛点，需要相应的数据能力来解决问题的时候，首先必须梳理顶层的组织架构和业务架构，并确定全局的数据架构和数据规范。值得注意的是，这里并不需要进行全局的业务梳理、数据梳理，因为我们在确定顶层架构和数据规范之后，可以根据具体的业务需求来梳理专门的业务流程和相关数据。只要有合适的顶层架构和数据规范并贯彻执行，系统中就不会出现数据孤岛。

（3）平台管理，由工具来指导数据能力的抽象和共享

如果实现数据能力的抽象和共享需要建立大量规则，需要复杂的培训，还要小心使用，那么这个数据中台注定是很难长期演进的。数据中台的建设应该以提供一系列方便好用的工具和流程为目的，让工具引导人来完成工作，而不是靠人手动操作。例如，添加一个新的数据源，对现有数据源进行修改的时候，相应的工具应该能自动完成这个数据源相关的管理工作（元数据采集、监控、通知），而不是让使用人员手动添加很多相关的配置。

（4）明确的责权利制定，并由工具来配合责权利的管理

任何一个系统的有效执行都需要参与人员的高效管理，高效的管理需要明确的责权利定义。特别是数据中台这种几乎涉及公司所有部门的体系，参与各方的责权利必须明确。一个常见的问题是，数据中台和大数据平台团队的价值无法明确体现，却要承担整个系统的高效、稳定、正确运行，而这个系统很多时候要运行来自业务部门的应用和服务。如果不将各个部门的责权利定义清楚，最后就会陷入相互推诿的境地。这是一个管理问题，但是也需要相应工具的支撑。

（5）必须是一个安全、高效、稳定、可扩展的系统

实际上，中台并不是一个新概念，只不过以前受制于IT技术，企业无法建立安全、高效、稳定、可扩展的平台。如今，借助云原生、容器等技术，构建这样的系统已经变得非常可行。有了这些技术，再加上快速稳定的DevOps和CI/CD流程，整个应用开发和部署变得更快捷，从开发到上线的流程变得更加流畅，因此数据中台建设最好的开发基础就是云原生架构。而且，容器天然具有资源和数据的隔离性，可以很好地保证系统的安全性。

在云原生架构下做数据服务有天生的好处，就是以微服务和容器化的方式发布数据服务，能够实现非常快速的部署和迭代。另外，数据中台能够实现数据服务的弹性扩展。在容器编排如Kubernetes等架构下，一个操作就可以把一个数据服务容器实例变成多个实例，从而充分满足系统的可扩展性。因此，数据中台的建设一定要基于云原生和容器。