企业数据中台建设指南

数据中台介绍

什么是数据中台

2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心是避免数据重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。数据中台的建设目标可归结为“两化”：业务数据化和数据业务化，其建设思路可概括为“四化”：业务数据化、数据资产化、资产服务化和服务业务化。

数据中台通过数据技术，对海量数据进行采集、加工、存储，统一标准和口径，形成企业数据资产，进而服务于企业的各项业务。数据中台跟企业业务紧密相关，因此只能由企业自建，无法从外部购买得到。数据中台是企业数据的沉淀，不仅能降低重复建设，减少烟囱式协作的成本，同时也是企业差异化竞争优势所在。

大数据发展历史

纵观大数据发展历史，历经数据仓库、大数据平台，再到当前的数据中台，它们都是为了解决某个大数据发展阶段的问题而出现。

数据仓库

商业智能（BI，Business Intelligence）诞生在上世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这导致了数据仓库的出现。

传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。但是进入互联网时代后，传统数据仓库逐渐没落，一场由互联网巨头发起的技术革命催生了大数据时代的到来。

大数据平台

进入互联网时代，有两个最重要的变化。一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。所以，数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能，因此催生了以 Hadoop 为代表的大数据技术。

商用的大数据集群包含几十上百种组件，数据研发涉及流程非常多，技术门槛比较高。对于一个数据需求，常见的流程是首先把数据导入到大数据集群中，然后按照需求进行数据开发。开发完成以后进行数据验证比对，确认是否符合预期。接下来把数据发布上线，提交调度。最后是日常的任务运维，确保任务每日能够正常产出数据。如此繁杂的一个工作流程，如果没有一个高效的平台作为支撑，就跟写代码没有一个好用的 IDE，用文本编辑器写代码一样，别人完成十个需求，你可能连一个需求都完成不了，效率异常低下，根本无法大规模的应用。大数据平台的出现就是为了解决此问题，它能够提高数据研发的效率，降低数据研发的门槛。

大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台。其参考架构如下：

数据开发人员只需要通过可视化界面创建包含多个数据处理环节的任务工作流，提交给任务调度器，然后平台会自动定期按依赖顺序执行工作流里的各项任务，并且能够查看各个任务的执行状态。原始数据经过大数据平台加工后变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。为了能够在企业内部更好的共享数据，以及让数据服务于业务（而不是仅仅用来生成报表），带动业务创新，产生更大的价值，数据中台应运而生。

数据中台

过去企业的数据系统距离用户和业务比较远，这里的远主要包括三点：

1. 数据系统只是技术支撑而不能直接产生业务价值。做一个业务系统，比如，电商平台，可以直接带来收入。但是，传统的数据应用，比如数据仓库，是不能带来直接的价值的。
2. 当业务人员需要在报表里修改一些内容的时候，得到的响应慢，因为业务人员无法自己直接使用数据来产生洞察，需要去找数据团队。
3. 过去在数据方面的投资，大量花费在数据采集、处理和建模部分，而真正利用到业务领域的不多。

换个角度来看，就是业务开发团队对数据的利用有很大的需求，主要体现在，希望数据中台能够解决企业数据开发的效率问题，协作问题和能力问题。数据中台给了应用开发人员这样的希望，那就是他们不需要关注具体的取数逻辑，只需要关注客户需求，可以像搭乐高一样方便的组合各种数据中台的数据服务到自己的应用当中去，数据准确并且一致。

所以，如果用一句话来说数据中台的价值，那就是改变原来企业利用数据的形式。过去，数据的利用形式主要是商业智能，说直接一点就是做报表，做报表的目的就是让管理者知道现在的业务在发生什么，为什么会发生这些事情，接下来可能会发生什么，这一切都是提供给我们的管理者去看的，帮助管理者去做出一个业务决策。随着业务复杂度的提升，一个决策背后的因素是非常多的，一个现象需要多个维度的解读才能够体现业务全貌。于是，管理者需要的报表就越来越多，很多企业会有多个不同业务线的数据仓库，每个数据仓库里都有千张以上的报表，最后就陷入了报表的迷宫。当我们回头来看这个过程，我们发现，报表并不是我们所需要的，而数据本身也不是我们所需要的，我们所需要的是一个业务决策，一个业务行为。比如，当用户打开电商产品目录的时候，将他最有可能购买的产品展示在第一页，而原来的 OLTP、OLAP 分离的数据处理流程是做不到的，那么，在业务交易的过程中，也没有办法 从历史数据和全域数据的分析结果中获得行动的指引。

