//  前期回顾

企业如果想要玩转数据中台，真正做到让数据用起来，并推动自身业务的发展，除了确立有效的组织形式，推广围绕数字化转型的协作方式之外，还需要一套得心应手的系统工具来帮助企业将中台战略落实。

数据中台经过几年的发展，已经在不同规模、行业、领域的企业、机构中得到落地执行，也仍然有众多企业在观察、分析数据中台在自身生命周期发展中存在的必要性。这其中，企业要建设什么样的数据中台、如何建设、需要什么能力是CIO们近年来面临的核心命题。

上一期介绍了“四化”中的业务数据化，本期将从数据资产化、资产服务化、服务业务化这三个环节来继续介绍如何打造企业数据中台建设所需产品技术能力。

数据资产化

1.元数据

元数据是描述数据的数据，通俗一些就是将数据作为一个对象，用一些属性来刻画它，这些属性就是元数据。对于数据本身的元数据可以是数据在产生时天然自带的，也可以是人工自定义补充的。只要能够让使用人员理解数据在描述什么，就起到了元数据的作用。

元数据通常使用“采集”的方式获取，并注册到数据中台。在采集之前要定义好“元模型”，将采集目标的数据结构定义完整，之后通过手动或自动，定期或实时的方法进行元数据采集。

元数据可以应用在多个方面。例如血缘分析、影响性分析、指标一致性分析、数据查询检索、自动数据清洗处理、数据链路展示等场景，元数据将数据资产更具象化地展示给企业的管理者、数据研发与分析人员，方便各职责人员掌握、理解数据。

2.数据建模

业务数据在存储时，为了便于业务流程的使用，数据存储的结构、位置与格式更多是为了应用程序方便调用设计，而不是用来分析决策。因此要想让数据能够形成资产方便加工处理或者业务查询分析，需要对数据进行加工处理，处理的原则和指导方案就需要数据建模能力支持。

数据建模包含数据标准以及构建数据模型两部分工作。数据标准定义了数据元的术语要求、类型、值域、大小范围等规范，数据模型将数据元进行拼装，形成可物理化为实际数据表的逻辑定义。在数据建模过程中，就要考虑在仓湖中，不同层级数据资产的处理过程和数据形态。

常规的数据仓湖分层包括：贴源层、明细层、汇总层、应用层以及公共维度层，不同存储层的数据内容不同：

• 贴源层存储与原始数据相同的数据，所以数据结构与原始数据一致

• 明细层是对业务分析后，根据主题，将业务明细数据与描述对象的维度数据拆分，形成明细层数据与公共维度层数据

• 汇总层是对明细层按对象的聚合、统计计算形成指标数据

• 应用层是根据不同数据应用需求，总结数据专题，形成可直接提供数据服务的层级

3.数据处理

数据资产化的主要工作由数据开发人员根据定义好的处理规则编写执行代码来完成，根据不同的数据处理目标，选择适合的处理方法。

｜ 流批计算

对于大部分企业来说，由于数据分析、使用的场景对于数据的及时性要求不高，所以离线数据计算已经能够满足需求。

随着业务规模增长，对于数据的实时性要求会越来越强，甚至将借用大数据技术来直接解决业务问题，例如提供即席的银行余额查询服务、智能生产车间设备联动等，这些场景下要求数据产生即计算，而不是积攒一批后统一计算。

流批计算的常见架构主要有Lambda架构与Kappa架构：

• Lambda架构是将流与批分开，虽然数据计算结果相同或相近，但需要搭建两套环境、写两份相同逻辑的代码，造成整体运维成本、资源需求都将翻倍，好处是批量计算拥有成熟稳定的基座，能够让分析的数据得到更准确的结果；

• Kappa架构是仅使用流计算处理引擎的模式，不同的数仓层级中使用Kafka消息队列来缓存数据，这种架构的好处是只需要编写一套代码即可以完成数据处理，但数据分析人员只能从应用层获取结构化数据来分析，而不能从明细层、汇总层等获取数据进行分析。

