数仓dw怎么建_数据治理、中台、微服务，这三者怎么扯上关系的？

文|谈数据

前段时间，我的一个小伙伴跳槽到了某大型国有企业，刚到公司不久，老板给交给他一个重要项目——公司的数据中台规划。

老板交代：“要搞一个数据中台架构，涵盖数据资产管理、数据治理、数据分析等，同时这个数据中台，要体现去中心化，甚至无中心化的理念”。

我这哥们儿有过多年的数仓架构经验，并参考了业界主流的数据中台架构，很快就“照猫画虎”的搞了一个数据中台架构图出来。

当他拿走自己的“得意之作”，找老板汇报的时候，没想到老板只看了一眼，就劈头盖脸骂了他一顿，主要原因就是没有体现“去中心化”的思想。

小伙伴儿向我抱怨：“数据中台可不就得建一个集中管理数据资产的平台，实现数据资源的汇集、治理、编目、标签化，然后再根据业务部门的用户需求形成数据服务，提供给其他系统调用吗？数据不集中管理，怎么给数据资产打标签，怎么沉淀数据服务？

小伙伴儿噼里啪啦，越说越委屈、越说越气愤……

我赶紧打断了他：“你先别急，你把需求再跟领导沟通沟通，比如公司上这个数据中台也解决什么问题？为什么要去中心化？另外就是，去中心化和中台也并不矛盾，业务中台的最佳实践就是去中心化的微服务架构，难不成你们老板让你搞的是业务中台？”。

……

后来，这个事情也就这样过去了。但这件事引发了我的一些思考：

• 中台架构就要去中心化吗？
• 中台和微服务到底什么关系？
• 微服务的情况下，数据治理该如何搞？

01

什么是微服务，

微服务与中台的关系？

先说服务

这个定义也不知道是哪位兄台更新的，这专业的语言、晦涩的词语，让我这有IT技术基础的看着都一脸懵逼。

本质上，微服务是就一种用于构建应用的技术架构，他是IT技术发展的产物。微服务架构有别于更为传统的单体架构、垂直架构，它的特点是每个核心的功能，都可以作为一项服务，每个服务都有自己的运行环境、数据库，可以单独部署和运行，这意味着各项服务在工作(和出现故障)时不会相互影响，从而将单点故障产生的影响降到最低。

再说中台

中台是一个很泛的概念，包含了数据中台、业务中台、技术中台、算法中台，还有一些垂直应用中台，比如：财务中台、营销中台、制造中台等，甚至还有组织中台、资源中台的说法。

不论是哪种中台，它的核心思想都是企业能力和资源的共享和复用，实现这些能力和资源的集约化管理，并能够对不断变化的业务需求进行灵活，快速响应。

简单来讲，中台是一种企业能力共享、资源复用的方法论。而微服务是一种可独立部署、独立运行、独立维护的业务应用单元，它是一种技术架构模式。从这个层面讲，中台与微服务之间没有半毛钱关系。

但，中台与微服务真的没有关系吗？往下看。

02

微服务下，

数据治理环境变得复杂？

基于微服务技术体系构建业务中台，已经成了当前很多公司IT治理的首选解决方案。基于微服务架构的业务中台，自然有他的优势，诸如我们上文中提到的独立部署和运行、服务自治、敏捷试错等等，但是微服务架构下，拆分的不仅是应用，还有数据库。

微服务如何拆分，数据如何分区，如何保证拆分后数据的一致性，是考验微服务架构师经验和水平的试金石。一旦拆分逻辑设计不周密，其将来的数据环境将变的复杂！

那微服务环境下，数据治理到底治什么，在哪治，怎么治？

what，治什么？即：哪些数据需要治理？

where，在哪治？即：在单个的微服务中实施数据治理，还是集中到一个数据平台(数据中台)进行治理？

how，怎么治？即：微服务下的数据治理和传统架构下的数据治理有哪些不一样？

我们带着这三个问题，继续往下看~~

03

微服务下的数据治理，

治什么，在哪治，怎么治？

有人认为微服务架构下，数据治理会遇到很大的挑战，但是在我看来，就是数据源多了些，不论从体系上、方法上、还是从技术上、工具上，微服务就是微服务，数据治理还是数据治理。

1、治什么

微服务下，数据治理的内容也无外乎也是元数据、主数据、指标数据、业务数据。当然，也有处理非结构化数据、半结构化数据、实时数据微服务。数据治理的内容/对象没有变。

2、在哪治

微服务下，数据治理在哪治的问题，要分为两个层面考虑。

一个层面，是关于主数据或基础数据的治理，其重点还是应该放在数据源头治理。比如：“用户中心”微服务管理了用户主数据，“商品中心”微服务管理了商品主数据，那对于用户和商品这两个主数据就应该从“用户中心”、“商品中心”这两个微服务中入手，控制好数据的入口。

另一个层面，是关于分析数据、业务数据、日志数据的治理。对于分析数据，以及一些实时性要求高的业务数据、日志数据的质量，应放在数据中台或数据湖中治理。

3、怎么治

数据治理体系和方法上与传统架构下的数据治理没有任何区别，我们主要从技术层面来看。从技术方面来讲，微服务下的数据治理，一般有两种选择：第一种是在线处理数据，第二种是离线处理数据。

在线处理数据的方案就是按照微服务的标准接口来进行，后端服务或系统需要哪个数据就去调用某个微服务提供的接口来获取，然后将返回的数据进行处理后将数据返回。

离线处理数据方案，就是将业务数据准实时的同步到另外一个数据库中，在同步的过程中进行数据整合处理，以满足业务方对数据的需求。

值得一提的是，微服务环境下更需要数据治理，尤其是元数据管理。元数据管理的作用不仅是对微服务中数据的治理，更是对微服务全生命周期的治理。如下图：

写在最后的话

微服务架构最开始是在互联网行业流行起来的，随着互联网向传统行业的渗透(或者说传统行业朝着互联网方向转型)，微服务架构也逐渐出现在了企业应用开发的选项当中。

尽管在核心理念上，微服务和SOA没有太大差别，都是强调模块化、服务化，但随着敏捷开发、持续交付、DevOps理论的不断发展和实践，以及基于Docker等轻量级容器的应用和服务的逐步成熟，微服务已经成为了企业软件架构的未来演进方向。

可以预见，在未来的很长一段时间内微服务架构与传统软件并存。

对于数据治理来讲，传统的数据管理方式可能会受到挑战，但“治理”这两个本身就带着强烈的改革基因，改变一些传统思维，固有习惯，拥抱新技术，面对新挑战，与时俱进，才能达到“让业务更有序、让管理更有效！”的治理目标。