总而言之，市场对于数据中台的期待，是提供直接驱动业务流程的数据服务，而不仅是需要经过人去转化和解读的数据可视化报表，原来商业智能时代已经过去，市场和用户期待的是数据智能的时代。

数据中台建设指南

什么样的企业需要数据中台

数据中台的构建需要非常大的投入。一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另一方面，面对大量的数据需求，需要花费人力去开发数据模型。所以数据中台的建设，需要结合企业的现状，按需选择。

当企业面临以下困境时，可以考虑构建数据中台：

1. 企业内存在多种数据应用场景。数据中台本身并不直接产生业务价值，数据中台的本质是支撑快速地孵化数据应用。当企业有较多数据应用场景时，可以考虑构建一个数据中台来提供支撑。
2. 企业完成了信息化建设，存在较多的业务数据孤岛，需要整合各个业务系统的数据进行关联分析。比如电商初期，仓储、供应链、市场运营都是独立的数据仓库，进行数据分析时需要跨多个数据系统，为了消除这些数据孤岛，就需要构建一个数据中台。
3. 团队正在面临效率、质量和成本的苦恼，面对大量的数据开发需求，不知道如何提高效能，数据经常出问题而束手无策，老板还要求你控制数据成本。
4. 企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率。通过构建一个数据中台，同时结合可视化的 BI 数据产品，来辅助运营，这种情况往往出现在传统企业中。
5. 数据中台因为投入大，收益偏长线，所以更适合业务相对稳定的大公司，并不适合初创型的小公司。

数据中台建设方法论

早在 2016 年，阿里巴巴就提出了数据中台建设的核心方法论：OneData 和 OneService。

OneData

用一句话定义 OneData 的话，就是所有数据只加工一次。这个看似很普通的要求，却往往因为企业各部门之间烟囱式的数据开发而无法满足。由于跨部门之间沟通和协调的不便，企业的各个部门往往喜欢选择自己建设数仓，这就会导致数据重复加工，并且难以保证口径一致。数据中台就是要在企业内部构建一个公共数据层，消灭各部门内部的小数仓，实现数据的复用。

要想实现数据只加工一次，可以遵循以下原则:

• 划分主题域。主题域也称为数据域，在数仓规划中位于业务板块之下。试想一下，如果存在几万张表，同时有几十个数据开发维护这些表，那么如何来确保这些表的管理效率？可以将这几万张表划到不同的主题域中，比如在电商业务中，商品、交易、流量、用户、售后、配送、供应链都可以作为主题域。好的主题域划分，是相对稳定，且尽可能覆盖绝大多数的表。
• 定义命名规范。表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息。比如，对于仓储域下的一张入库明细表，可以命名为 dwd_wms_inbound_item_info_di，其中 dwd 表示分层为明细层，wms 表示主题域为仓储域，inbound 表示业务过程为入库，di 表示分区规则为每日增量。
• 确保指标一致。通过构建全局的指标字典，确保所有表中相同指标的口径是一致的。
• 复用数据模型。为了实现模型的复用，建议采用分层的设计方式，常见的分层包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层/数据集市层。
• 确保数据完善。尽可能覆盖所有的业务过程，每一层的数据也要尽可能完善，让数据使用者尽可能使用汇总后的数据。

OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneService

OneService，数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问。为什么数据一定要通过 API 接口的方式被访问，不通过 API 接口，直接提供数据表给用户又存在哪些问题呢?