由于两种架构都各有较明确的缺陷，因此出现了使用数据湖替代Kappa架构中Kafka地位的混合架构。首先，数据湖本身的ACID特性，能保证数据的准确性；其次，虽然在实时性上，相对Kappa架构较慢，但仍然可以提供毫秒级的数据计算分析；第三，数据湖存储本身提供表格形式供应用读取，对SQL语言兼容性强，所以在任何数仓层级的数据都可以被随时消费使用，对于数据分析人员更友好。

随着数据湖存储、计算的发展以及流批计算的统一，未来企业将无需考虑数据的界限，所有数据都能够在线完成处理，让业务对数据的分析使用更加灵活。

｜  Id-mapping

流批计算主要使用SQL进行计算处理，在实际数据处理过程中，由于数据类型或者处理目标不同，需要灵活的选择非结构化、半结构化数据处理的方法辅助处理数据。对于业务方，在市场运营、产品运营方面，最迫切的是希望通过数据更精确的描述客户画像，通过给人、物、关系打标的方式来过滤圈选目标对象，做到最小的成本投入，获取最佳的收益，但是往往用户的数据分散在不同业务中，并且大部分数据缺少相同的编号来索引确认关系，这就需要使用Id-mapping方法。

由于标签数据的体量过于庞大，用常规的二维表数据处理已经无法满足，而且标签值之间存在与结果强相关的关系，所以通常在Id-mapping应用中，会采用图计算技术。将所有的标签值（能够代表对象实体的）定义为一个图中的节点，然后通过一定的规则算法为任意两点之间赋予关系权重，构建无向带权图。完成图构建之后，要根据业务需要切分重组，将关联度强的节点划分到一组，并记录相关权重，当业务方需要使用关联关系时，就可以快速索引到相关对象并开展业务。

Id-mapping主要支撑于数据应用，并且数据根据选择的权重阈值、标签取舍需要快速完成计算，所以图数据存储位置也需要在标签层或者应用层，以满足业务使用。

除了Id-mapping，还有广泛的数学分析方法，可以便于数据仓湖的构建与数据挖掘，通常这些数学分析方法可以打包为机器学习算法组件，快速被数据计算引擎使用，成为数据中台基础能力，而无需每次由开发人员重新学习设计。

数据处理技术选型

4.质量控制

数据资产要能够被放心地使用、交易，质量需要得到有效保障。

质量的管控贯穿整个数据资产化过程，在数据接入中台时，就可以通过关联原始数据的元数据与数据标准进行稽核探查，将不符合标准的数据反馈给数据业务归口部门，从源头解决问题；如果源头无法解决问题，也可以在数据处理过程中对质量进行控制，这时候就靠数据建模中提到的数据模型发挥作用。

通过模型生成的物理表将会具备额外的元数据属性，用于关联监控其是否符合标准的质量控制单元。在持续加工数据产生数据时，系统要能够对数据进行检查稽核，并在发生问题时及时预警，甚至阻止加工作业，降低业务方使用错误数据的风险。

除了不符合数据标准的数据被视为质量问题外，还可以增加额外规则来检测数据质量。有的时候每一个任务处理的数据都合乎标准，但在使用时却出现了与常理或业务相悖的错误，这时就需要联合多个数据对象基于一定计算标准分析、测试质量问题，这时也可以使用指标标准来进行辅助检测，帮助发现数据质量问题的产生原因。

5.安全保障

数据安全贯穿于数据的整个生命周期，在数据资产化过程中，企业需要通过各类手段来对数据的安全属性进行定义、管理与落实，确保数据资产在全域的安全使用、传输。

数据权限管控是数据安全的主要方式。在实践中，元数据采集后，就需要对数据进行分类定级，并规定哪类用户可以对哪些数据有哪些权限，也可以直接对数据资源的物理权限进行分配，在不影响数据生产的情况下，降低数据泄露或者被破坏的概率。

除权限管控之外，还可以设置多种监控规则来识别数据安全风险，做到事前预警、事中阻止、事后审计，周期性的为数据管理人员、运营人员推送数据安全分析报告，及时修复解决安全问题，保护企业核心资产。

