首页  思维导图  详情

数据中台培训笔记

2023-02-14 17:28:12   2  举报





AI智能生成

数据中台实战

知识管理

作者其他创作

大纲/内容

数据中台是数据仓库下一站

数据仓库

面向主题的、集成的、反映历史变化的、与时间相关的、不可修改的数据集合（Bill Inmoon）

大数据平台

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

数据产品的出现，提高企业运营效率也面临五大问题

指标口径不一致

原因：业务口径不一致、计算逻辑不一致、数据来源不一
致。

解决办法：就务必确保对同一个指标，只有一个业务口径，只加工一次，数据
来源必须相同。

数据重复建设，需求响应时间长

原因：而数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发，比如同一份原
始数据，两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外
一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。

解决办法：就必须解决数据复用的问题，要确保相同数据只加工一次，
实现数据的共享。

取数效率低

原因：一方面原因是找不到数据，另一方面原因可能是取不到数据。

解决办法：要解决找不到数
据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数
据。而非技术人员并不适合用写 SQL 的方式来取数据，所以要解决取不到数据的问题，就
要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。

数据质量差：数据经常因为 BUG 导致计算结果错误，最终导致错误的商业决策

数据质量差难以被发现，我们经常是等到使用数据的人反馈投诉，才知道数据有问题。而数据的加工链路一般非常长，等到运营投诉再知道数据有问题就太迟

解决办法：要解决数据质量差，就要及时发现然后快速恢复数据问题。

数据成本线性增长。数据成本随着需求的增长而线性增长

原因：数据重复建设

产生五大问题原因

缺少全局指标管理

烟囱式开发导致数据重复建设

找不到数据，SQL不适合非技术人员

数据加工链路长，出现问题很难及时发现

数据重复建设，无用的数据加工，消耗大量资源

数据中台如何解决

确保全局指标业务口径、数据来源、计算逻辑一致

相同聚合粒度的度量、指标只加工一次、避免重复建设

构建企业数据资产目录、提供非技术人员取数工具

全链路稽查监控，早发现，早处理，早回复

计算每个应用、报表、指标的ROI，避免低价值的数据加工

什么样的企业适合建设数据中台

拥有3个以上数据应用场景

存在业务数据孤岛

面临效率、质量和成本问题

需要借助数据质量提高企业经营效率

业务相对稳定的有一定规模的公司

数据中台建设方法论、支撑技术和组织架构

方法论

OneData 一个数据

分主题域管理

命名规范定义

指标一致

数据模型复用

数据完善

OneService一个服务

屏蔽异构数据源

MySQL：数据量小

Hbase：数据量大（超过500W row）

Greenplum 多维分析

Redis 实时要求高

ES:全文索引

数据网关

权限

监控

限流

熔断

逻辑模型

屏蔽底层物理模型设计

性能和稳定性

无状态设计

支撑技术

大数据基础设施

大数据平台

数据治理

元数据中心

数据地图

数仓设计

数据质量

成本优化

指标管理

数据服务

数据应用

组织架构

独立于业务线的中台组织部门

中台团队必须深入业务、懂业务

中台团队的组织架构

数据产品

数据开发

数据平台

数据应用

中台团队的组织必须与业务绑定

元数据中心建设

元数包括内容

数据字典描述的是数据的结构信息

数据血缘

数据血缘是指一个表是直接通过哪些表加工而来，数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天，你的老板看到某个指标的数
据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后
顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。

血缘采集三种方式

通过静态解析 SQL，获得输入表和输出表；面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题

通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；比较理想的方式

通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析
大量的任务日志数据

数据特征

标签

主题域

分层

指标

访问热度

存储空间

业界元数据产品

Metacat 支持多种数据源 Hub设计

Altas 实时数据血缘采集

元数据中心必须实现的关键目标

多租户支持

多数据源支持

数据血缘

实时数据血缘采集

字段血缘

血缘生命周期管理

数据标签

元数据中心必须要支持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征，比如指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。

字段标签

多标签类型

与大数据平台集成

与Ranger结合，实现基于Tag的数据权限

与数据传输、数据治理系统集成

技术实现

数据血缘

通过Hive、Spark Listener、Flink hook获取运行时血缘

血缘按照7天过期，下线任务立即清理血缘

数据字典

元数据管理模块，定义Redis、Kafka、Hbase数据格式

Hub设计

数据特征

标签

API接口

数据地图

元数据中心界面

多维度检索：按照表、列、指标、主题域、分层

