很多企业都在建数据中台，但不被业务吐槽的还是少数，如何走出数据中台建设达不到业务预期的困局，以下是本人对数据中台建设的一种建设思路。
一、数据中台vs传统数据架构
如今似乎人人都在提数据中台，但是大家对数据中台并没有一个很清晰的概念，不同的人员对数据中台会有不同的理解，甚至有人将数据中台等同于大数据平台、数据仓库、数据湖等技术。数据中台概念不同理解都有相应的道理，不过本人比较认可ThoughtWorks 数据和智能总监史凯的总结：“数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。
在传统数据开发中，核心数据模型的变化是相对缓慢的，同时，对数据进行维护的工作量也非常大；但业务创新的速度、对数据提出的需求的变化，是非常快速的。数据中台的出现，就是为了解决数据开发和应用开发之间，由于开发速度不匹配，出现的响应力跟不上的问题。
从整体概念来看，数据中台并不是脱离于传统数据架构的独立存在，而是传统数据架构的能力优化和补充；而从系统实施角度看，本人更倾向于将所有数据服务的整体视为数据中台，也就是数据中台包含传统数据架构的设计，并在其之上进行了优化，使数据更便于应用、能更快速响应需求。
架构图来源：公众号文章《数据中台到底包括什么内容？一文详解架构设计与组成》
上图是一个公众号文章对数据中台分层架构的示例图，按工具平台、数据资产、数据应用三个维度对数据中台进行分层列举，其中有传统数据架构的内容，如源数据模型、主题域模型、标签模型可以对应传统数据架构上的ODS、数据仓库、数据集市等；也会有传统数据架构不包含的内容，如统一数据服务，机器学习等。
本人认为，数据中台架构实际上是在传统数据架构和方法论基础上，利用大数据、机器学习等技术补充了实时数据访问服务和实时数据决策服务的能力支撑，使数据服务更贴近前台业务应用的需要。
以下列举出数据中台和传统数据架构的差异：
（1）传统数据架构更偏重于数据治理，核心在数据标准和数据仓库的建设，关注点在数据自身，思路是怎么把数据理清楚；数据中台则更偏重于数据应用，核心在如何支撑业务应用，关注点在业务应用场景，思路是怎么把数据用起来；
（2）传统数据架构主要面向事后分析、决策、报送等方面的应用，只处理T+1的数据，对数据的实时应用支撑不足；数据中台则需要面对更多的实时业务场景，包括营销推送、反欺诈等，需要准实时/实时的数据服务支撑能力，要考虑高并发、快速响应的性能要求；
（3）传统数据架构在决策方面主要提供历史统计分析，服务于人工决策；数据中台则需要利用算法进行业务预测或实时决策，需要用到机器学习、规则引擎等技术（有些方案把反欺诈、授信审批的风控能力也纳入了数据中台的范畴）。
二、以数据资产管理为核心的数据中台建设思路
上一个章节对比了传统数据架构和数据中台的差异，从表面看似乎只要在传统数据架构上增加实时数据服务、数据决策服务、算法模型服务等系统模块就行了，但实际上真的这么简单就能完成数据中台的建设吗？
前面说过，数据中台的出现是为了解决数据开发和应用开发之间，由于开发速度不匹配，出现的响应力跟不上的问题。单纯地增加新的服务能力确实可以扩展数据的应用范围，但并不能从根本上解决数据开发响应力跟不上应用开发的问题。很多人一直在提一个说法，那就是“数据是新的石油”，但需要搞清楚，数据只会在使用过程中产生价值，否则就算有再多的数据，如果只是躺在硬盘上没有人使用，这样的数据则没有任何价值。而应用开发对数据的需求正是创造数据价值的最基本过程，这也正贴合了数据中台的思路：要怎么把数据用起来，而且是能快速应用起来。
我们再进一步分析一下为什么数据没有办法被前端应用快速使用，看看前端业务或开发人员最常见的问题：“我们现在具体有什么数据？”、“XX的数据在哪里能获取到？”、“为什么这两份数据不一样？”，这些问题对数据应用的影响：“因为不知道我们有什么数据，所以没有办法考虑怎么将数据用在业务创新上”，“要花很多时间和人力才能找到需要的数据来源”，“因为不清楚两份数据的口径所以没办法判断哪个是对的”。
继续引用ThoughtWorks 数据和智能总监史凯的观念，他认为数据中台最核心的一个关键组件是数据资产目录。“我们认为，一个企业的数据要能够充分发挥价值，很重要的一个前提条件就是这个企业的数据结构和数据资产目录是对整个企业开放的。所有人都能够通过这个资产目录了解公司有哪些类别的数据、包含什么属性、源数据由谁管理，这样就可以快速搞清楚这些数据是不是自己需要的。但数据本身可以不开放，因为数据是有隐私信息和安全级别的。”
我是十分认可史凯总这个观念的，同时有别于目前数据架构按系统组件逐个建设的思路（如第一章节的分层架构图），我认为未来数据中台会逐步转变为以数据资产管理为核心的建设模式，通过数据资产管理来整合、串接全行的数据应用，以支持数据的快速应用。在系统建设上，数据资产管理的能力落地系统可以命名为“数据资产门户”（当然也可以叫“数据资产目录”、“数据地图”等名字），承接全行数据资产的管理、查询、申请等基础功能，让企业内部所有人员可以快速找到自己所需的数据。
数据资产门户的整体功能设计如上图，其核心功能说明如下：
（1）资产管理
对企业内部的各种数据类资产进行统一的管理，主要的资产类型包括数据资产、指标资产、报表资产、标签资产、模型资产、技术资产，当然未来还会有更多的资产类型。数据资产门户主要管理这些资产清单、资产定义（口径）、资产示例（样例数据）、资产分类、资产来源（使用方法）、归属部门等信息，以便于企业人员便捷地查找和理解所有的数据资产。
数据资产的统一管理并不解决数据重复的问题，例如企业中可能有多个系统都会有客户相关的数据项，在数据资产门户中也同样可以查到多个相同或类似的数据项，不过基于数据资产门户可以让企业人员知道这些数据项有重复的情况，以及可以在哪些地方可以找到数据。
这里需要特别说明一下，数据资产门户所管理的只是资产相关的基础信息，并不包含实际的生产数据，因此并不会存在敏感数据泄露的风险；不过对于模型资产来说，可能会有部分模型是不允许公开的，因此还是需要有资产查询权限的控制。
（2）资产查询/展示
支持企业员工通过门户进行企业内部所有资产进行多维度的检索，便于快速查找到所需要的数据资产情况；此外提供对数据资产的详细信息的展示，可以让业务人员快速了解数据细节。
（3）资产维护
各数据管理部门的维护人员可通过门户进行数据资产的信息进行维护，对于无法自动采集的资产信息进行新增、修改等操作，对于可自动采集的资产进行缺失数据的补录，保证各类资产与当前实际生产保持一致。
（4）资产申请
企业内部的数据使用人员可以直接在门户上进行所需数据的使用申请，例如数据分析人员在门户上申请要使用的源数据表，在通过流程审批后，门户将自动联动后台系统每天定时将对应的表数据导入数据分析人员指定的数据分析沙箱环境。
（5）自动采集
数据资产门户需要支持对资产数据的自动采集功能，尽可能减少需手工维护信息的工作量，例如可以通过采集生产系统数据库的表结构、表注释、字段注释等信息，自动生成新增的数据资产的基本信息，这样只需人工维护或调整数据所属分类即可。
（6）版本管理
资产的每次变更都必须保留历史版本，这会有利于企业人员了解资产的变更过程，例如在企业中价值客户的定义是有可能调整的，今年100万存款视为价值客户，明年就可能提升至200万才算价值客户，资产信息的历史版本会有利于企业人员明白口径的变化，并可以基于历史口径看懂历史数据和当前数据的差异原因。
传统数据架构一般采取以数据仓库为核心进行建设，解决全行数据汇集、数据模型统一、数据口径统一的问题，不过数据入仓的过程通常会比较长，同时也解决不了让使用人员了解数据的问题，因此在遇到比较紧急的数据需求，很多应用开发人员都会选择绕过直接使用源系统数据（通过ODS）的做法。当前要求数据开发快速响应应用开发的需求会越来越多，未来很有可能都会是先利用源系统数据实现业务应用，待数据入仓后再进行数据切换，因此对数据特别是源系统数据的梳理工作显得更为紧迫。所以可以考虑改变一下数据架构的建设思路，采用以数据资产管理为核心的思路开展数据基础建设，让所有数据系统围绕数据资产门户的资产管理需求，让数据资产直接展现在企业员工面前，以真正实现数据的便捷、可用。
数据资产门户上数据资产信息的完整性和准确性，是影响数据中台应用效果的最大因素，因此要避免使用容易出现遗漏或更新不及时的手工维护模式（除补录历史数据资产），而是要尽可能实现数据资产的自动采集和自动更新，这也是为什么我建议要以数据资产管理为核心来进行数据中台建设。如上图所示，在数据中台建设的整体过程中都必须考虑和实现每个系统模块的数据资产信息的自动采集能力，将采集过程直接嵌入到开发工具及开发流程上，以此保障所有数据资产可实时、准确地反映在数据资产门户上。
建设数据资产门户的难点并不在数据资产信息管理本身（简单的信息管理系统现在一两个月就能开发出来），而是在于如何实现数据资产信息的自动采集，这将对数据开发工艺流程有较大的变动。
举几个例子让大家更容易理解：
（1）在源系统数据字典自动采集功能上，需要所有源系统按开发规范在数据库的表上增加完整的注释，以此让采集程序能自动获取与生产一致的数据字典；对于不适合向让运维人员明示设计的敏感表，以及无法建立注释的架构，则需要优化开发流程，确保上线的数据字典在元数据管理系统可以正确获取到数据字典信息；
（2）在离线计算的ETL血缘关系自动采集功能上，可以通过改造ETL开发工具，通过Mapping开发模式来实现数据ETL过程的血缘关系管理和自动采集；同步也在开发流程中明确每个结果数据的定义（如数据项定义，或指标口径定义），并提交数据资产门户采集，而不是事后再进行补录；
（3）在报表口径的自动采集上，需要业务需求提出时就按照数据资产管理要求给出完整的口径说明（当然这一步也可以在需求分析过程中产生），或者直接在数据资产门户上提交报表需求，并实现与报表上线流程的状态更新联动，来保证上线的报表跟数据资产门户信息的一致性。
简单来说，以数据资产管理为核心建设数据中台，并不是指将资源重点投入在数据资产门户这一个系统的建设上，而是在每一个数据系统的建设过程都要围绕数据资产采集和管理的要求进行系统设计、工艺流程的适配，这只是一个观念或设计理念上的调整，因此真正投入的资源还是在各个数据系统上。
以上是本人对数据中台建设的一个思路，虽然我们已经开始在做数据资产门户的尝试，但暂时还没有取得成功，只是基于此前走过的弯路，以及分析了业务批评声音后，对破解数据中台困局的思考，仅供大家参考。
