数仓相关汇总

1. 数据仓库的意义

• 空间换时间
  • 通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
• 屏蔽原始数据的异常
• 清晰数据结构
  • 每一个数据分层都有它的作用域和职责,在使用表的时候能更方便的定位和理解
• 复杂问题简单化
  • 将一个复杂的任务拆分成多个步骤来完成,每一层解决特定的问题
• 数据血缘追踪
  • 便与排查问题以及确定影响范围
• 减少重复开发
  • 开发一些通用的中间层数据,能够减少极大的重复计算

2. 数据仓库的文档产出

• 构建数据仓库本身需要的文档
  • 数据平台安装部署文档
  • 数据仓库规范文档
    • 定义任务、表、指标命名规范
    • 数据质量规范
    • 告警规范
  • 模型文档（主题、表、说明）
    • 定义有哪些主题
    • 核心业务过程
    • 核心表
  • 元数据相关文档
    • 逻辑关系映射文档
    • 指标口径文档
• 数仓开发数据产品需要的文档
  • 需求文档
    • PRD/MRD
  • 数据探查文档
  • 技术方案
    • 排期
    • 模型
    • 口径
    • 兜底方案等
  • 指标口径文档
  • 接口/前后端对接文档

3. 数据仓库的工作

• 面向基础：自下而上。数仓建设，基础数仓的打磨

  • 系统是怎么流转的，业务过程/指标是否全，数据从业务系统来。
  • 有底线，从合理的角度出发，如果做不了应该取推动上游处理，尽量减少数仓兜底

• 面向应用：自上而下。从需求出发，面向业务项目，需要项目拆解能力模型能力。

  • 一般的流程 收集数据诉求（@数据产品）；项目数据拆解（@数仓），做好数据探查/是否合理/是否可以补充；统一口径（分析师通常会先行@分析师@业务方@数仓@数据产品）

4. 数仓如何快速入手

• 了解业务
  • 咨询老员工或者业务同学
  • 查看沉淀的文档
  • 知道大致的业务方向&核心功能
• 了解模型
  • 找到常用的核心dw表&dim表（一般情况下下游依赖比较多）
• 了解数据产品
  • 针对这些重要的数据应用/数据产品的计算链路梳理
• 了解技术架构
  • 同步工具/策略
  • 数据质量管理
  • 元数据管理
  • 血缘
  • olap引擎等

5. 怎么数据探查

• 1.确定业务口径，和对应的表以及字段关系
• 2.基于1确定当前数据是否满足业务口径需求
• 3.同时考虑数据的质量问题

6. 数仓建模的意义

• 如何将数据有序、有结构地分类组织和存储是数据建设者面临的一个挑战，如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置。
• 模型是映射 “事实” 的东西，构建这个东西的动作就叫做建模。
• 数据模型就是数据组织和存储的方法，合适的数据模型能获得以下好处：
  • 性能 :良好的数据模型能帮助我们快速查询所需要的数据，减少数据的 I/O吞吐。
  • 成本 : 良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
  • 效率 :良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
  • 质量 : 良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。
• 因此，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

7. 如何评价一个好数仓

• 数据质量高
• 数据产出，稳定有保障
• 数据构成清晰透明，分层明确
• 能创造价值

8. 如何评价一个模型的好坏

• 如何判断一个数据模型的好坏？数据仓库的 KPI 怎么定？

• 如何评价数据模型的好坏？

• 数仓深度 | 数据模型设计
  

• 高内聚-低耦合：各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务指标，造成模型主题不清晰和性价比低。

  • 将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：将高概率同时访问的数据放一起 ，将低概率同时访问的数据分开存储。
  • 各主题内数据模型要业务高内聚，避免在一个模型耦合其他业务的指标，造成该模型主题不清晰和性价比低。

• 业务过程清晰，易理解。

  • ODS就是原始信息，不修改；
  • DWD面向基础业务过程；
  • DIM描述维度信息；
  • DWS针对最小场景做指标计算；
  • ADS也要分层，面向跨域的建设，和面向应用的建设；

• 命名清晰、可理解

  • 表命名需清晰、一致，表名需易于使用方理解。

