数据中台实战课-（ 郭忆）笔记
2022-11-14 17:26:46 4 举报AI智能生成
大数据中台很清晰的思维导图，是实战的总结，不仅仅是理论
作者其他创作
大纲/内容
面向主题的、集成的、反映历史变化的、与时间相关的、不可修改的数据集合（Bill Inmoon）
数据仓库
大数据平台
数据中台是数据仓库下一站
解决办法：就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。
原因：业务口径不一致、计算逻辑不一致、数据来源不一致。
指标口径不一致
解决办法：就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。
原因：而数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发，比如同一份原始数据，两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。
数据重复建设，需求响应时间长
解决办法：要解决找不到数据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据。而非技术人员并不适合用写 SQL 的方式来取数据，所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。
原因：一方面原因是找不到数据，另一方面原因可能是取不到数据。
取数效率低
解决办法：要解决数据质量差，就要及时发现然后快速恢复数据问题。
数据质量差难以被发现，我们经常是等到使用数据的人反馈投诉，才知道数据有问题。而数据的加工链路一般非常长，等到运营投诉再知道数据有问题就太迟
数据质量差：数据经常因为 BUG 导致计算结果错误，最终导致错误的商业决策
原因：数据重复建设
数据成本线性增长。数据成本随着需求的增长而线性增长
数据产品的出现，提高企业运营效率也面临五大问题
缺少全局指标管理
烟囱式开发导致数据重复建设
找不到数据，SQL不适合非技术人员
数据加工链路长，出现问题很难及时发现
数据重复建设，无用的数据加工，消耗大量资源
产生五大问题原因
确保全局指标业务口径、数据来源、计算逻辑一致
相同聚合粒度的度量、指标只加工一次、避免重复建设
构建企业数据资产目录、提供非技术人员取数工具
全链路稽查监控，早发现，早处理，早回复
计算每个应用、报表、指标的ROI，避免低价值的数据加工
数据中台如何解决
拥有3个以上数据应用场景
存在业务数据孤岛
面临效率、质量和成本问题
需要借助数据质量提高企业经营效率
业务相对稳定的有一定规模的公司
什么样的企业适合建设数据中台
什么样的企业需要建数据中台
分主题域管理
命名规范定义
指标一致
数据模型复用
数据完善
OneData
MySQL：数据量小
Hbase：数据量大（超过500W row）
Greenplum 多维分析
Redis 实时要求高
ES:全文索引
屏蔽异构数据源
权限
监控
限流
熔断
数据网关
屏蔽底层物理模型设计
逻辑模型
无状态设计
性能和稳定性
OneService
方法论
大数据基础设施
元数据中心
数据地图
数仓设计
数据质量
成本优化
指标管理
数据治理
数据服务
数据应用
支撑技术
独立于业务线的中台组织部门
中台团队必须深入业务、懂业务
数据产品
数据开发
数据平台
中台团队的组织架构
中台团队的组织必须与业务绑定
组织架构
数据中台建设方法论、支撑技术和组织架构
数据字典 描述的是数据的结构信息
数据血缘是指一个表是直接通过哪些表加工而来，数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。
通过静态解析 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_warehous_stock，warehous 是业务系统数据库名，stock 是该库下面的表名。
接管 ODS 层，控制源头。
主题域是业务过程的抽象集合。可能这么讲，稍微有点儿抽象，但其实业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面有入库、出库、发货、签收，都是业务过程，抽象出来的主题域就是仓储域。主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性。（新加入一个主题域，不影响已经划分的主题域的表）。
构建总线矩阵，明确每个主题域下的业务过程有哪些分析维度
划分主题域，构建总线矩阵
构建全局一致性的维表，确保维表只存一份
在自营平台中，通常也会有一些第三方的商家入驻，但是数量很少。大部分商品其实都没有店铺的属性，这种情况，就不建议将店铺和商品的其他维度属性，比如商品类别、品牌设计成一个维表。
公共维度属性与特有维度属性拆成两个维表
比如有些维度属性产出时间在凌晨 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 格式出现了不符合约定的格式
业务源系统变更
任务发布上线，代码中引用的测试库没有修改为线上库，结果污染了线上数据；
任务发布上线，代码中使用了固定分区，没有切换为“${azkaban.flow.1.days.ago}”，导致数据异常
代码忽略了异常，前面数据格式处理错误，导致数据错误
任务配置异常任务没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误
这种情况在数据质量事件中占到了 60% 以上，而它大多数是由于数据开发的纰漏引发的，典型例子
数据开发任务变更
物理资源不足，导致任务延迟产出，1，大促业务量激增 2.新来开发，代码不好，大量sql嵌套，占用大量资源
物理资源不足
这类异常不算多，但影响却是全局性的。hadoop出现系统性Bug
基础设施不稳定
数据质量问题的根源
早发现：先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间
早回复：就是要缩短故障恢复的时间，降低故障对数据产出的影响
原则：早发现，早恢复
对产出表按照业务规则，设计校验逻辑，确保数据的完整性、一致性和准确性
符合进入下一个任务
不符合，如果设置了强规则，则停止任务，如果是若规则，则继续运行下有任务，并报警通知
数据产出任务运行结束后，启动稽核校验任务，判断是否符合预期
数据量的绝对值监控和波动率的监控（表波动超过 20%，就认为是异常）
表主键唯一性的监控，判断是否有重复记录
字段级别的监控（比如字段为 0、为 NULL 的记录）
完整性规则：确保数据记录是完整的不丢失
一致性规则：解决相关数据在不同模型中一致性的问题
一个商品只能归属在一个类目，数据格式是不是正确的 IP 格式，订单的下单日期是还没有发生的日期等等。
准确性规则：解决数据记录正确性的问题
稽核规则
组建数据架构师团队，由这个团队负责核心表的规则审核，确保规则的完备性
稽核校验任务
基于数据血缘关系，建立全链路数据质量监控
对链路中每个表增加稽核校验规则之后，当其中任何一个节点产出的数据出现异常时，能够第一时间发现，并立即修复，做到早发现、早修复。另外，即使是使用方反馈经营分析上的黑卡会员购买用户数，相较于昨天数据大幅下降超过 30%，你也可以快速判定整个指标加工链路上节点是否运行正常，产出任务是否有更新，提高了问题排查速度
建立全链路监控
指标加工链路中的每个任务的产出时间进行监控，基于任务的运行时间和数据血缘，对下游指标产出时间进行实时预测，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些低优先级的任务，确保核心任务按时产出
智能预警，确保任务按时产出
稽核校验会消耗大量的资源，只有核心任务才需要。核心任务的定义是核心应用（使用范围广、使用者管理级别高）数据链路上的所有任务
根据应用的重要性区分数据等级，加快恢复速度
提高数据质量
就是规则的完备性如何来保障。在我看来，这不仅仅是一个技术问题，也涉及管理。在网易，我们会制定一些通用的指导规则（比如，所有数据中台维护的表都需要添加主键唯一性的监控规则），但这些通用规则往往与业务关系不大。如果涉及业务层面，就要由数据架构师牵头，按照主题域、业务过程，对每个表的规则进行评审，决定这些规则够不够
规范化管理制度
原则：数据量化
故障数量
基于稽核规则，计算表级别的质量分数。根据表上稽核规则的通过情况，为每个表建立质量分数，对于分数低的表，表负责人要承担改进责任
介入的报警次数，通常以开启循环报警的电话报警次数为准。对于核心任务，任务异常会触发循环电话报警，接到报警的数据开发需要立即介入
数据产品 SLA。每个数据产品上所有指标有没有在 9 点产出，如果没有，开始计算不可用时间，整体可以按照不同数据产品的重要性进行折算，99.8% 是数据产品一个相对比较好的 SLA。
如何衡量数据质量
质量大屏，提供了稽核规则的数量、表的覆盖量以及这些规则的执行通过情况。
在 DQC 中创建稽核规则非常简单，DQC 内置了大量的基础规则，例如 IP 字段格式校验，主键唯一性校验，表行数波动率校验，同时还提供了自定义 SQL 的方式，允许业务层面的规则创建，例如我们前面提到的一致性规则中，两个指标相除等于第三个指标，就可以通过自定义 SQL 解决。
DQC 还提供了全链路监控的功能，覆盖了从数据导入、数据加工、模型产出、指标、到数据应用的完整链路。绿色节点代表数据正常，蓝色节点代表数据正在产出中，红色节点代表数据异常，灰色节点代表产出任务还未被调度到。通过这个监控，大幅提高了问题发现和定位的速度
数据质量中心（以下简称 DQC）的核心功能是稽核校验和基于数据血缘的全链路数据质量监控，一个好用的 DQC， 必须要具备的功能就是质量度量、稽核规则管理以及全链路监控
数据质量中心
数据有问题，该怎么彻底解决
有一半的表在 30 天内都没有访问，而这些表占用了 26% 的存储空间对于无法及时清理数据，数据开发其实也有苦衷。他们并不知道一个表还有哪些任务在引用，还有哪些人在查询，自然不敢停止这个表的数据加工，那造成的后果就是数据上线容易，下线难
数据上线容易下线难
数据部门比较关注新的数据产品带给业务的价值，却忽略了已经存在的产品或者报表是否还存在价值，最终导致低价值的应用仍然在大量消耗资源。比如一张大宽表仅提供给一个运营部实习生使用
低价值的数据应用消耗了大量的资源
烟囱式的开发模式，表无法复用
数据倾斜，数据倾斜会让任务性能变差，也会浪费大量的资源
一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。如果存在大表没有设置生命周期，就会浪费存储资源
数据未设置生命周期
调度周期不合理，把一些不必要在高峰期内运行任务迁移到低谷期运行，也可以节省资源的消耗
任务参数配置任务参数配置的不合理，往往也会浪费资源。比如在 Spark 中，Executor 内存设置的过大；CPU 设置的过多；Spark 没有开启动态资源分配策略，一些已经运行完 Task 的Executor 不能释放，持续占用资源，尤其是遇到数据倾斜的情况，资源浪费会更加明显
HDFS三副本，原始数据层和明细数据层的大表，不启用压缩，存储资源成本会很高
在 Hive 或者 Spark 计算过程中，中间结果也需要压缩，可以降低网络传输量，提高 Shuffer性能
数据未压缩
常见8中成本陷阱，1~3 是广泛存在，容易被忽略的；4~8 涉及数据开发中一些技能，开发时候需要注意。
成本治理应该遵循全局盘点、发现问题、治理优化和效果评估四个步骤
对数据中台中，所有的数据进行一次全面盘点，基于元数据中心提供的数据血缘，建立全链路的数据资产视图
为什么从末端计算？因为中间数据，在计算价值的时候，还要考虑下游表被使用的情况，比较难计算清楚，所以我们选择从末端数据开始。这与我们下线表的顺序也是一致的，如果数据的价值很低，成本很高，我们也是从末端数据开始下线的
我们要对上图中财务分析报表核算成本，这个报表上游链路中涉及到 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 部门一般有两项职责，一个是做报表，一个是取数。而取数的工作量远远多于报表的工作量。一年中做的报表可能就几百张，但是取数，一年可能要取几千次，或者上万次。而大部分传统企业的取数会依赖技术人员，因为他们离数据更近，取数还涉及写代码，所以，如果你是非技术人员，根本不可能基于数据去做探索式的分析。所以，大量的取数工作就落在了懂技术的数据开发的头上。
自助取数
工具：指标系统
涉及角色：数据产品、数据开发、应用开发、数据分析师
产出：指标业务口径、计算逻辑、数据来源
核心：指标规范化定义
需求分析
工具：模型设计中心
涉及角色：数据架构师、数据开发
产出：模型设计
核心：基于主题域分层的维度模型
设计阶段
工具:数据集成、离线/实时数据开发、数据测试，数据治理中心
涉及角色：数据开发
产出：任务
核心：先设计后开发
开发阶段
研发阶段
工具：数据服务
涉及角色：应用开发、数据开发
产出：API接口
核心：数据抽取到中间存储、发布API接口
交付阶段
工具：任务运维中心
产出：任务稳定运行
核心：早发现、早恢复
运维阶段
建立标准的数据研发流程
数据分析过程划分五个步骤
数据协作流程
数据中台实践
数据中台实战
0 条评论
回复 删除
下一页
