近些时间一直在做数据可视化方面的一些工作，主要会用到公司的数坊工具，引发了我想对数据中台的一些思考。找了本书看，《数据中台-让数据用起来》，把书中一些感兴趣的点记录于此罢，内容大多抄录书中原文，行文逻辑大概如下：
先给出数据中台的定义，再聊聊数据中台应该具备的功能，他与业务中台的区别。然后会说到如何打造数据中台,从数据抽取，到数据开发，再聊到数据体系的建设，最后顺带说两句元数据。
一.什么是数据中台
数据中台是一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。数据来自于业务，并反哺业务，不断循环迭代，实现数据可见、可用、可运营。 
简而言之，数据中台就是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的一个逻辑概念。
二.数据中台必备的核心能力
数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现4个核心能力，让企业员工、客户、伙伴能够方便地应用数据。
1.汇聚整合
随着业务的多元化发展，企业内部往往有多个信息部门和数据中心，大量系统、功能和应用重复建设，存在巨大的数据资源、计算资源和人力资源的浪费，同时组织壁垒也导致数据孤岛的出现，使得内外部数据难以全局规划。数据中台的第一个核心功能就是能够汇集各个业务系统数据，同时能够为各系统做数据联通，避免数据孤岛的出现。
2.提纯加工
数据中台必须连通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，满足企业业务对数据的需求。
3.服务可视化
为了尽快让数据用起来，数据中台必须提供便捷、快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。
4.价值变现
数据中台通过打通企业数据，提供以前单个部门或者单个业务单元无法提供的数据服务能力，以实现数据的更大价值变现。
三.数据中台与业务中台的区别
业务中台更多偏向于业务流程管控，将业务流程中共性的服务抽象出来，形成通用的服务能力。比如电商平台，有C2C、B2C、C2B、B2B四种模式，其中订单、交易、商品管理、购物车等模块都是有共性的。将这些组件沉淀出来，形成电商行业的业务中台，再基于这些业务中台组件的服务能力，可以快速搭建前台应用。
业务中台是抽象业务流程的共性形成通用业务服务能力，而数据中台则是抽象数据能力的共性形成通用数据服务能力。比如，原始业务数据通过资产化服务化，形成客户微观画像服务，这个服务可用于电商平台的商品推荐，也可能用于地产购房意愿，还可能用于金融领域的信用评级等。同一个服务，在应用层面展现的内容可能不一致，但是底层的数据体系是一致的。数据中台也将极大提升数据开发的效率，降低开发成本，同时可以让整个数据场景更为智能化。
如果同时拥有业务中台和数据中台，则数据中台与业务中台是相辅相成的。业务中台中沉淀的业务数据进入到数据中台进行体系化的加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又流转到数据中台，形成循环不息的数据闭环。
业务中台与数据中台互相促进，为企业业务的发展、管理者更好的决策提供支持。其中，业务中台的存在是为了围绕公司业务运营进行服务，将获取的多维度数据传递给数据中台，由数据中台挖掘新的价值反馈给业务中台，以优化业务运营。
四.数据汇集联通：打破企业数据孤岛
要构建企业级的数据中台，第一步就是要让企业内部各个业务系统的数据实现互联互通，从物理上打破数据孤岛，这主要通过数据汇聚和交换的能力来实现。
数据采集一般有以下这些方式：线上行为采集（埋点），线下行为采集（Wifi探针、摄像头等），互联网数据采集（网络爬虫），内部数据汇总（业务系统入仓）等。
在数据建设过程中有ETL（Extract-Transform-Load， 抽取-转换-存储）的操作，即在数据抽取过程中进行数据的加工转换，然后加载至存储中。但在大规模数据场景下，一般不建议采用ETL的方式，建议采用ELT(Extract-Load-Transform，抽取–存储–转换)的模式，即将数据抽取后直接加载到存储中，再通过大数据和人工智能相关技术对数据进行清洗和处理。如果采用ETL的模式在传输过程中进行复杂的清洗，会因为数据体量过大和清洗逻辑的复杂性导致数据传输的效率大大降低。另一方面，ETL模式在清洗过程中只提取有价值的信息进行存储，而是否有价值是基于当前对数据的认知来判断的，由于数据价值会随着我们对数据的认知以及数据智能相关技术的发展而不断被挖掘，因此ETL模式很容易出现一些有价值的数据被清洗掉，导致当某一天需要用这些数据时，又需要重新处理，甚至数据丢失无法找回。相比存储的成本，这种损失可能会更大。
数据汇聚是数据中台建设的第一个环节，其主要目的是打破企业数据的物理孤岛，形成统一的数据中心，为后续数据资产的价值挖掘提供原始材料。同时需要注意的是，企业的每一个业务端都是一个数据触点，会产生大量的数据，这些数据的生产和采集过程需要符合数据安全、隐私保护的相关要求。
五.数据开发，数据价值提炼工厂
汇聚联通到中台的数据，基本是按照数据的原始状态堆砌在一起的，是企业对过往所有IT信息化建设积累的成果的融合。数据开发是数据资产内容建设的主战场，是数据价值生产过程中的核心环节，可以支撑大批量数据的离线处理、实时处理和数据挖掘等。业务沉淀的数据就像原始的矿石或商品的原材料，数据开发这个环节就像是“商品”生产的流水线，通过这条流水线将数据转换成数据资产，让数据能根据业务的需求转换成新的形态，将原本看起来没有价值的数据变成对业务有价值的资产，为前端业务源源不断提供所需要的“商品”。数据开发涉及的产品能力主要包括三个部分，分别是离线开发、实时开发和算法开发。
- 离线开发
离线开发需要一些核心的功能（如作业调度的策略机制、对于数据生产时效的基线控制、 企业当前信息化架构下各类异构数据源的适配、数据权限的管控等）来保障数据加工的过程易用可控。
作业调度：在数据开发过程中，经常需要配置作业的上游依赖作业，这样作业之间便会组成一个有向无环图(DAG，Directed Acyclic Graph)，同时会配置作业的开始调度时间。
基线控制：在大数据离线计算中，由于作业执行时间较长，经常会遇到急着用数据却发现数据还没出来的情形。重新跑需要几个小时，时间已然来不及。书中提出一种基线控制方法，用于统一管理数据处理作业的完成时间、优先级、告警策略，保障数据加工按时完成。
异构存储：计算储存引擎的多元化。
代码校验：语法校验和规则校验。
推荐依赖：随着业务的不断深入，企业对工作流和作业与业务结合的理解越来越深，数据开发人员需要开发的作业会不断累加,峰值时一个工作流下会挂成千上万个作业。这时候就需要一把利器，能自动推荐上游作业，既能保证准确找到需要定位的上游作业，又能保证不会形成环路。
数据权限:构建统一的权限管理系统来支持多种引擎，可以直接在此系统上进行各种引擎的权限申请、审批和管理，无须接触底层引擎的权限管理系统。 - 实时开发
实时计算起源于对数据加工时效性的严苛需求：数据的业务价值随着时间的流逝会迅速降低， 因此在数据产生后必须尽快对其进行计算和处理。通常而言，实时计算具备以下三大特点：
实时且无界(unbounded)的数据流;
持续且高效的计算;
流式且实时的数据集成; - 算法开发
面对前台的智能业务需求，传统的数据加工和分析往往难以满足，作为数据开发的重要工具，算法开发需要满足复杂的学习预测类智能需求，输出算法模型能力，将数据洞察升级为学习预测，驱动业务创新。当数据开发和资产加工无法满足数据挖掘、算法标签生产等场景的需求时，算法开发可为离线开发和实时开发提供算法模型。加工好的数据和标签资产又能被算法开发用于模型训练和学习预测，支持智能需求研发。
关于算法开发，能谈的东西太多，在此只说一点，特征工程是算法开发的一个非常核心关键点。所谓特征工程，是指在算法开发过程中，利用特征选择、特征加工、特征降维等技术手段构建对结果具有显著影响或便于模型处理的特征。利用特征工程相关的组件可以快速构建特征体系、快速选择有效特征，进而大幅提高算法的质量，提升分析效率。常见的组件有主成分分析、特征尺度变换、特征离散、特征异常平滑、奇异值分解、one-hot编码等。机器学习，并非把原始数据往模型里一扔，优化调整参数就能得到想要结果的，前期的数据清洗，特征提取、筛选尤为重要。
六．数据体系建设
数据中台建设、管理、应用的核心是数据，那么数据中台中的数据采用的是什么体系结构？使用的是什么建设方法呢？
数据中台是企业数据汇聚地，企业的一切数据都汇聚到数据中台，企业业务所需的数据总能在数据中台找到。但数据中台中的数据并不是简单地堆积，各种系统产生的原始数据堆积在一起导致使用成本非常高，这类数据只能在某些数据技术基础非常好的部门使用，而且会经常出现命名不一、口径不一的问题，从而导致整个企业数据无法真正用起来。数据中台数据体系是在全域原始数据的基础上，进行标准定义及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便支撑数据应用。
中台数据体系应具备以下特征：覆盖全域数据；结构层次清晰；数据准确一致；性能较好；成本较低；方便易用。
为了使数据体系在建设时具备以上特征， 需要一个体系化的数据层次架构， 这个层次架构定义了数据分层及每一层的模型建设规范。 数据体系架构是一套指导规范， 实施过程中应严格按照架构执行。下图就是数据中台数据体系的一个常规架构。
贴源数据层ODS（Operational Data Store，又称操作数据层）：对各业务系统数据进行采集、汇聚，尽可能保留原始业务流程数据，与业务系统基本保持一致，仅做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。
统一数仓层DW(Data Warehouse)：又细分为明细数据层DWD(Data Warehouse Detail)和汇总数据层DWS(Data Warehouse Summary),与传统数据仓库功能基本一致，对全历史业务过程数据进行建模存储。对来源于业务系统的数据进行重新组织。业务系统是按照业务流程方便操作的方式来组织数据的，而统一数仓层从业务易理解的视角来重新组织，定义一致的指标、维度，各业务板块、业务域按照统一规范独立建设，从而形成统一规范的标准业务数据体系。
标签数据层TDM(Tag Data Model)：面向对象建模，对跨业务板块、跨数据域的特定对象数据进行整合，通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。
应用数据层ADS(Application Data Store)：按照业务的需要从统一数仓层、标签数据层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。
七.元数据管理
究竟元数据是个啥？元数据是描述数据的数据。有点扯！直白点说，元数据是数据的户口簿。想想一个人的户口簿是什么，是这个人的信息登记册：上面有他的姓名、年龄、性别、身份证号码、住址、原籍、何时从何地迁入等，除了这些基本的描述信息之外，还有他和家人的血缘关系，比如父子、兄妹等。所有这些信息加起来，就构成了对这个人的全面描述，而这些信息都可以称为这个人的元数据。同样，如果要描述清楚一个现实中的数据，以某张表格为例，则需要知道表名、表别名、表的所有者、主键、索引、表中有哪些字段、这张表与其他表之间的关系等。所有的这些信息加起来，就是这张表的元数据。
元数据管理是数据治理的核心和基础。想象一下，一位将军要去打仗， 他要掌握的必不可少的信息是什么？对，是战场的地图。很难想象手里没有军事地图的将军能打胜仗。而元数据就相当于所有数据的一张地图。
通过这张关于数据的地图，可以知道：
1. 有哪些种类的数据；
2. 有哪些信息系统、哪些数据库、哪些表、哪些字段；
3. 数据全量是多少，每日增量是多少；
4. 数据分布在哪里；
5. 数据之间有什么流向关系；
- 本文算不上是对《数据中台》一书的提炼总结，只是个引子而已，原书内容远不止于此，书中还聊到数据资产管理、数据服务体系的建设、数据中台的运营机制、数据安全管理等等，感兴趣的同学可以看看。
作者：陈淅灿