• 核心模型相对稳定，与扩展模型分离

  • 一些重要的数据作为核心模型
    • 考虑产出的时效性
    • 不是很边缘的业务数据是否影响核心模型

• 公共逻辑下沉

  • 出现相同逻辑的可以在dwd或者中间层收口
  • 万一口径发生变化，只需要在最底层修改逻辑，上层只需要回溯验证数据即可，而不是说到处修改用到的地方，提高模型的复用性和易用性。

• 成本与性能平衡

  • 适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
  • 产出时效性

• 数据可回滚

  • 不改变处理逻辑，不修改代码的情况下重跑任务结果不变。

9. 如何模型优化

• 合并
  • 存在相似的业务流程，有一些小模型
  • 在不破坏核心模型的简洁性和产出时效时，考虑进行合并，减少对这些不是很边缘业务的关联
• 拆分
  • 影响到核心模型的产出时效、维护难、可读性差
  • eg：用户购物这个业务过程，和订单和商品的一些信息放在一起

10. 数据仓库的 KPI 怎么定？

• 数据最终是要服务于业务的，简单地讲，数据仓库要做的是提高数据能力、提高数据分析效率、提高数据质量的。
• 定 KPI 在某种程度上也可以理解为工作的评价标准。对于数据建设来讲，我们可以从工作内容是否可量化的角度来考虑。
• 不可量化/不易量化（更多的像是品牌影响力，不容易体现具体的工作产出）
  • 比如说需要写多少和数据仓库设计相关的文档
  • 有哪些业务相关的表将会按照你的设计来开发
  • 优化了多少数据分析的流程
• 可量化（比如说中间表对业务方的支持情况，解决了多少业务的痛点，提高了多少的数据质量等等。）
  • 将要解决哪些业务问题（多少业务、多少报表用了你的中间表）
  • 将会替换多少原始表的使用频率（比如数据分析查询你的表的次数，以前都是查原始日志的）
  • 将要解决了多少数据口径不一致，数据质量的问题（可以加上告警，统计出来提前发现了多少数据问题）
• 举例
  • 完成数据仓库的设计，包括主题设计、数据分层和表字段命名等内容，完成10篇以上 Wiki
    • 已完成数据仓库设计相关文档的编写，总计25篇 Wiki，总阅读量10w。
  • 完成店铺主题相关的中间表的设计和开发，满足90%的数据分析需求。
    • 已完成店铺主题相关的中间表的设计和开发，共计15张中间表，日均访问次数400次，占店铺主题相关总任务数的98%。
  • 完成基本的数据监控功能，能够监控关键数据的数据迟到、掉零、环比等内容。
    • 完成基本的数据监控功能，共计监控380张业务表，提前发现了14起数据异常。

11. 为什么要分层

• 假如数据不分层,那么可能数据体系依赖复杂,层级混乱

12. 分层的好处

• 用空间换时间
  • 通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
• 清晰数据结构
  • 每一个数据分层都有它的作用域和职责,在使用表的时候能更方便的定位和理解
• 减少重复开发
  • 开发一些通用的中间层数据,能够减少极大的重复计算
• 统一数据口径
  • 提供统一的数据出口,统一对外输出的数据口径
• 复杂问题简单化
  • 将一个复杂的任务拆分成多个步骤来完成,每一层解决特定的问题

13.数据模型的分层

ods

• 贴源层
  • 放的数据就是没有做任何修改的
  • 直接对接外围系统,不对外开放,为临时存储层,为后一步的数据处理做准备

dw

• 数据仓库层,又称为细节层,一致,准确,干净
• dwd明细层
  • 数据清洗和转换
  • 将数据更细粒度保存
  • 更贴近业务，尽量少特殊判断，根据主题域划分
  • 以还原业务过程，原子性，主题清晰，适量的维度退化拉宽（减少过多关联）
• dwm中间层
  • 轻度汇总
    • 一般是对多个维度的聚合数据（减少运算量）
  • 指标收口
    • 二义性融合 （减少维护量）
  • 期望是能分泳道的，不过早冗余其他主题
• dws业务层
  • follow 某个实体/业务方
  • 根据不同主题形成宽表
    • 存储宽表数据,针对某个业务领域的聚合数据
  • 在这一层将所有业务相关的数据统一汇集起来进行存储,可以将dwm层数据拼接得到,但是宽窄难以界定,因此也可以去掉dwm层,只保留dws层

