非常有幸参与《数据中台-让数据用起来》的鲜读活动，第一时间在出版前就尝鲜阅读。全书按照Why--What--How的方式，先讲清楚为什么需要数据中台，再由表及里阐述数据中台到底是什么，之后大量篇幅详细说明了怎么建设企业的数据中台。
1、为什么要数据中台？因为数据中台是对未来场景的能力支撑，是增援未来的能力。 建好数据中台，需要从钱、事、人的角度都发力才行，战略高度的顶层设计和规模化投资、面向数字化转型的方法论、新型信息化人才，缺一不可。
2、数据中台是什么？ThoughtWorks王健曾经给出中台的定义，企业级能力复用平台。本书给了数据中台的定义，一套可持续的“让企业的数据用起来”的机制。定义很简单，但是要建立这样一种机制可没那么简单。至少要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现４个核心能力，才有可能让企业员工、客户、伙伴能够方便地应用数据。这四种能力对应的正是数据→信息→知识→智慧，也就是D2V（Data to Value）的能力。
数据中台不是什么？首先它不是平台，平台可以有很多，可以有营销平台、风控平台、管理平台等，但是中台一个企业只需要有一个。 现在还有业务中台、数据中台之分，但未来数据和业务紧密结合融为一体，会统一成一个企业中台。 数据中台也不是数据仓库，数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。
3、怎么建设数据中台？
首先是方法论的总体价值框架，然后是从分析问题（评估模型 ）到解决问题的角度出发，分别从工具（获取、计算）、体系构建、使用、运营、安全等角度说明怎么建设。特别是第7章的数据体系构建，将数据中台做了层次结构划分，ODS贴源数据层、DW统一数仓层、TDM标签数据层、ADS应用数据层。对应到各企业的数据中台建设，基本上都能找到相应的架构映射。各层具体要怎么建设，书中给了非常非常详尽的讲解和示例。
读完之后的感受是，本书兼顾理论又重在实战，还需要再多读几次，能用于实战才是真的理解！
以下是阅读过程中的笔记（有点乱。。。）
ch1why?
三个核心认知（钱→事→人）
1.数据中台更需要企业从战略高度进行顶层设计、确定规模化投入政策、设置更合理的组织架构，才能够确保数据中台作为数据应用的基础设施并落地建设，承担起企业数据资产全生命周期的管理。
2.率先解决面向数字经济特征的全新数据价值观和方法论的问题，并在其指引下打造出平台级能力，谁才能真正意义上帮助企业把数据用起来。
3.吸引到或培养出拥有业务、数据、分析等综合素养的新型信息化人才。
能直接作用于业务领域，业务能阅读、能理解的数据才叫数据资产。
数据中台是对未来场景的能力支撑，是增援未来的能力。
ch2what?
数据中台是一套可持续的“让企业的数据用起来”的机制，是一种战略选择和组织形式，依据企业特有的业务模式和组织架构，通过有型的产品和实施方法论支撑，构建一套持续不断地把数据变成资产并服务于业务的机制。
4个核心能力：数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现４个核心能力，让企业员工、客户、伙伴能够方便地应用数据。
1.汇聚整合（形成数据）
2.提纯加工（数据→信息）
3.服务可视化（信息→知识）
4.价值变现（知识→智慧）
从战略上来看，汇聚整合、提纯加工、服务可视化和价值变现的能力是数据中台最核心的竞争力 业务中台vs数据中台
业务中台是抽象业务流程的共性形成通用业务服务能力，而数据中台则是抽象数据能力的共性形成通用数据服务能力。
中台不是平台，平台可以有很多，可以有营销平台、风控平台、管理平台等，但是中台，一个企业只需要有一个。 现在还有业务中台、数据中台之分，但我们预测未来数据与业务会更紧密地结合，完全融为一体，会统一成“企业中台”。
数据中台vs数据仓库
数据中台建设包含数据体系建设 。数据仓库的主要场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。数据中台持续不断地将数据进行资产化、价值化并应用到业务，并关注数据价值的运营。
数据中台的价值：数据中台是把数据这种生产资料转变为数据生产力的过程。
业务价值：从洞察走向赋能业务创新，形成核心壁垒。
技术价值：
1.针对不同的数据应用场景，需要能够快速应对多数据处理需求，比如：
要保持原来的报表需求，仍需要保持批量离线计算的能力（Hadoop、Oracle RAC）；
针对准实时的指标统计和实时推荐，需要实时流式计算的能力（Storm、Spark Streaming、Flink）；
针对决策类业务如海量人群的圈人需求和ad-hoc需求，需要即席计算能力（Greenplum、Elasticsearch、Impala）；
针对高并发业务场景（如用户画像），需要在线计算能力（MySQL、Redis、Oracle）。
2.丰富标签数据，降低管理成本
3.数据的价值能体现业务系统效果而不仅是准确度
4.支持跨主题域访问数据
5.数据可以快速复用而不仅是复制
ch3数据中台建设和结构how?-架构
价值框架
业务产生数据，数据服务业务，业务在阳，数据在阴，阴阳互相滋补，形成闭环
数据中台必须拥有与企业的设计部门、制造部门、销售部门等同样重要的地位。
数据是企业的战略资产！
数据中台建设方法论
1个战略：数据中台要求整个企业共用一个数据技术平台、共建数据体系、共享数据服务能力。 只有企业的一把手才有这种推力来推动数据中台的建设。 2个保障：数据中台战略的执行必然伴随着企业组织保障以及整个企业数据意识的提升。 用一句话来概括数据文化：用数据说话。
数据采集（尽可能采集一切业务触点数据——数字化感知响应），数据标准化（数据治理），数据使用，数据安全。
3个目标准则 可见、可用、可运营。
4套建设体系
技术体系、数据体系、服务体系、运营体系。TA+IA+AA+OA
5个关键步骤 其中最关键的是标签体系建设。所谓标签体系是面向具体对象构建的全维度数据标签，通过标签体系可以方便地支撑应用，大数据的核心魅力和服务能力主要就体现在标签体系的服务能力上。
所谓持续建设和运营是指在架构基本稳定的情况下，不断循环第3~5步，多方角色会围绕核心KPI不断挖掘数据和业务场景的结合点，不断根据质量和价值两个点去运营优化。
数据中台架构
数据资产：数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。
数据服务：服务模块并没有自带很多服务，而是提供快速的服务生成能力以及服务的管控、鉴权、计量等功能。
Ch4评估和选择 how?As-Is当前问题和阶段评估。即，分析问题。
数据应用成熟度评估模型
数据应用能力成熟度可以总结为统计分析、决策支持、数据驱动、运营优化四个阶段。
数据运营优化：1.能够追溯数据资产的形成过程；2.能及时获取到数据资产当前的状态，尤其是数据质量和安全情况，如更新频率、合规性、空值率等；3.能够知道数据资产被哪些业务调用了，以通过建立数据闭环了解和追溯数据资产所带来的业务价值；4.能够对整个数据中台从数据采集到数据应用的整个链路建立监控体系，便于及时发现和排除故障，保障数据资产的稳定性；5.建立丰富的数据内外部共享和服务渠道，实现数据价值的释放和交换。
Ch5数据汇聚联通 解决问题-取数工具（源>SDI->DWI）
数据获取（埋点，集成，爬虫）→数据交换→数据存储
大规模数据场景下，一般不建议采用ETL的方式，建议采用ELT（Extract-Load-Transform，抽取–存储–转换）的模式。即先取再存落地后转换，非传输过程中转换。
Ch6数据开发 解决问题-计算工具（DWI→DWR），技术平台。
Ch7 数据体系 解决问题-架构分层 数据中台数据体系是在全域原始数据的基础上，进行了标准定义及分层建模，数据体系建设最终呈现的结果是一套完整、规范、准确的数据体系，可以方便支撑数据应用。
特征：覆盖全域数据，结构层次清晰（纵向的数据分层，横向主题域、业务过程划分，让整个层次结构清晰易理解），数据准确一致（定义一致性指标，统一命名、统一业务含义、统一计算口径，并有专业团队负责建模，保障数据的准确一致），性能提升（统一的规划设计，选用合理的数据模型，清晰地定义并统一规范，并且考虑使用场景，让整体性能更好），降低成本（数据能被业务共享，这避免了大量烟囱式的重复建设），方便易用（总体原则是越往后越能方便地直接使用数据，复杂处理前置，公共计算下沉、明细与汇总共存）
中台层次结构
ODS贴源数据层，等同于SDI→DWI。
DW统一数仓层（DWD+DWS），等同于DWR。
TDM标签数据层（Tag Data Model）：面向对象建模，对跨业务板块、跨数据域的特定对象数据进行整合，通过ID-Mapping把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。 ——类似于DM层的一部分，通过标签化来构建。
ADS应用数据层（Application Data Store）：按照业务的需要从统一数仓层、标签层抽取数据，并面向业务的特殊需要加工业务特定数据，以满足业务及性能需求，向特定应用组装应用数据。 ——标准的DM层。
A. ODS贴源数据层
要求：贴源数据层的数据只被统一数据仓层使用，统一数仓层数据只被标签层和应用层使用。贴源数据层、统一数仓层只保存历史数据以及被标签层、应用层引用，不直接支撑业务，所有业务使用的数据均来源于标签层和应用层。
建模规范：
贴源数据层也叫操作数据层，ETL改用ELT方式，命名采用前缀+业务系统表名的方式，采用数据同步工具实现数据的同步落地。
B. 统一数仓层建设——标准化的数据底座（核心！）
统一数仓层站在业务的视角，不考虑业务系统流程，从业务完整性的角度重新组织数据。
统一数仓层建设过程以维度建模为理论基础，构建总线矩阵，划分业务板块，定义数据域、业务过程、维度、原子指标、修饰类型、修饰词、时间周期、派生指标，进而确定维度表、事实表的模型设计。统一数仓层建设过程如图：
业务板块：根据业务的属性划分出的相对独立的业务板块，业务板块是一种大的划分，各业务板块中的业务重叠度极低，数据独立建设，比如地产板块、金融板块、医疗板块等。（如财经、供应链、EBG、CNBG、CBG等）
数据域：数据域是统一数仓层的顶层划分，是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合，面向业务分析，一个数据域对应一个宏观分析领域，比如采购域、供应链域、HR域等。数据域是抽象、提炼出来的，并且不轻易变动，既能涵盖当前所有业务需求，又能在新业务进入时无影响地将其分配到已有的数据域中，只有当所有分类都不合适时才会扩展新的数据域。数据域是有效归纳、组织业务过程的方式，同时方便定位指标/度量。
怎么划分数据域（数据主题）？BA-->IA的过程
第一阶段：数据调研。
业务调研：确定项目要涵盖的业务领域和业务线，以及各个业务线可以细分成哪几个业务模块，各业务模块具体的业务流程是怎样的，通过跟业务专家访谈或进行资料文档收集，梳理主要业务流程、业务边界、专业术语等。
数据调研：调研全部数据目录信息，梳理数据流与业务过程关联关系。
第二阶段：业务分类。
业务过程提取：根据调研结果抽取出全部业务过程。
业务过程拆分：将组合型的业务过程拆分成一个个不可分割的行为事件，如下单、支付、收货、退款。
业务过程分类：按照业务分类规则，将相似特征的业务过程分为一类，且每一个业务过程只能唯一归属于一类。
第三阶段：数据域定义。
业务分类确认：对业务分类结果再次确认，避免分类范围中出现业务特征明显与其他业务过程无关的情况。
数据域定义：根据业务分类的规律总结出划分业务范围的标准定义。
数据域命名：为每个数据域起一个专属名称，并附上英文全称和简称。
第四阶段：总线矩阵构建。
关系梳理：明确每个数据域下有哪些业务过程，并梳理出业务过程与哪些维度相关。
矩阵构建：定义一张二维矩阵，将数据域下的业务过程与维度信息如实记录下来。
业务过程：业务过程是一种企业的业务活动事件，且是企业经营过程中不可拆分的行为事件，比如下订单、银行转账、账号注册都是业务过程。业务过程产生度量，并且会被转换为最终的事实表中的事实。业务过程一般与事实表一一对应，也有一对多或者多对一的特殊情况，比如累计快照事实表就会把多个业务过程产生的事实在一张表中表达。
模型设计：以建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实，同时设计出一套表命名规范。
维度表：维度是观察事物的角度，提供某一业务过程事件所涉及的用于过滤及分类事实的描述性属性，用于描述与“谁、什么、哪里、何时、为什么、如何”（5W1H）有关的事件，通常还包含了很多描述属性字段。比如“早上小王在小卖部花费5元钱购买了一个面包”，以购买为业务过程进行分析，可从这段信息中提取三个维度，即时间维度（早上）、地点维度（小卖部）和商品维度（面包）。
维度表设计：维度是维度建模的基础和灵魂，维度表设计得好坏直接决定了维度建模的好坏。维度表是统一设计的，在整个数据仓库中共享，所有数据域、业务过程都需要用到维度，都可以在公共维度表中获取相关维度属性。每个维度表都包含单一的主键列。维度设计的核心是确定维度属性，维度属性是查询约束条件（SQL where条件）、分组（SQL group语句）与报表标签生成的基本来源。
维度表通常有多列或者说多个属性，通常比较宽（维度表实际应用中包含几十甚至上百个属性的维度并不少见），是扁平型非规范表，包含大量细粒度的文本属性。维度表应该尽可能包括一些有意义的文字性描述，以方便下游用户使用。维度属性尽可能丰富。维度属性设计中会有一些反规范化设计，把相关维度的属性也合并到主维度属性中，达到易用、少关联的效果。
1. 选择维度：维度作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。维度一般用于查询约束条件、分组、排序的关键属性，维度既可以从报表需求中分析获取，也可以从与业务人员的交谈中发现。
2. 确定主维表：主维表一般直接从业务系统同步而来，是分析事实时所需环境描述的最基础、最频繁的维度属性集合。比如用户维表从业务系统的用户基本信息表中产出。
3. 梳理关联维表：数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。如商品与类目、SPU、卖家、店铺等维度存在关联关系。
4. 定义维度属性：从主维表或关联维表中选择维度属性或生成新的维度属性，过程中尽量生成更丰富、更通用的维度属性，并维护和描述维度属性的层次及关联关系。如商品维表，商品属于类目，类目属于行业。
事实表：事实是观察事物得到的事实数据，事实涉及来自业务过程事件的度量，基本都是以数量值表示，比如一次购买行为就可以理解为是一个事实，5元就是事实信息。在确定数据域与业务过程后，就可以根据业务过程涉及的维度、度量及粒度，设计相关的事实表。事实表不跨数据域，根据需要，一个事实表可能对应同数据域下一个或者多个业务过程。事实表又分为明细事实表和汇总事实表。明细事实表记录事务层面的事实，保存的是原子数据，数据的粒度通常是每个事务一条记录，明细事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。汇总事实表是把明细事实聚合那时的事实表，包括以具有规律性的、可预见的时间间隔来记录事实的周期快照事实表和以不确定的周期来记录事实的累计快照事实表。
事实表设计：事实表是统一数仓层建设的主要产出物，统一数仓层绝大部分表都是事实表。一般来说事实表由两部分组成：一部分是由主键和外键组成的键值部分，另一部分是用来描述业务过程的事实度量。事实表的键值部分确定了事实表的粒度，事实表通过粒度和事实度量来描述业务过程。事实表的外键总是对应某个维度表的主键，实际建设和试用过程中，为了提升事实表的易用性和性能，不仅会存储维度主键，还会把关键的维度属性存储在实施表中。这样事实表就包含表达粒度的键值部分、事实度量以及退化的维度属性。一切数据应用和分析都是围绕事实表来展开的，稳定的数据模型能大幅提高数据复用性。
在Kimball的维度建模理论中主要定义了事务事实表、周期快照事实表、累积快照事实表三种类型的事实表：
1. 事务事实表：事务事实表描述业务过程事务层面的事实，每条记录代表一个事务事件，保留事务事件活动的原始内容。事务事实表中的数据在事务事件发生后记录，一般记录后数据就不再进行更改，其更新方式为增量更新。事务事实表相对其他事实表保存的数据粒度更细，可以通过事务事实表对事务行为进行详细分析。
2. 周期快照事实表：周期快照事实表以具有规律性、可预见的时间间隔产生快照来记录事实，每行代表某个时间周期的一条记录，记录的事实是时间周期内的聚集事实值或状态度量。周期快照事实表的内容一般在所表达的时间周期结束后才会产生，一般记录后数据就不再更改，其更新方式为增量更新。周期快照事实表一般是建立在事务事实表之上的聚集，维度比事务事实表少，粒度比事务事实表粗，但是由于对事实进行了多种形式的加工从而产生了新的事实，故一般事实会比事务事实表多。
3. 累计快照事实表：累积快照事实表覆盖一个事务从开始到结束之间所有的关键事件，覆盖事务的整个生命周期，通常具有多个日期字段来记录关键事件时间点。周期快速事实表涉及的多个事件中任意一个的产生都要做记录，由于周期快照事实表涉及的多个事件的首次加载和后续更新时间是不确定的，因此在首次加载后允许对记录进行更新，一般采用全量刷新的方式更新。累计快照事实表一般用于追踪某个业务的全生命周期及状态转换，比如交易业务，涉及下单、支付、发货、确认收货，这些相关事件在不同的事务事实表中，通过事务事实表很难看到不同事件之间的转化及状态变化，通过累计快照事实表可把相关事件串起来放在一条记录中，这样就很容易解决了。（大宽表）
不管哪种类型的事实表，设计方法都类似，事实表设计可以遵循以下步骤：
第一步：确定业务过程。
企业业务是由一个个业务过程组成的，事实表就是为了记录这些业务过程产生的事实，以便还原任意时刻的业务运转状态。所以设计事实表，第一步就是确定实施所要表达的是哪一个或者几个业务过程。业务过程是企业活动事件，比如注册、登录、下单、投诉等都是业务过程，最基本的是每一个业务过程对应一张事实表，这样最容易理解。但是实际开发过程中，业务过程和事实表会存在多对多的关系。
第二步：定义粒度。
不管事实表对应一个还是多个业务过程，粒度必须是确定的，每个事实表都有且只能有唯一的粒度，粒度是事实表的每一行所表示的业务含义，是事实的细节级别。在实际设计过程中，粒度与主键等价，粒度更偏向业务，而主键是站在技术角度说的。虽然粒度在最终的事实表中很难被体现，但是定义粒度是必不可少的步骤，这样可避免整个事实表的业务含义模糊。
第三步：确定维度。
定义粒度之后，事实表每一行的业务含义就确定了。那么业务人员会站在哪些角度来描述事实度量？这就要确定维度了，常见的维度有时间、区域、客户、产品、员工等。维度依附于粒度，是粒度的环境描述。
第四步：确定事实。
事实就是事实表度量的内容，也就是业务过程产生的事实度量的计算结果，比如注册量、登录次数、交易金额、退款量等。事实表的所有事实度量都与事实表所表达的业务过程相关，所有事实必须满足第二步所定义的粒度。
第五步：冗余维度属性。
事实表的设计要综合考虑数据来源和使用需求，在满足业务事实记录的同时也要满足使用的便利性和性能要求。大数据时代，事实表记录数动辄亿级，甚至数十亿、数百亿，维表也有可能达到亿级甚至更多。利用标准维度模型会经常出现维表与事实表关联的情况，这种对亿级表的关联计算，在性能上是灾难性的。为了满足业务需求，降低资源消耗，建议适当冗余维度属性数据到事实表，直接利用事实表就可以完成绝大部分业务的使用需求，这样下游使用时可减少大表关联，提升效率。所以大数据时代，适当进行维度冗余是可取的。
注意：维度属性冗余与模型的稳定性是有矛盾的，因为维度的属性是有可能改变的，如果属性已经冗余到事实表中，那么维度属性就与事实一起被记录到事实表中。如果后续维度属性值改变，由于事实表已经生成，事实表的内容基本不会再做改变，这样就会出现已记录的维度属性与真实的维度属性不一致，导致数据错误的情况。属性的冗余是一种优化建议，冗余带来的收益与弊端要综合考虑。
粒度：粒度是指统一数仓层数据的细化或综合程度，对各事实表行实际代表的内容给出明确的说明，用于确定某一事实表中的行表示什么。确定维度或者事实之前必须声明粒度，因为每个维度和事实都必须与定义的粒度保持一致。原子粒度是最低级别的粒度，是对业务过程最详细的刻画，原子粒度事实必须保留。
指标：是在企业业务运转过程中产生的度量事实，被用于模型设计，是建模的基础。
原子指标：原子指标是某业务过程下具有明确业务含义的最小度量单元，是一种不可拆分的指标，具有明确业务含义，比如支付金额。原子指标有确定的字段名称、数据类型、算法说明、所属数据域和业务过程。原子指标名称一般采用“动作+度量”方式命名，比如支付金额（pay_amt）、停留时长（stay_time）。
修饰词：修饰词指除统计维度以外的对指标进行限定抽象的业务场景词语，修饰词隶属于一个修饰类型。比如，在日志域的访问终端类型下，有修饰词PC、无线端。修饰类型的出现是为了方便管理、使用修饰词。
1. 时间修饰词：数据统计的时间范围或者时间点，如最近1天、最近1周、截至当天。
2. 其他修饰词：对指标业务场景的限定，如客户等级高、终端为PC。修饰词归属到某个抽象的修饰类型，如客户等级、终端类型。
派生指标：派生指标可以理解为对原子指标业务统计范围的圈定，由原子指标、时间修饰词及其他修饰词组合而成，即派生指标=1个原子指标+多个修饰词+时间周期。派生指标继承了原子指标所在的数据域、数据类型、算法，保障指标的一致性。比如最近1天北京买家支付金额（最近1天是时间周期，北京是修饰词，买家是维度）。
计算方法：指标的数学计算方式，比如汇总、平均、最大、最小等。
一致性指标：指标归属到具体数据域，定义原子指标、修饰词、时间周期和派生指标的含义、命名、类型、计算方法，确保指标的全局一致性。一致性指标设计是为了在企业内外部使指标的命名、计算方法、业务理解达到一致，避免不同部门同一个指标的数据对不上或者对同一个指标的数据理解不一致。
C. 标签数据层建设——数据价值魅力所在（价值点！）
标签数据层是面向对象建模，把一个对象各种标识打通归一，把跨业务板块、数据域的对象数据在同一个粒度基础上组织起来打到对象上。标签数据层建设，一方面让数据变得可阅读、易理解，方便业务使用；另一方面通过标签类目体系将标签组织排布，以一种适用性更好的组织方式来匹配未来变化的业务场景需求。
标签归属到一个对象，标签按照产生和计算方式不同可分为属性标签、统计标签、算法标签。对象本身的性质就是属性标签。对象在业务过程事件中产生原子指标，原子指标与修饰词、计算方法可以组装出统计标签。对象在多个业务过程的规律特征通过一定的计算方法可以计算出算法标签。另外对象在特定的业务过程会与其他对象关联，关联对象的属性也可以作为标签打在主对象上。对象的属性标签、统计标签、算法标签与对象标签类目、对象标识组装起来就生成对象标签表（标签融合表）。对于对象标签表来说一切都是标签，并没有严格的维度与事实的区分。
标签基本概念：
对象：是客观世界中研究目标的抽象，可以是现实存在的，也可以是虚拟的，是具备独立特征的个体，比如自然人、产品、账户等。
对象标识：对象的标识符用以标识一个对象，一般是各种ID，比如手机号、身份证、登录账号。
标签：利用原始数据，通过一定的加工逻辑产出，能够为业务所直接使用的可阅读、易理解、有业务价值的数据。
标签类目：是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找标签，一般采用多级类目。
属性标签：属性是对实体基本性质的刻画，属性的变化非常缓慢，有些甚至永远固定，属性是一类实体区别于另一类实体的差异所在。属性标签是根据人类对实体的长期认知得出的，比如性别、年龄、体重。
统计标签：统计标签是特定场景下，维度和度量的组合。构建出实体所在场景的维度、度量矩阵，就可以根据经验和实际业务需要组装统计标签，比如日均登录次数、最近30天交易额。
算法标签：算法标签是不可以直接获取的，需要通过复杂逻辑分析推理得出，是通过分析对象在多个场景下发生多个事件的规律性得出的相关结论，比如信用指数、购买能力、品牌偏好。
标签融合表：以对象为核心把属性标签、统计标签、算法标签组装起来得到的表，是标签数据层落地的产出物。标签融合表设计要考虑标签的类目结构进行合理组织。
标签建设方法：
1、确定对象（首先要清楚对哪类对象建设标签，画像）
对象是客观世界中研究目标的抽象，有实体的对象，也有虚拟的对象。在企业经营过程中可以抽象出非常多的对象，这些对象在不同业务场景下交叉产生联系，是企业的重要资产，需要全面刻画了解。
经过对多个行业、多个标签体系建设经验的总结，可把对象分为“人”“物”“关系”三大类。其中“人”包括自然人、自然人群体、法人、法人群体等，例如消费者、消费者协会、电商企业、电商企业联合会，这类是可以主动发起行为的主体。“物”包括物品、物体、物品集合等，例如商品、仓库等，是行为中的被施与对象。关系指的是人、物、人和物、人和人、物和物在某时某刻发生的某种行为、关联、关系，包括行为关系、归属关系、思维关系等各种强弱关系，例如购物、运货、聊天、监管等。因此可以采用这种对象识别方法，将现实世界中的一切事物、关系通过这种方式一一对应到相应的对象分类中。
三种对象是不一样的，“人”往往具有主动性和智慧，能主动参与社会活动，主动发挥推动作用，往往是关系的发出者。“物”往往是被动的，包括原料、设备、建筑物、简单操作的工具或功能集合等，是关系的接收者。当常规意义上的设备具有了充分的人工智能，变成了机器人，那么它就属于“人”这一类对象。“人”和“物”是实体类的对象，即看得到、摸得着的对象，而“关系”属于一种虚拟对象，是对两两实物实体间的联系的定义。因为关系很重要，企业大多数情况下反而是在对关系进行定义、反复发生、记录、分析、优化，因此需要“关系”这种对象存在，对关系进行属性描述和研究。关系按照产生的动因不同，又分为事实关系和归属关系，事实关系会产生可量化的事实度量，归属关系只是一种归属属性。
明确了对象的定义和分类，就可以根据业务的需要确定要对哪些对象建立标签体系。企业的对象非常多，不会对所有对象都建立标签体系，一般都是选择典型的对象建立标签体系，比如客户、员工、产品、设备等。一种对象标签体系的建设并不会影响另一种对象标签体系的建设，可以根据资源和业务紧急度，合理安排标签体系建设的前后关系。
2、对象ID打通
在确认对象后，由于存在同一个对象在多个不同业务中的标识ID不同的情况，因此需要将同一个具体对象的不同ID标识打通，以便所有业务数据都能在该对象上打通，完成对该对象的全面数据的刻画。比如一个自然人，他本身由身份证进行唯一识别，但是他看病时用的是医保账号进行挂号缴费；缴纳水电煤费用时，又有不同的水表账号、电表账号、天然气账号；购买了手机又有手机的设备账号；上网购物会有电商账号，上网聊天会有聊天应用账号……通过不同账号，又记录了各自账号下的大量行为记录，如果需要对一个对象进行全面的数据收集、完整刻画、辨别真伪，就需要将多方数据进行融合打通。要完成对象的ID打通，一般会给每个对象设置一个超级ID，比如SUPER-ID作为唯一识别该对象的标识码，业务系统中不同的对象标识ID都通过一定的算法规则与这个SUPER-ID打通，进而完成对象所有业务标识ID的打通。
ID打通，首先必须有ID-ID之间的两两映射打通关系，通过ID-ID之间两两映射关系表，将多种ID之间的关联打通。比如手机号、身份证号码可以打通，手机号、邮箱账号可以打通，这样通过手机号就可以把身份证号码和邮箱账号也打通了。完全孤立的ID是无法进行打通的。通过ID-ID间的两两映射，打通整个ID关系，看似简单，实则计算复杂，计算量非常大。想象一下，假如某种对象有数亿个个体，每个个体又有数十种不同的ID标识，任意两种ID之间都可能有打通关系，想要完成这类对象的所有个体ID打通需要数亿亿次的计算，一般的机器甚至大数据集群都无法完成。大数据领域中的ID-Mapping技术就是用机器学习算法来取代野蛮计算，解决对象数据打通的问题。基于输入的ID关系对，利用机器学习算法做稳定性和收敛性计算，输出关系稳定的ID关系对，并生成一个SUPER-ID作为唯一识别该对象的标识码。
另外要说明的是，通过算法打通对象的不同ID标识，两两之间的打通关系会有置信度，并不是都要100%识别为同一个对象。不同业务根据业务自身的需要，选择不同的置信度，比如要做财务统计，就要100%置信度才行，但是如果是做营销推广，可能80%的置信度就可以了。
一般来说，ID打通是标签体系建设的前提，没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面标签化刻画。
3、标签类目设计（建立对象标签类目体系来进行分类管理）
对象标签体系设计的核心是标签类目设计，标签类目设计完成，整个标签体系的框架就有了，接下来要做的就是往每个叶子类目下填充有业务价值并且可以加工出来的标签，进而完成整个标签体系的设计。
构建标签类目体系首先需要确定根目录，根目录就是对象，因此有三大类根目录：人、物、关系。根目录就像树根一样直接确定这是一棵什么树。如果根目录是人，即这个标签类目体系就是人的标签类目体系，每个根目录都有一个识别列来唯一识别具体对象。根据类似的方式，也可以将物细分为“物品”“物体”“物品集合”“物体集合”等亚类，各亚类下也可以细分根；关系也可以细分“关系记录”“关系集合”。
对根目录展开可以构建多级类目结构：针对“人”“物”“关系”的标签集都可以分别构建出多级的标签类目体系。标签类目体系是对业务所需标签采用类目体系的方法进行设计、归属、分类。类目体系本身是对某一类目标物进行分类、架构组织，分类通常使用一级类目、二级类目、三级类目等作为分类名，将item分入合适的类目中，每个具体的item都是叶节点。
4、标签设计
标签本质上是一种对客观世界中实体对象的度量或描述，是经过缜密的逻辑分析和处理后的产物，用以引导发挥数据应用价值。数据必须转化成能帮助业务提升的标签才具有价值，否则就是数据负累。因此大数据业内一直尝试探索的最核心环节就是数据的商业变现，或者叫数据到商机价值之间的桥梁通道建设。将数据提炼转化为标签的过程就叫标签化，也就是标签设计过程。一个好的标签设计，等于已经完成了好的数据服务50%的工作，标签设计考验的是理解、抽象、提炼、提升业务场景的数据能力。标签设计要充分考虑两大前提条件：有用+可行。
1）标签必须是业务上需要的，能体现业务价值，帮助业务人员做出业务判断或者能创造性的地唤醒新业务场景的数据项，在业务中往往会称其为属性、特征、指标、参数等。
2）必须要探查清楚根据业务需求提炼、整理出的标签是否具有数据可行性，是否有原始数据可以用于加工成标签，不能天马星空，没有落地点。
5、标签融合表设计
1）纵表：类似K-V表，每行表示对象的一个标签，通常的表结构如下：
2）横表：就是普通的二维表，每行表示一个对象，包含对象的多个标签，表结构如下：
推荐使用横表的方式设计标签融合表，以满足性能和易用性的要求。由于标签众多，一般不会用一张标签融合表来存储所有标签，而是通过多张融合表来存储标签。
D. 应用数据层建设——灵活支撑业务需求（灵活+性能）
统一数仓层和标签数据层数据相对稳定，为了解决规范稳定与灵活、高性能之间的矛盾，要增加应用数据层。应用数据层是按照业务使用的需要，组织已经加工好的数据以及一些面向业务的特定个性化指标加工，以满足最终业务应用的场景。
应用数据层类似于传统的数据集市，但是比数据集市更轻量化、更灵活，用于解决特定的业务问题。应用数据层整体而言是构建在统一数仓层与标签数据层之上的简单数据组装层，尽可能复用统一数仓层和标签数据层的建设成果，不像数据集市那样要为某个特定的业务独立构建，应用数据层的构建和完善是从企业级多个类似业务场景来考虑的，同时它又具备数据集市灵活响应业务需求的特点。
应用数据层的建设是强业务驱动的，有以下几种结构：
1）应用场景是多维的即席分析，一般为了减少连接、提升性能，会采用大宽表的形式组织。
2）如果是特定指标查询，可以采用K-V表形式组织，涉及此类表的时候需要深入了解具体的查询场景，例如是否有模糊查询，以便于选择最适合的数据结构。
3）有些场景下搜索多种信息，也可能会用复杂数据结构组织。
比如交叉分析和特定指标查询，所有数据都是数据工程师、算法工程师在数据平台中加工而成的，一般采用分布式离线加工，加工的结果存放在分布式文件中。但是交叉分析和指标查询都需要毫秒级的快速响应，大数据存储层计算环境无法满足这样的低延迟要求，这就需要把加工好的数据同步到可以满足的环境介质中。这里交叉分析一般同步到具备高吞吐、低延迟的即席分析环境，比如Greenplum、Impala；指标查询一般同步到K-V数据库，比如HBase。这样就达到一套数据多套存储，以满足业务对于性能的要求。
Ch8 数据资产管理 解决问题-数据治理
《数据资产管理实践白皮书4.0》：
数据资产定义为：由企业拥有或控制的、能够为企业带来未来经济利益的、以物理或者电子方式记录的数据资源，如文件资料、电子数据等。
数据资产管理的定义为：规划、控制和提供数据及信息资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方法和程序，从而控制、保护、交付和提高数据资产的价值。
数据资产管理的目标：将企业的数据资产统一管理起来，实现数据资产的可见（全面盘点形成数据资产地图，可以快速精确地查找到数据资产）、可懂（通过元数据管理完善对数据资产的描述，指标化、标签化）、可用（通过数据标准、数据质量和数据安全性等措施增强数据的可信度）、可运营（建立一套符合数据驱动的价值评估体系，提升数据资产管理的水平和数据资产的价值）。
数据治理（Data Governance，DG）是指对数据资产管理行使权力和控制的活动集合（规划、监督和执行）。传统的数据治理内容通常包含：数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。
Ch9 数据服务体系建设 解决问题-数据服务
数据服务是对数据进行计算逻辑的封装（过滤查询、多维分析和算法推理等计算逻辑），生成统一资源（数据）标识符（URI），通常提供API服务，让数据快速地应用到业务场景中。主要分为：
基础数据服务：它面向的对象是物理表数据，主要面向的场景包括数据查询、多维分析等，通过自定义SQL的方式实现数据中台全域物理表数据的指标获取和分析。
标签画像服务：它面向的对象是标签数据，主要面向的场景包括标签圈人、画像分析等，通过界面配置方式实现数据中台全域标签数据跨计算、存储的统一查询分析计算，加快数据应用的开发速度。
算法模型服务：它面向的对象是算法模型，主要面向的场景包括智能营销、个性化推荐和金融风控等，主要通过界面配置方式将算法模型一键部署为在线API，支撑智能应用和业务。
4种较为常见的数据服务
1、查询服务的构建过程（非传统的SP写逻辑的构建方式！）
2、分析服务的构建过程
3、推荐服务的构建过程
4、圈人服务的构建过程
Ch10 数据中台运营机制
中台运营团队的使命及目标：数据安全及质量是中台可持续运营的基础；提效降本是打造中台影响力的关键。
数据资产运营的目标：
可阅读：需要有一个资产信息的读取门户或资产地图，在该门户/地图中，业务人员能够直接自己上手操作，通过简单的检索、分类查找、智能推荐等方式便捷地获知数据资产信息，且资产信息必须是以业务人员的阅读习惯呈现；
易理解：将数据资产标签化，标签是面向业务视角的数据组织方式；
好使用：通过数据服务体系可以实现对数据使用方法的抽象，供业务部门理解后直接配置使用，解决了业务人员难以准确描述需求的问题；——非常难，语义断层
有价值：在数据资产的使用过程中应该记录调用信息、效果信息、反馈信息、业务信息等所有可以用来评估资产价值的信息。
数据资产运营的全链路分为看、选、用、治、评5个面向用户使用的运营环节。
业务、产品、研发、数据团队配合：
Ch11 数据安全管理
数据生命周期
数据安全管理体系
6大行业解决方案架构图
地产行业解决方案：
金融行业解决方案：
零售行业解决方案：
制造行业解决方案：
传媒行业解决方案：
检务行业解决方案：
网友评论