资产服务化

数据集成是数据中台要具备的核心能力之一，通过数据集成能够将数据从业务系统数据库中抽取到中台，也可以将处理好的数据推送给数据应用使用。在处理对象上，根据数据结构不同，要能够提供非结构化数据同步、结构化数据同步以及结构化数据转换同步的能力。对于结构化数据同步，还要能够支持全量与增量同步，以保证数据的完整、时效。

数据传输过程中，系统要具备脏数据处置的能力，以保证传输数据的有效性，以及追溯问题数据能力，并进行及时修正。脏数据可能是不符合数据标准定义的数据内容，也可能是计算引擎中无法写入的不规范数据，这些数据可能是业务系统发生异常时产生的，也可能是在数据治理之前记录的，但通过数据中台的脏数据管控就可以及时发现并从根本解决问题。

除了数据内容的管控，数据集成还需要提供例如断点续传、反压监测、流量控制等对传输过程性能、流程管理的能力，保障数据能够稳定可靠的传输，在出现网络抖动、流量异常时，能够及时处理任务的运行状态和速度，保障数据的准确性。

2.数据交换

与数据集成不同，数据交换是多方基于相同数据需求与传输协议的数据流通过程。对于数据需求方，无需关心数据提供方 的数据存储在哪里，只关注是否有这些数据、数据是否正确；对于数据提供方，无需关心数据需求方数据如何加工处理 （但需要了解需求方的业务目标以保障数据的合法合规使用），只关注数据准时、准确提供，并创造了相当的价值。

根据交换主体之间的关系不同，交换模式也会有所区别：

• 对于集团和旗下子公司或部门之间可以采用直接交换的模式， 通过下发任务的方式完成数据的上报和下发；

• 对于政务部门之间通常采用授权交换的模式，通过审批流来保证数据安全流通；

• 对于多个独立企业之间会采用安全交换或API服务的方式进行数据共享，彼此之间找到一个可信第三方提供计算服务，或者通过接口的方式对数据脱敏输出供需求方使用。

在数据交换基础上，可以根据安全的需要、数据保密的需要，应用隐私计算技术，通过可信执行环境（TEE）来进行具体数据的传输，保证数据交换双方彼此之间在不同加密方法之下安全的流通数据。

3.数据接口

数据接口是最常用的为数据应用提供数据服务的方式，通过将数据源中半结构化数据标准处理后，注册到网关供应用方直接调用，而不需要各应用方自己拼接SQL到数据库中查询数据，是能体现数据中台思想与独特价值的能力之一。

数据接口也可以划分两大类，一种是提供数据的接口，一种是提供能力的接口。提供数据的接口通常使用脚本或者SQL语言对数据库进行查询操作，并在配置好出入参数后发布到网关；提供能力的接口通常对接统一的模型运行服务模块，这类模型基于数据资产训练而成，为应用提供预测与分析服务。

服务业务化

无论哪个行业、领域，都会面临相同模式的数据使用、分析需求，满足通用场景的应用就是通用应用。

对企业整体经营分析研判的指标应用，能够通过统一的维度建设、业务域下的指标管理，为企业提供上下一致口径的数据指标查询与计算服务，业务人员无需掌握数据仓库知识，只需要通过业务术语就能够掌握企业各业务经营情况，并作出相应决策。

完成决策并落地运营时，可以使用标签应用。标签应用通过实体、关系、行为以及场景的通用模型，在数据仓库基础上构建业务模型，对业务对象进行多维度刻画。通过标签这种业务模型组织方式，连接数据模型以及物理模型，形成三模合一的数据应用模式。业务人员只需要操作对象和属性，就可以快速选定目标人群、商品等数据，并进行业务消息推送、活动宣传推广等动作。

除了指标与标签应用，还有诸如视频分析、自然语言处理等非结构化数据的分析类型应用，企业可以根据自身业务属性加入固定的分析方法模式、分析内容结构、业务术语等，将通用应用打造成符合自身业务属性的领域应用，更好的与业务相互融合。

服务业务化

结束语