ads

• 数据应用层
  • 业务个性化数据,服务于特定场景,复用性不强
  • 前端应用直接读取的数据,根据报表 、专题的需求而计算生成的数据

维表层

• 高基数维度数据
  • 一般是用户资料表、商品资料表等,数据量可能千万级或上亿级
• 低基数维度数据
  • 一般是配置表,比如枚举值对应的中文含义、日期维度表
    

实例：电商网站的数据体系设计

• 这里针对用户访问日志这一部分数据进行举例说明:
• 在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。
• 为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。
• 在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表
• 然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。
• 最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。
  
  
  

14. 业务过程是什么

• 业务过程可以是单个业务事件，比如交易的支付、退款等；
• 也可以是某个事件的状态，比如当前的账户余额等；
• 还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
• 如果还不是太理解，可以想象一个日常便利店消费的场景，（用户手机付款，选择支付宝和微信）这些操作算不算业务过程？
  • 有 2 个参与方：消费者和便利店。
  • 便利店作为企业，如果它关心的结果只是消费者买了什么，买了多少，那消费者选择支付方式的事件，它完全不管，也不用记录。
  • 但如果用户只开通了微信支付，没开通支付宝，因为支付问题导致没法成交，那企业肯定也会关心选择支付方式这个事件以及其结果。业务过程，是不可拆分的事件，而且是基于分析目标进行选定的。

15. 维度划分的依据及维度建模的 4 步

• 结合业务,从什么角度分析,比如商品表的维度通常包含食品,饮料,非消费品等若干层次结构
• 建模前需要确定，是否是通用指标，数仓是否已经沉淀该指标
  • a.选择业务过程
    • 例如订单业务过程、下单、支付、发货等业务过程
  • b.声明粒度
    • 应该尽量选择最细级别的粒度，以确保事实表的应用具有最大的灵活性。例如订单id
    • 我们要预判所有分析需要细分的程度，从而决定选择的粒度。
    • 粒度是维度的一个组合。
  • c.确认维度（描述事实的信息，进行分析的角度，也是sql里面的当作维度使用的信息）
    • 例如买家、卖家、商品名称、商品类目、发货地区、收货地区、订单时间等维度。
  • d.确认事实。
    • 如，在下单业务过程中，需要包含商品ID、商品价格、购买数量。在支付业务过程中，需要包含支付金额、红包金额、积分金额。在收货业务过程中，需要包含确认收货金额等。
  • 确定原子指标（一般为可累加的度量值）
    • 原子指标=业务过程（动作）+度量，如支付（事件）金额（度量）。
  • 确定派生指标（维度信息+原子指标+日期信息）
    • 派生指标=原子指标+业务限定【做筛选】+统计周期+维度的组合（统计粒度）

16. 为保证数据质量，你们做了哪些事情

• 事前（数据探查&评审&校验）
  • 模型表上线前一系列的校验
    • 主键唯一性校验
    • 空值率
    • 部分度量值是否超出正常业务范围
    • 大概数据量
    • 核心指标一致性对比
• 事中（监控&告警）
  • 主键唯一性监控
  • 指标波动范围监控
  • 核心指标一致性监控
  • 任务报错/延迟告警（电话/短信/企微等）
• 事后（复盘）
  • 事故复盘
    • 事故现象
    • 处理经过
    • 原因分析
    • 业务影响
    • 改进计划

17. Etl如何保证数据质量

• 对脏数据进行过滤,对于无效的,重复的数据可以丢掉,对缺失的数据可以丢掉或者补全
• 格式转换,类似于日期、金额等数据需要转换为统一的格式
• 枚举值统一,类似 1 男 2 女 0 男 1女 统一为 0男1女
• 空值给默认值
• 敏感数据脱敏,对于身份证号、手机号通常需要进行加密
• 对数据进行分类打标签，有很大的业务价值
  • 计算在表中出现的次数，每天记录一个值，久而久之可以形成变化趋势，可以发现某些业务细节的波动，发现异常的用户行为。
  • 对关键业务指标做统计值校验，比如N个商品销量的最大最小、中位数、90%位数、平均数、标准差等，同样是每天采集并形成变化趋势，可以发现异常业务情况。