表详情：基础信息、字段信息、分区信息、产出信息和数据血缘

如何统一管理杂乱的数据指标

构建全局指标字典

指标口径常见问题

相同指标名称，口径不一致

相同口径,指标名称不一样

不同限定词，,描述相同事实过程的两个指标,相同事实部分口径不一致常见指标问题

指标口径描述不清晰

指标命名难于理解

指标数据来源和计算逻辑不清晰

指标规范化定义

指标归属于业务线、主题域、业务过程

拆分原子指标和派生指标派生指标组成规则

统计周期、统计粒度、业务限定、原子指标，组成派生指标，所以原子指标可以定义为不能够按照上述规则进一步拆分的指标。

指标命名规范

原则：易懂、统一

指标命名：

原子指标(指标名称:动作+度量用户注册数;指标标识:英文简写或汉语拼音）

派生指标(指标名称:时间周期+统计粒度+修饰词+原子指标;指标标识:修饰词原子指标_时间周期的方式)

关联应用和可分析维度

对于使用指标的人（运营、分析师）了解了这个指标的口径定义之后，下一步就是要看指标的数值。所以，在全局的指标字典中，还应该有指标被哪些应用使用，这样方便去对应的数据产品或者报表上查看指标的数值。除此之外，还应该有指标的可分析维度，方便分析师从不同的维度分析指标的变化趋势。

分等级管理

核心指标

核心指标数据中台直接产出的指标和原子指标为核心指标

业务方根据数据中台产出指标派生的指标为非核心指标

一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。

二级指标：基于中台提供的原子指标，业务部门创建的派生指标

管控

一级指标，要确保指标按时、保证质量产出，指标创建由中台负责；

二级指标，允许业务方自己创建，中台不承诺指标的产出时间和质量；

指标系统

基于元数据中心构建,指标以标签形式,下沉到元数据中心对应的表和字段

自动同步元数据中心的主题域和业务过程划分

基于指标规范化定义创建指标

照指标名称、标识、业务口径的检索

基于指标规范化定义创建指标

新的指标开发需求

参与方数据产品经理、分析师、数据开发、应用开发

指标开发流程规范

对已经存在的混乱的指标现状梳理

指标治理小组

指标梳理时间计划

盘点还在使用的数据报表和数据应用

收集使用中的报表和应用的指标

评审指标的业务旦径、对相同的进行去重合并

根据业务口径明确主题域、业务过程

拆分指标类型、录入指标系统

数据模型无法复用，归根结底还是设计问题

如何数据模型设计的好坏

完善度

dwd层跨层引用率：：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例

DWS/ADS/DM 层完善度

汇总数据查询比例：DWS/ADS/DM 层的查询占所有查询的比例

复用度

模型引用系数：一个模型被读取，直接产出下游模型的平均数量

规范度

没有分层信息，没有主题域，业务过程、全量/增量的表表的数量

表命名不规范，主题域、分层、表是全量快照，还是增量等信息。

字段命名不一致的表数量

如何从烟囱式的小数仓到共享的数据中台

接管 ODS 层，控制源头。

数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份，，只有中台团队的账号才能同步数据。ODS 层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于 ODS 层表的命名采用 ODS_ 业务系统数据库名 _ 业务系统数据库表名方式，比如ods_warehous_stock，warehous 是业务系统数据库名，stock 是该库下面的表名。

划分主题域，构建总线矩阵

主题域是业务过程的抽象集合。可能这么讲，稍微有点儿抽象，但其实业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面有入库、出库、发货、签收，都是业务过程，抽象出来的主题域就是仓储域。主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性。（新加入一个主题域，不影响已经划分的主题域的表）。

构建总线矩阵，明确每个主题域下的业务过程有哪些分析维度

构建一致性维度

构建全局一致性的维表，确保维表只存一份

是否所有维度属性都要整合到一个大的维表中？

公共维度属性与特有维度属性拆成两个维表

在自营平台中，通常也会有一些第三方的商家入驻，但是数量很少。大部分商品其实都没有店铺的属性，这种情况，就不建议将店铺和商品的其他维度属性，比如商品类别、品牌设计成一个维表。

产出时间相差较大的维度属性拆分单独的维表

比如有些维度属性产出时间在凌晨 2点，有些维度属性产出时间在凌晨 6 点，那 2 点和 6 点的就可以拆成两个维表，确保核心维表尽早产出

将更新频繁的和变化缓慢的进行拆分

访问频繁的和访问较少的维表进行拆分

维表规范命名

DIM_ 主题域 _ 描述 _ 分表规则”方式。分表你可以这样理解：一个表存储几千亿行记录实在是太大了，所以需要把一个表切割成很多小的分区，每天或者每周，随着任务被调度，会生成一个分区。我提供给你一个常见的分区规则（这个规则你在用的时候，查阅就可以了）

事实表整合

原则：统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。

供应链部门、仓储部门和市场部门都有一些重复的事实表，我们需要将这些重复的内容进行去除，按照交易域和仓储域，主题域的方式进行整合

考虑将不全的数据补齐

对于 ODS 层直接被引用产出 DWS/ADS/DM层的任务，通过血缘，找到任务清单，逐个进行拆解。没有 ODS 对应的 DWD 的，应该生成 DWD 表，对于已经存在的，应该迁移任务，使用 DWD 层表。

模型开发

所有任务都必须严格配置任务依赖，有以下注意点

如果没有配置任务依赖，会导致前一个任务没有正常产出数据的情况下，后一个任务被调度起来，基于错误的数据空跑，浪费资源，同时增加了排查故障的复杂度

任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有大量的临时表存在，占用空间

任务名称最好跟表名一致，方便查找和关联

生命周期的管理，对于 ODS 和 DWD，一般尽可能保留所有历史数据，对于DWS/ADS/DM 需要设置生命周期，7～30 天不等

DWD 层表宜采用压缩的方式存储，可用 lzo 压缩

应用迁移

这个过程的核心是要注意数据的比对，确保数据的完全一致，然后进行应用迁移，删除老的数据表

可视化建模

EasyDesign 构建于元数据中心之上，通过 API 调用元数据中心的数据血缘接口，结合数仓模型设计的指标，给出了模型设计度量

照主题域、业务过程、分层的方式管理所有的模型

提供了维度、度量和字段基础字典的管理，同时具备模型设计审批流程的控制

数据有问题，该怎么彻底解决

数据质量问题的根源

业务源系统变更

源系统数据库表结构变更

源系统环境变更，新增机器，或机器环境变更，导致数据收不到或收不全

源系统日志数据格式异常，前后端埋点日志中。业务系统发布上线引入埋点 BUG，导致 IP 格式出现了不符合约定的格式

数据开发任务变更

这种情况在数据质量事件中占到了 60% 以上，而它大多数是由于数据开发的纰漏引发的，典型例子

任务发布上线，代码中引用的测试库没有修改为线上库，结果污染了线上数据；

任务发布上线，代码中使用了固定分区，没有切换为“${azkaban.flow.1.days.ago}”，导致数据异常

代码忽略了异常，前面数据格式处理错误，导致数据错误

任务配置异常任务没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误

物理资源不足

物理资源不足，导致任务延迟产出，1，大促业务量激增 2.新来开发，代码不好，大量sql嵌套，占用大量资源

基础设施不稳定

这类异常不算多，但影响却是全局性的。hadoop出现系统性Bug

提高数据质量

原则：早发现，早恢复

早发现：先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间

早回复：就是要缩短故障恢复的时间，降低故障对数据产出的影响

稽核校验任务

对产出表按照业务规则，设计校验逻辑，确保数据的完整性、一致性和准确性

数据产出任务运行结束后，启动稽核校验任务，判断是否符合预期

符合进入下一个任务

不符合，如果设置了强规则，则停止任务，如果是若规则，则继续运行下有任务，并报警通知

稽核规则

完整性规则：确保数据记录是完整的不丢失

数据量的绝对值监控和波动率的监控（表波动超过 20%，就认为是异常）

表主键唯一性的监控，判断是否有重复记录

字段级别的监控（比如字段为 0、为 NULL 的记录）

一致性规则：解决相关数据在不同模型中一致性的问题

准确性规则：解决数据记录正确性的问题

一个商品只能归属在一个类目，数据格式是不是正确的 IP 格式，订单的下单日期是还没有发生的日期等等。

组建数据架构师团队，由这个团队负责核心表的规则审核，确保规则的完备性

建立全链路监控

基于数据血缘关系，建立全链路数据质量监控

对链路中每个表增加稽核校验规则之后，当其中任何一个节点产出的数据出现异常时，能够第一时间发现，并立即修复，做到早发现、早修复。另外，即使是使用方反馈经营分析上的黑卡会员购买用户数，相较于昨天数据大幅下降超过 30%，你也可以快速判定整个指标

加工链路上节点是否运行正常，产出任务是否有更新，提高了问题排查速度

智能预警，确保任务按时产出

指标加工链路中的每个任务的产出时间进行监控，基于任务的运行时间和数据血缘，对下游指标产出时间进行实时预测，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些低优先级的任务，确保核心任务按时产出

根据应用的重要性区分数据等级，加快恢复速度

稽核校验会消耗大量的资源，只有核心任务才需要。核心任务的定义是核心应用（使用范围广、使用者管理级别高）数据链路上的所有任务

规范化管理制度

就是规则的完备性如何来保障。在我看来，这不仅仅是一个技术问题，也涉及管理。在网易，我们会制定一些通用的指导规则（比如，所有数据中台维护的表
都需要添加主键唯一性的监控规则），但这些通用规则往往与业务关系不大。如果涉及业务层面，就要由数据架构师牵头，按照主题域、业务过程，对每个表的规则进行评审，决定这些规则够不够

如何衡量数据质量

原则：数据量化

故障数量

基于稽核规则，计算表级别的质量分数。根据表上稽核规则的通过情况，为每个表建立质量分数，对于分数低的表，表负责人要承担改进责任

介入的报警次数，通常以开启循环报警的电话报警次数为准。对于核心任务，任务异常会触发循环电话报警，接到报警的数据开发需要立即介入

数据产品 SLA。每个数据产品上所有指标有没有在 9 点产出，如果没有，开始计算不可用时间，整体可以按照不同数据产品的重要性进行折算，99.8% 是数据产品一个相对比较好的 SLA。

数据质量中心

数据质量中心（以下简称 DQC）的核心功能是稽核校验和基于数据血缘的全链路数据质量监控，一个好用的 DQC，必须要具备的功能就是质量度量、稽核规则管理以及全链路监控

质量大屏，提供了稽核规则的数量、表的覆盖量以及这些规则的执行通过情况。

在 DQC 中创建稽核规则非常简单，DQC 内置了大量的基础规则，例如 IP 字段格式校验，主键唯一性校验，表行数波动率校验，同时还提供了自定义 SQL 的方式，允许业务层面的规则创建，例如我们前面提到的一致性规则中，两个指标相除等于第三个指标，就可以通过自定义 SQL 解决。

DQC 还提供了全链路监控的功能，覆盖了从数据导入、数据加工、模型产出、指标、到数据应用的完整链路。绿色节点代表数据正常，蓝色节点代表数据正在产出中，红色节点代表数据异常，灰色节点代表产出任务还未被调度到。通过这个监控，大幅提高了问题发现和定位的速度

如何有效降低成本

常见8中成本陷阱，1~3 是广泛存在，容易被忽略的；4~8 涉及数据开发中一些技能，开发时候需要注意。

数据上线容易下线难

有一半的表在 30 天内都没有访问，而这些表占用了 26% 的存储空间对于无法及时清理数据，数据开发其实也有苦衷。他们并不知道一个表还有哪些任务在引用，还有哪些人在查询，自然不敢停止这个表的数据加工，那造成的后果就是数据上线容易，下线难

低价值的数据应用消耗了大量的资源

数据部门比较关注新的数据产品带给业务的价值，却忽略了已经存在的产品或者报表是否还存在价值，最终导致低价值的应用仍然在大量消耗资源。比如一张大宽表仅提供给一个运营部实习生使用

烟囱式的开发模式，表无法复用

数据倾斜，数据倾斜会让任务性能变差，也会浪费大量的资源

数据未设置生命周期

一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。如果存在大表没有设置生命周期，就会浪费存储资源

调度周期不合理，把一些不必要在高峰期内运行任务迁移到低谷期运行，也可以节省资源的消耗

任务参数配置任务参数配置的不合理，往往也会浪费资源。比如在 Spark 中，Executor 内存设置的过大；CPU 设置的过多；Spark 没有开启动态资源分配策略，一些已经运行完 Task 的Executor 不能释放，持续占用资源，尤其是遇到数据倾斜的情况，资源浪费会更加明显

数据未压缩

HDFS三副本，原始数据层和明细数据层的大表，不启用压缩，存储资源成本会很高

在 Hive 或者 Spark 计算过程中，中间结果也需要压缩，可以降低网络传输量，提高 Shuffer性能

如何实现精细化成本管理

成本治理应该遵循全局盘点、发现问题、治理优化和效果评估四个步骤

全局资产盘点

对数据中台中，所有的数据进行一次全面盘点，基于元数据中心提供的数据血缘，建立全链路的数据资产视图

计算末端数据的成本和价值

为什么从末端计算？因为中间数据，在计算价值的时候，还要考虑下游表被使用的情况，比较难计算清楚，所以我们选择从末端数据开始。这与我们下线表的顺序也是一致的，如果数据的价值很低，成本很高，我们也是从末端数据开始下线的

核算数据成本

全链路数据资产视图的下游末端关联到了数据应用（报表：财务分析），而上游的起点是刚进入数据中台的原始数据。数据之间通过任务进行连接。

我们要对上图中财务分析报表核算成本，这个报表上游链路中涉及到 a，b，c，3 个任务，A，B，C，D，E，F， 6 张表，那么

末端数据价值

如果末端数据是一张应用层的表，它对接的是一个数据报表，那衡量这个数据的价值，主要

是看报表的使用范围和使用频率。在计算使用范围时，通常用周活来评估，同时还要考虑不

同管理级别的人权重，对于老板，他一个人的权重可以相当于 1000 个普通员工。

发现问题

持续产生成本，没有使用的末端数据一般指 30 天内没有访问，陷阱1

成本很高，业务价值很低的末端数据，陷阱 2

高峰期高消耗的数据，陷阱 4～8

治理优化

无用末端数据下线

数据下线策略

产出任务停止调度

数据备份到冷备集群

线上数据清理

数据服务

数据服务到底解决了什么问题

数据接入效率低

数据存储在mysql、es、hbase上，不同的中间存储，涉及的访问 API 也不一样

数据服务，为应用开发使用统一的 API 接口访问数据，大幅度提高了数据应用的研发效率

数据和接口没办法复用

中间存储中的数据没办法复用

API接口也高度定制化，没办法复用

数据服务暴露的是接口而不是数据

数据服务具备限流功能是的不同应用共享数据成为可能

不知道数据被哪些应用访问

数据和应用的链路关系是断的

数据出问题，不知道影响到哪个应用，无法优先恢复

下线数据，不知道下游还有没有应用访问

数据服务打通了数据和应用的访问链路，建立了从数据应用到数据中台数据的全链路数据血缘关系

数据部门字段变更导致应用变更

汇总层模型根据需求不断优化是经常的事情

汇总层变更，应用开发需要跟着变更

数据服务解耦了数据应用和数据，修改数据服务的映射关系即可实现字段变更

数据服务应该具备什么功能

接口规范化定义

就是取快递时我们约定的取件码。数据服务，对各个数据应用屏蔽了不同的中间存储，提供的是统一的 API。

数据网关

数据服务必须要具备认证、权限、限流、监控四大功能，数据服务还要提供接口相关的监控，比如接口的 90% 的请求响应时间、接口调用次
数、失败次数等相关的监控，另外，对于长时间没有调用的 API ，应该予以下线。这样做

的好处是防止没用的接口额外占用资源

全链路打通

数据服务还必须负责维护数据模型到数据应用的链路关系，将数据应用信息一标签信息，同步到元数据中心

构建 API 集市，实现接口复用

构建 API 的集市，应用开发者可以直接在 API 集市发现已有的数据接口，直接申请该接口的 API 权限，即可访问该数据，不需要重复开发，数据服务通过元数据中心，可以获得接口访问的表关联了哪些指标。使用者可以基于指标的组合，筛选接口，这样就可以根据想要的数据，查找可以提供这些数据的接口，形成了一个闭环。

逻辑模型，实现数据的复用

在数据服务中定义逻辑模型，然后基于逻辑模型发布 API，逻辑模型的背后实际是多个物理表，从用户的视角，一个接口就可以访问多张不同的物理表了。

利用中间存储，加速数据查询

将hive表数据加载到不同中间存储，加速查询速度

推和拉的数据交付方式

数据服务都是以 API 接口的形式对外提供服务，但是业务实际场景中，光API 还不够的。我把 API 方式称为拉的方式，而实际业务中同样还需要推的场景，在实时直播场景中，商家需要第一时间获得关于活动的销售数据，此时就需要数据服务具备推的能力，我把它称为数据的送货上门服务。数据服务将数据实时写入到一个 Kafka

中，然后应用通过订阅 Kafka 的 Topic，可以获得实时数据的推送

数据服务系统架构设计

云原生

云原生的核心优势在于每个服务至少有两个副本，实现了服务的高可用，同时根据访问量大小，服务的副本数量可以动态调整，基于服务发现，可以实现对客户端透明的弹性伸缩。服务之间基于容器实现了资源隔离，避免了服务之间的相互影响。这些特性非常适用于提供高并发、低延迟，在线数据查询的数据服务

逻辑模型

相较于物理模型，逻辑模型并没有保存实际的数据，而只是包括了逻辑模型和物理模型的映射关系，数据在每次查询时动态生成。逻辑模型的设计，解决了不同接口，对于同一份数据，需要只看到自己需要的数据的需求接口发布者在数据服务中选择主键相同的多张物理表构建一个逻辑模型，然后基于逻辑模型发布接口。API 服务接到查询请求后，根据逻辑模型和物理模型字段的映射关系，将逻辑执行计划拆解为面向物理模型的物理执行计划，并下发多个物理模型上去执行，最后对执行的结果进行聚合，返回给客户端。

数据自动导出

数据服务选择的是数据中台的一张表，然后将数据导出到中间存储中，对外提供 API 。那数据什么时候导出到中间存储中呢？要等数据产出完成。
所以在用户选择了一张数据中台的表，定义好表的中间存储后，数据服务会自动生成一个数据导出任务，同时建立到这个数据中台表的产出任务的依赖关系，等到每次调度产出任务结束，就会触发数据导出服务，将数据导出到中间存储中，此时 API 接口就可以查询到最新的数据

数据安全

数据备份与恢复

垃圾回收箱设计

HDFS 一旦开启垃圾回收功能后，用户通过命令行执行 rm 文件操作的时候，HDFS 会将文件移到 /user/[用户名]/.trash/current/ 目录下。这个目录下的文件会在fs.trash.interval 配置的时间过期后被系统自动删除。当你需要恢复文件的时候，只需要把/user/[用户名]/.trash/current/ 被删除文件移到要恢复的目录即可。因为它只能支持通过命令行执行 rm 操作，对于在代码中通过 HDFS API 调用 Delete 接口时，会直接删除文件，垃圾回收机制并不生效。尤其是我们在 Hive 中执行 drop table 删除一个 Hive 内表，此时删除的数据文件并不会进入 trash目录，会存在巨大的安全隐患。

精细化的权限管理

数据应用

数据应用的三阶段理论

初级阶段-BI报表

发展阶段-数据产品

只是可视化的展现数据已经不能满足业务的需求，业务需要根据数据持续监控业务过程，发现问题、诊断分析，并给出决策建议，最后需要一键执行，形成完成的业务过程闭环。

高级阶段-自助取数

数据报表、数据产品，呈现的都是固化的分析思路，只能解决知道的业务问题，但是日常工作还有很多未知的业务问题，比如销售额指标突然下降了，需要基于数据进行探索分析。这个时候，如果都依赖分析师，肯定不现实，那么就要实现自助取数

数据中台对BI赋能

统一报表指标业务口径

掌握任务影响了哪些数据报表

报表治理

治理低价值的数据报表

增强分析

在制作报表时，分析师只能依靠经验去判断一个指标有哪些可分析维度。如果 BI 工具能根据元数据中心提供的所有指标可分析维度，自动根据指标在各个维度下的取值，找出指标波动的原因，那这就是全维度钻取了，它是目前业界最为热门的研究领域，增强分析的一个方向。

打造零售行业精益数据运营体系

让更多人买更多奶茶

拉新

基于数据评估广告渠道的效果

基于数据计算人群画像、推正确的商品给正确的人

指标：新消费用户数，新消单客成本，新消APRU

促活

基于数据计算用户喜欢的奶茶类型、门店，门店定向推送折扣信息

管好奶茶

供应链-基于数据，精准预测销量，自动生成采购计划

滞销商品监控-基于数据分析原因，及时干预

构建数据产品，实现数据驱动下的精益运营

量化目标、持续监控、诊断分析、决策建议、一键执行

自助取数

BI 部门一般有两项职责，一个是做报表，一个是取数。而取数的工作量远远多于报表的工作量。一年中做的报表可能就几百张，但是取数，一年可能要取几千次，或者上万次。而大部分传统企业的取数会依赖技术人员，因为他们离数据更近，取数还涉及写代码，所以，如果你是非技术人员，根本不可能基于数据去做探索式的分析。所以，大量的取数工作就落在了懂技术的数据开发的头上。

建立标准的数据研发流程

需求分析

工具：指标系统

涉及角色：数据产品、数据开发、应用开发、数据分析师

产出：指标业务口径、计算逻辑、数据来源

核心：指标规范化定义

研发阶段

设计阶段

工具：模型设计中心

涉及角色：数据架构师、数据开发

产出：模型设计

核心：基于主题域分层的维度模型