中台建设之路-中台建设怎么作？建设中台须要具有什么？

开宗明义：要建设中台，须要考虑组织、支撑技术、方法论这三个方面，每每还须要咨询服务。
中台做为一种有业务属性的共性能力，首先就须要一个懂业务、承担业务职责的专职的组织机构来负责。要不要建中台，首先要看领导有没有魄力去整合创建一个中台组织。由于原来的平台部一般不懂业务，懂业务的人各自分散在前台业务部门，因此创建中台组织每每涉及人员、组织架构和部门职责的调整。正由于如此，中台的建设每每须要做为一把手工程才能成功。
中台组织关键要懂业务和承担业务职责。举个例子，一个大数据平台的建设运维团队不是一个中台组织。一个团队若是作了很是完善的中台产品（如开发了数据中台所须要的指标管理系统、数据仓库开发系统、数据质量管理系统等等），但只是把产品提供给业务方使用，这个团队仍然不能说是中台组织。只有当这个团队承担起指标体系的建设和管理、数据仓库的设计和实施、数据质量的保障等工做时，才能够说是中台组织。而要作到这一点，这个组织确定是比较了解业务的，它的目标和考核也必定与业务有相关性（确定不仅是平台稳定性这样的非业务指标）。
中台组织的层次与中台的层次最好是对应的，BU级的中台组织最好直接向BU老大或分管的CXO汇报，企业的中台组织最好直接向CEO或分管的CXO汇报。
这里特别说明一点的是若是不建设在线业务中台，而只是采用微服务、云原生等技术的话，能够不涉及组织方面的大规模变更，就在原来的研发部实现转型。一般来讲也能够实现必定的系统可用率、弹性和研发效率方面的提高。
中台建设的支撑技术
建设中台通常须要一套支撑技术。
1、在线业务中台支撑技术
建设在线业务中台通常须要云原生、DevOps、微服务技术体系的支撑，这是由于：
微服务技术：中台是一个独立的组织负责并为多个前台业务服务，所以须要一个标准的服务接口、成熟的服务治理能力和高效的敏捷研发技术。在当前的技术环境下，采用地球人都熟悉的REST风格的同步API、消息队列异步通讯做为标准的服务接口技术，采用服务框架（如Spring Cloud等）、API网关、APM等做为标准的服务治理和敏捷研发技术是最合适的选择。再也不建议采用传统的基于ESB的服务化（SOA）技术，由于ESB产品过多的介入到业务逻辑中，致使前台业务的变动每每须要中台团队的配合才能完成，这样就失去了建设好中台，支撑前台高效创新的意义。此外，中心化的ESB软件和复杂的基于XML的WS-xxx等协议也影响到系统的可用性和性能。能够参见Martin Fowler在P of EAA中的评价，Web Services是应用集成而非应用开发的技术。
DevOps技术：若是不经过DevOps使得各微服务都能自助式的部署更新，则微服务带来的敏捷性就无从发挥，反而由于服务数量的增长致使研发效率的降低，所以持续集成、持续发布等DevOps技术通常是实现微服务的必备。
云原生技术：微服务和DevOps要求底层的基础设施是灵活可编程的，不然根据Amdahl定律，只要有一个必须的环节是低效的，总体的效能也提不上去。
须要强调的是中台要敏捷，这一方面是由于中台具有业务属性，且支撑了很是丰富的前台业务，前台业务的敏捷性要求有一部分就会传导的中台层；另外一方面是中台的重要性使得其须要持续不断的优化，即使对外提供的服务不变，内部实现也会常常变。
分布式事务技术：实施微服务拆分后，复杂的业务流程再也不能经过数据库的事务机制来实现ACID特性，为此还须要服务层面的分布式事务处理技术。典型的分布式事务处理模型包括TCC、Saga、FMT等。其中TCC和Saga须要各服务实现定制化回滚逻辑，侵入性比较严重，用起来门槛比较高。FMT模式对于Java能够作到加一行注解（如@GlobalTransaction）便可实现分布式事务，剩下的由框架自动处理，用起来方便的多。Saga模式是Princeton的两位研究者在1987年提出的，灵活性和并发度最好，但须要经过语义锁等精细的设计才能发挥出来。
因而可知，在线业务中台的技术支撑体系是至关复杂的，所幸的是Netflix、Google等世界领先的互联网企业因为自身业务须要打造了不少实用的技术模块，开源社区也贡献了很多力量，CNCF组织又作了很好的聚集和标准化。经过将相关技术加以整合，已经有了不错的产品可用，如网易轻舟微服务就是一套产品化设计良好、功能丰富的在线业务中台支撑技术产品。
通常而言，前台也会和在线业务中台同样采用云原生等一样的技术体系，这是由于前台更须要敏捷性。在完善的中台支撑之下，前台会比较轻，还能够考虑采用FaaS Serverless技术，不过目前这方面的实践还很少（特别在中国），相关的支撑技术也不是很成熟。
2、数据中台支撑技术
建设数据中台通常须要一整套以下典型的支撑技术：
指标管理系统：指标是中台与前台之间最关键的接口，也是建设数据中台的牛鼻子，由于它是最核心的业务语言，且指标不一致、数据常出错是建设数据中台最多见的出发点。若是指标体系没有统一的方法论，进行统一建设，那么就很难说是数据中台。指标管理系统通常要实现一套一致的方法论（如原子 / 派生 / 复合指标、维度、修饰词等），作好指标的业务和技术口径管理，还须要支持指标的审批管理。数据中台的指标没法交给各前台业务自助式的建设。
数据服务系统：相似于在线业务中台须要经过API网关提供标准化的服务，数据中台也须要一个标准化的服务方式，一般称为数据服务系统，也能够说是数据网关或数据门户。相似于别的网关类产品，数据服务系统须要提供鉴权、日志审计、流控、协议转换（如SQL Dialect之间的转换）等功能，也应该发展多引擎融合查询、逻辑模型等扩展功能以提升服务接口的稳定性和实现的灵活性。
元数据管理系统：元数据管理是整个数据中台的基础和中心，全部的其余系统都依赖元数据管理。元数据管理首先要作好的固然是数据模式或目录（catalog）的管理，至少要知道中台里都有什么数据。对复杂的数据中台来讲，数据血缘也很重要。没有血缘信息，不知道数据间的依赖关系，数据质量确定管很差，由于不知道一个数据的质量问题怎么来，又进而会影响什么。一样的若是没有血缘，数据资产也确定管很差，由于不知道什么数据有价值什么没价值，这就像若是你不知道一个函数被谁调用，你就不知道它是否是死代码同样。元数据管理系统每每也须要提供一个基础的访问界面，一般称之为数据地图。
数据仓库开发与管理系统：除了指标管理，数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。通常来说数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法，这是由于Inmon强调顶层设计，而Kimball强调至下而上。若是要建设数据中台，确定是由于前台业务复杂多变，这时强调顶层设计会致使中台建设缓慢、僵化。由于中台虽然应该是由组织高层决策，但目的倒是为了支持前台业务，而不是为了控制。支持而不是控制，这一点毫不能本末倒置。
数据质量管理系统：全部复杂的系统都须要专业的质量管理，在线业务系统有一系列的弹力设计和APM等监控运维工具，数据中台也须要专业的质量管理。数据质量管理系统一般设计为支持丰富的稽核 / 校验 / 比对规则，监控数据是否准确、实时、一致，还要作到及时的报警，分析影响面，提供快速修复的手段等。但这些手段只能发现和补救问题，不能预防问题，要预防问题，还要经过测试工具减小代码bug、经过资源弹性应对性能波动、经过优先级调度优先知足重要业务需求等。相对来讲，当前数据中台领域的质量管理没有在线业务领域的成熟，如在线业务领域的测试手段远比数据领域的精细，在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法（优先级调度能够说是实现了部分的服务降级功能），随着数据中台愈来愈普遍和重要，这些技术应该也须要持续发展，但技术上的挑战不小。
数据安全管理系统：数据中台由于聚集了组织全部有价值的数据资产，所以良好的安全管理是必须的。细粒度的权限和审计是基础，通常的还须要隐私 / 敏感数据的脱敏处理、数据加密（特别是将数据托管在第三方平台之上时）、数据泄漏防御（比方说一种常见的方法是限制将数据下载到本地的数据量）等技术。发展到高级阶段甚至可能还须要联邦学习、数据沙盒等技术。
数据资产管理系统：在数据质量和安全单列的状况下，数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工做。
同时，数据中台还须要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎，还每每须要一套敏捷BI系统：
大数据计算引擎：数据中台要管理的数据规模和复杂度每每都很高（不然搞中台属于为赋新词强说愁），因此传统的数据库和数据仓库基本上支撑不了。当前的技术环境下，基于Hadoop MapReduce或Spark几乎是惟二的选择，固然这也包括了这二者之上的Hive和Spark SQL。能用SQL就用SQL，易于维护，也易于数据血缘的收集。除此以外，流处理可能还须要Flink，交互式查询可能要引入Impala或GreenPlum。
数据集成 / 同步 / 交换引擎：一方面数据中台须要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近，同步更强调实时性。另外一方面，数据中台每每由多种数据计算引擎构成，就须要同步或交换引擎实现不一样引擎见的数据交换。
敏捷BI系统：建设数据中台一般最重要的目的是为了支持业务运营和决策，为此须要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段，可以尽快尽早的发挥数据中台的价值。
此外，对于互联网业务，统一的埋点引擎每每也是数据中台所须要的。若是埋点的逻辑都不统一的话，建数据中台的时候会发现数据的源头就是乱的，后续也都无法作。其余行业业务，数据采集也属于基础工做，也是要先作好的。
因而可知，建设数据中台须要的技术支撑体系也是至关的庞大，复杂。所幸的是这十年来Google等领先的企业、Hadoop / Spark等开源社区以及大量的厂商大体联合探索出了一条可行的路径，方法论和技术路线都比较统一了。以此为基础，就能够提供较成熟的数据中台技术支撑产品，如网易杭研研发的“网易猛犸V6.0 + 网易有数”就是一套较完整的数据中台产品。