• 解析数据后结构化,统一不同来源的信息结构,便于后期统计分析
  • 数据质量是个很大话题，除了数据准确性，至少还包括数据产出及时性、表间的数据一致性，用户甚至会把任何的数据看不懂都认为是数据质量问题，有些可能只是理解上的偏差。要真正解决数据质量问题，还需要更多技术和规范的努力。
  • 企业在不同的发展时间，系统处理会有所差异，特别是二次开发比较多的公司。后续规范的数据与前面不规范的数据，可以通过相对应的关系，进行结构的统一；如果暂时无法统一，最好分开进行统计，避免出现错误的统计结果。

18. 如何保证数据一致性（指标准确性）

• 首先保证一致性维度
• 有一些公共模型沉淀，避免重复开发，指标收口
• 建立指标管理平台
  • 保障指标唯一性
  • 对于指标口径的变更，有明确的记录
• 建立质量管理平台
  • 检测指标的一些异常情况
  • 波动值监控
• 任务上线前自测&数据测试工程师&分析师介入

19. 了解的同步技术

离线

• kettle
  • 功能强大,可视化做的比较好
  • 支持多种数据源
• datax
  • 丰富的reader和writer
  • 数据抽取性能高

实时

• Flume
  • 主要应用于日志文件
• Sqoop
  • 主要应用于关系型数据库
• Canal
  • 模拟MySQL从节点，获取binLog数据

20. 典型的数据仓库建模方法论？

• 首先需要了解建模方法:
  • 三泛式
  • 维度建模

三泛式

• 第一范式: 要求表必须有主键,每一个字段都是原子性的,不可再分
  • (一列里面不能同时包含多种信息,比如学生的联系方式,不能同时包含邮箱和手机号.)
• 第二范式: 要求所有的非主键字段完全依赖主键字段,不能产生部分依赖
  • (多对多这种场景,一般都是使用中间表来管理多对多的关系,比如老师和学生之间是多对多,如果放在同一张表中,会产生很多冗余数据)
• 第三范式: 要求所有的非主键字段和主键字段之间不能产生传递依赖
  • (一对多这种场景,我们可以通过外键关联组织数据之间的关系,比如一个班级可以有多名学生,一个学生只能有一个班级,我们应该在学生的列后面添加一个班级ID外键,通过外键进行关联)
• 范式建模的目标就是为了保证我们的数据不会出现冗余数据,在实现的时候,就要尽可能的将表进行拆分,后面我们需要用到什么数据,就通过join操作将多个表进行关联,最终得到需要的数据
• 优点:
  • 各个表之间都是解耦的,没有冗余数据,方便维护.
• 缺点:
  • 如果我们完全按照三范式进行表设计,那么我们进行班级/学生/老师之间的数据查询的时候,肯定会出现很多的join操作,如果数据量很大,那么进行join操作就会非常的耗性能.所以一般数据量比较大的时候,我们应该尽量避免join操作.

维度建模

• 可以参考这篇：数仓–一文了解数仓建模
  • 从企业整体出发建设数据仓库–自顶向下
  • 从某个部门,数据集市出发建设数据仓库–自下而上
• 维度建模的表分类:
  • 事实表–度量值,维护大量维度表的主键作为外键,描述一个具体事实,例如订单
  • 维度表–角度,例如时间,地域
• 维度建模的模型

  • 星形

    • 一个事实表关联多个维度表
    • 维度表只与事实表关联,维度表之间没有关联
    • 每个维度表的主键在事实表中作为外键关联
    • 以事实表为核心,维度表围绕核心呈星形分布
    • 优点
      • 数据冗余，查询效率高
    • 缺点
      • 占用存储更多，容易引起数据一致性问题
        

  • 雪花

    • 一个维度表关联维度表
    • 星形模型的扩展
    • 每个维度表可以继续向外关联多个子维度表
    • 满足规范化设计,数据冗余问题不严重
    • 优点
      • 节约存储，不容易引起数据不一致性
    • 缺点
      • 维护麻烦点，使用时需要关联比较多的表
        

  • 星座

    • 多个事实表共享维度表
    • 星形模型的扩展
      