• 当开发一个数据产品时，首先要把数据导出到不同的查询引擎上供应用使用，比如数据量小的使用 MySQL，数据量大的可能用到 HBase，需要多维分析的可能需要 Greenplum，实时性要求高的需要用到 Redis。对于不同的查询引擎，应用开发需要适配不同的访问接口，这会增加应用的使用成本。
• 当某个任务无法按时产出，发生异常时，想要了解这个表可能会影响到下游的哪些应用或者报表，但是却发现单纯依赖表与表的血缘无法触及应用，根本无法知道最后的这些表被哪些应用访问。与此同时，当你想下线一张表时，因为不知道谁访问了这张表，无法实施，最终造成了“上线容易，下线难”的窘境。

通过使用 API 接口方式，一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。

那如何来实现数据服务化呢？

• 屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有 MySQL、HBase、Greenplum、Redis、Elasticsearch 等。
• 数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。使用数据的每个应用都应该通过 accesskey 和 secretkey 实现身份认证和接口权限的管理。另外，访问日志可以方便在访问出现问题时，加快排查速度。
• 逻辑模型：从用户的视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型。什么是逻辑模型呢？熟悉数据库的同学应该知道，数据库中有一个视图的概念，视图本身并没有真实的数据，一个视图可以关联一张或者多张表，每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果。逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，支持相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。
• 性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。

OneService 体系的目标是提高数据的共享能力，让数据可以被用得好，用得爽。

数据中台支撑技术

工欲善其事，必先利其器，对于建设数据中台这样的大型复杂系统，如果没有一个功能强大的大数据平台，一切依赖手动执行的话，必将寸步难行。下图展示了一个可以良好支撑数据中台建设的大数据平台：

上图中描述的大数据平台，划分为了多个模块：

• 底层是以 Hadoop 为代表的大数据计算、存储基础设施，提供了大数据任务运行所必须的计算、存储资源。
• 在 Hadoop 之上，浅绿色部分提供了各类工具产品，包括覆盖整个数据加工流程的数据集成、数据开发、数据测试和任务运维，基础的监控运维系统、 权限访问控制系统和项目用户管理系统，以及方便多人协作的流程协作与通知中心。
• 灰色部分是数据中台的核心组成部分：数据治理，它对应的方法论就是 OneData 体系。以元数据中心为基础，在统一了企业所有数据源的元数据的基础之上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品，分别对应数据发现、模型、质量、成本和指标的治理。
• 深绿色部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是 OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延伸到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的 API 接口获取数据。
• 在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统，面向数据开发、分析师的自助分析系统，面向敏捷数据分析场景的 BI 产品，活动直播场景下的大屏系统，以及用户画像相关的标签工厂。

有了这样一个可以支撑数据中台建设整个过程的大数据平台，再配合规范化实施，就能够比较容易地搭建出一个数据中台。

数据中台组织架构

数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。这个部门的负责人应该直接向公司的 CTO 汇报工作，当然这个也要取决于数据中台建设的层次。然而独立部门的最大风险是与业务脱节，所以数据中台部门的人必须要懂业务，能够深入业务，扎根业务。数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。

数据中台部门下可以参考如下划分团队：

• 数据产品团队：负责数据中台和数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护。
• 数据平台团队：负责研发支撑数据中台建设的工具，例如指标系统、元数据中心、数据地图等。
• 数据开发团队：负责维护数据中台的公共数据层，满足数据产品的数据需求。
• 应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析等。

数据中台部门的绩效目标一定要与业务落地价值绑定，比如在电商供应链决策系统的智能补货功能，会根据商品的库存，各个地区的历史销售情况，生产加工周期，自动生成补货决策，由人工审核以后，直接推送给采购系统。那么评估价值时，可以拿由系统自动生成的采购计划占整体采购计划的比例来衡量数据的应用价值。

最后，数据中台的组织架构改革涉及原有各个部门的利益，这个才是数据中台建设最难又不得不做的地方，必须要取得高层领导的支持和重视。