• 三种模式对比

21. 事实表的类型

	事务事实表	周期快照事实表	累积快照事实表
时间特点	离散事务时间点	固定的时间间隔	时间跨度不确定
粒度	每行代表一个事务度量事件	每行代表一个周期内的实体状态	每行代表一个实体的生命周期
日期维度	事务日期	快照日期	相关业务过程涉及的多个日期
事实	事务事实	累计事实	相关业务过程事实和时间间隔事实
适用场景	针对业务过程的事务分析	针对实体的状态分析	针对实体的生命周期分析
更新策略	不更新	周期结束时定期更新	业务过程更新时同步更新

• 事务事实表
  • 事务日期
  • 用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。
  • 相当于每个分区里面都是每天的数据，不包含之前的数据

id	name	regist_time	dt
100356	张XX	2021-10-01 08:02:10	20211001
200389	李xxx	2021-10-02 11:09:20	20211002

• 周期快照事实表
  • 规律性的、可预见的时间间隔
  • 周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表
  • 比如说时间周期是1周，那么这个周期快照事实表的一条记录就是这一周的对于某个度量的统计值

id	order_cnt	user_cnt	dt
130000356	32	28	20211001
224000389	12	12	20211001

• 累计快照事实表
  • 表述过程开始和结束之间的关键步骤事件时间，覆盖过程的整个生命周期-
  • 累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。
  • 例如订单累计快照事实表会有付款日期，发货日期，收货日期等时间点。

order_id	poi_id	user_id	push_time	grap_time	arrived_time	status	dt
16589600009723	300876	100356	2021-10-01 11:02:10	2021-10-01 08:02:10	9999-01-01 01:00:00	30	20211001
16200000003455	300087	200389	2021-10-01 09:10:33	2021-10-01 09:12:33	2021-10-01 10:02:09	50	20211001

• 也有说六种的，这里可以了解一下，个人还是觉得上面的三种比较清晰

类型	特点	示例
事务事实表	记录原子事件，时间粒度最小	订单表、交易表
周期快照事实表	固定时间间隔的快照	每日用户余额表、每月销售汇总表
累积快照事实表	记录业务过程的多个阶段	订单生命周期表、项目进度表
无事实事实表	记录事件，无度量值	用户注册表、产品浏览表
聚合事实表	汇总数据，提高查询性能	每日销售汇总表、每月用户活跃表
桥接事实表	处理多对多关系或复杂层次结构	用户-产品桥接表、组织架构桥接表

22. 事实表的粒度

• 事实表中一条记录所表达的业务细节程度被称为粒度。
• 通常粒度可以通过两种方式来表述：
  • 一种是维度属性组合所表示的细节程度，
  • 一种是所表示的具体业务含义。
• 作为度量业务过程的事实，通常为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型：
  • 可加性事实
    • 指可以按照与事实表关联的任意维度进行汇总。
  • 半可加性事实
    • 只能按照特定维度汇总，不能对所有维度汇总。
    • 例如库存可以按照地点和商品进行汇总，而按时间维度把一年中每个月的库存累加则毫无意义。
  • 完全不可加性
    • 例如比率型事实。
    • 对于不可加性的事实，可分解为可加的组件来实现聚集。

23. 数据域/主题域/主题

• 参考：数据仓库如何确定主题域？
• 参考：数据仓库中的主题域是如何划分的？
• 参考：阿里云划分数据域
• 数据域：指面向业务分析，将业务过程或者维度进行抽象的集合。
  • 其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标; 维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。
  • 通常，您需要阅读各源系统的设计文档、数据字典和数据模型，研究逆向导出的物理数据模型。进而，可以进行跨源的主题域合并，跨源梳理出整个企业的数据域。
  • 数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。例如A公司电商营销业务板块可以划分为如下数据域，数据域中每一部分都是实际业务过程经过归纳抽象之后得出的。例如：

数据域	业务过程
会员店铺域	注册、登录、装修、开店、关店
商品域	发布、上架、下架、重发
日志域	曝光、浏览、单击
交易域	下单、支付、发货、确认收货
服务域	商品收藏、拜访、培训、优惠券领用
采购域	商品采购、供应链管理

• 主题域：通常是联系较为紧密的数据主题的集合。
  • 比如销售分析，进销存分析都是主题，可根据业务的关注点，将这些数据主题划分到不同的主题域(即对某个主题进行分析后确定的主题的边界。)。主题域包含了某方面决策者关注的事物。一个主题域通常会覆盖多个业务部门，例如产品主题域涉及到销售、财务、物流、采购等部门。
  • 主题域的确定必须由最终用户和数据仓库的设计人员共同完成的，而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象，考虑的点可能会是下方的某些方面：
    • 1、按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
    • 2、根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题；
    • 3、按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等；
    • 4、按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题；
• 主题是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
  • 例如 “销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。
  • 简单说，一个主题对应一个分析对象。分析对象就是在决策、分析时重点关注的东西，这个东西其实是非常主观的，在不同的企业，或者企业的不同发展时期，所关注的点会不一样，从而影响有些主题可能存在或者不存在。一般来说，发展成熟的行业，主题的划分会比较固定。
  • 数据仓库是面向主题的应用，主要功能是将数据综合、归类并进行分析利用。数据仓库模型设计除横向的分层外，通常还需要根据业务情况纵向划分主题域。主题域是业务对象高度概括的概念层次归类，目的是便于数据的管理和应用。
  • 面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。

24. 主题域划分依据-除数据访问热度外

• 假如我们现在已经有一块地，要盖一个小区。那么主题域划分就像是在做规划图。咱要建的这个小区，哪里是住宅，哪里是别墅，哪里是幼儿园。
• 主题域模型就是最高视角的蓝图规划。
  • 按业务；
  • 按系统；
  • 按部门；
• 主题域模型是全局规划蓝图（建小区的规划蓝图），概念模型是局部抽象结果（某一栋楼的设计图），逻辑模型是详细设计图纸（设计好每一层的格局），物理模型是按图建设的一栋栋楼房。
• 从主题域模型到逻辑模型，是逐步细化的过程；从逻辑模型到物理模型，是设计到实现的过程。

25. 数据迁移的流程

• 设计迁移方案
• 打造迁移样板间（踩坑）
• 开发迁移工具（比如ddl/dml转换脚本、一键迁移等）
• 数据对比工具（数据条目比对/全字段比对）
• 压测（网络/磁盘io/cpu/内存）
• 考虑是否启动数据治理

26. 数据治理可以做的点，如何持续化治理

• 事前：定规范
  • 如 表名/字段名规范
  • 如 字段comment
  • 如 字段值null赋值默认值
• 事中：常巡检
  • 如任务监控
  • 如数据一致性对比监控
• 事后：常治理
  • 如僵尸表治理
  • 如大任务存算治理

27. 了解onedata吗，说说你的理解

• 统一指标管理
  • 保证了指标定义、计算口径、数据来源的一致性。
• 统一维度管理
  • 保证了维度定义、维度值的一致性。
• 统一维表管理
  • 保证了维表及维表主键编码的唯一性。
• 统一数据出口
  • 实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。

28. 交叉维度的解决方案？

• 多值维度及多值属性(交叉维度)
• 处理多值维度最好的办法是降低事实表的粒度。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。
• 但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如上述交叉维度，事实表与用户维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和用户维度表之间建立个帐户-用户桥接表。这个桥接表可以解决掉帐户维度和用户维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。

29. 大宽表的优点与缺点？

• 优点
  • 提高查询性能
  • 快速响应
  • 方便使用，降低使用成本
  • 提高用户满意度
• 缺点
  • 由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余
  • 另外就是灵活性差，就比如说线上业务表结构变更，宽表模式改造量也比较大
  • 开发宽表为了避免宽表重复迭代，我们应该去了解业务全流程，得需要知道需扩展哪些维度，沉淀哪些指标，这样就流程会比较长，特别是有些业务快速迭代的话，就有点捉襟见肘
  • 产出时间可能较晚

30. 怎么保证每天能在固定的时间数据产出？

• 任务优化
• 集群扩容
• 任务下线
• 值班制度

31. SCD缓慢变化维问题如何解决

• 详情参考数仓–缓慢变化维
• 保留原始值：指标计算不符合最新维度数据
• 改写属性值：无法获取到历史状态
• 增加维度新行：拉链表
• 增加维度新列：成本太高
• 添加历史表：增加维护难度

32. hive各引擎的优缺点（mr/spark/tez）

• mr引擎
  • 多job串联，基于磁盘，落盘的地方比较多
• spark引擎
  • 虽然在Shuffle过程中也落盘，但不是所有算子都需要Shuffle。
  • 多算子过程，中间过程不落盘
  • DAG有向无环图
  • 兼顾可靠性和效率
• tez引擎
  • 完全基于内存
  • 数据量特别大，慎用，容易OOM

33. 业务数据库涉及到表删除数据的情况，数仓感知的方式

• 监控业务数据库日志流处理数据
• 业务库不做物理删除，增加逻辑删除字段，来判别是否可用（eg：is_valid/is_delete）

34. 工作难点

• 快速发展的业务和规范建设的矛盾
  • 针对业务调整频繁的场景，比如维度信息经常发生变动，如何减少数据链路的调整成本(如逻辑调整、数据回刷)？要有所坚持，谨慎建设大宽表等
• 规范和不同开发同学认知的差异
  • 多做认知拉齐，多评审
• 同学之间业务感知、技能能力不同
  • 多组织技术分享、业务分享

35. 数仓工程师成长的脉络图，或者说知识架构图？

36. 发展之路上需要哪些核心能力

• 抽象能力
  • 把业务流程抽象成主题
  • 数据模型的定位清晰，易理解
• 技术能力
  • 基础：sql的debug、优化
  • 对于计算引擎（hive、spark）的原理掌握及优化
  • 对于olap引擎（sr、doris、ck）的原理掌握及优化
• 沟通能力
  • 听懂需求，明白诉求
  • 学会“拒绝”不合理的诉求，引导正确的方向
• 规范能力
  • 对规范有相同的认知

37. 你们的问题报备流程是什么

• tips：原因和改进可以后面处理，优先级最高的是消除问题影响（回滚等方法快速解决问题，上线前需要考虑清楚~）
• 1.【问题描述】
• 2.【问题原因】
• 3.【问题进展】
• 4.【问题影响】
• 5.【问题改进】
  • 【系统优化】
  • 【流程优化】
  • 【监控优化】
• 6.【跟进团队】

38. Lambda架构与Kappa架构对比

• Lambda架构
  • 内容
    • 批处理层(Batch Layer)：两个核心功能，存储数据集和生成Batch View。
    • 加速层(Speed Layer)：存储实时视图并处理传入的数据流，以便更新这些视图。
    • 服务层(Serving Layer)：用于响应用户的查询请求，合并 Batch View 和 Real-time View 中的结果数据集到最终的数据集。
  • 优点：
    • 容错性好、查询灵活度高 、易伸缩、易扩展
  • 缺点：
    • 全场景覆盖带来的编码开销。 针对具体场景重新离线训练一遍，益处不大。重新部署和迁移成本很高。
• Kappa架构
  • 内容
    • 实时层：输入数据直接由实时层的实时数据处理引擎对源源不断的源数据进行处理;
    • 服务层：再由服务层的服务后端进一步处理以提供上层的业务查询。
    • 数据：而中间结果的数据都是需要存储的，这些数据包括历史数据与结果数据，统一存储在存储介质中。
  • 优点：
    • 将实时和离线代码统一起来了；方便维护而且统一了数据口径；避免了Lambda架构中与离线数据合并的问题。
  • 缺点：
    • (1)消息中间件缓存的数据量和回溯数据有性能瓶颈。
    • (2)在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。
    • (3)Kappa在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。

对比内容	Lambda架构	Kappa架构
复杂度	需要维护两套系统(引擎)，复杂度高	只需要维护一套系统(引擎)，复杂度低
开发、维护成本	开发、维护成本高	开发、维护成本低
计算开销	需要一直运行批处理和实时计算，计算开销大	必要时进行全量计算，计算开销相对较小
实时性	满足实时性	满足实时性
历史数据处理能力	批式全量处理，吞吐量大，历史数据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理相对较弱
使用场景	直接支持批处理，更适合对历史数据分析查询的场景，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。	不是Lambda的替代架构，而是简化， Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求。