什么是数据仓库？
如何构建数据仓库？
概念模型、逻辑模型、物理模型分别介绍一下？
SCD常用的处理方式有哪些？
模型设计的思路？业务驱动？数据驱动？
数仓架构为什么要分层？
事实表的类型？
维度建模步骤？
维度建模的三种模式？
数仓架构进化？
数据仓库如何保证数据质量？
开发流程/你们是怎么测试的？
维度建模过程？
维度建模的三种模式？
事实表都有哪几种？
如何做数据治理？
元数据的理解？
如何分层？分层为了解决什么问题？优劣是什么？
数仓高内聚低耦合是什么含义？是怎么做的？
生产中对实时数仓是如何做数据质量管理的，如果同一指标离线和实时计算结果不一致，该怎么处理？
Order By、sort by、distribute by 的差异是什么？
数据质量如何保证？指标一致性如何保证？
ods全量，增量如何确定？有哪些衡量点？
数仓模型优化手段及方式、规范与规划？
主题是如何划分的？具体case
dwd、dws 的英文是啥？各层都做了哪些事情？
方法论，数据仓库怎么构建？你是怎么分主题域的？对现在的业务有什么看法？现在的仓库是个什么情况，各个分层有什么特点？为什么这么分？
拉链表，缓慢变化维
给你一个新业务，怎么开展？
数据治理，数据质量，口径一致
CTE的优缺点？
你负责的那部分，数仓架构是怎么设计的？
实时数仓做过吗，简单说下
用户画像是怎么考虑的？
讲一个最复杂的业务场景
数据赋能，你如何体现数仓职位的价值
数据总矩阵的理解？行和列表示什么？
一致性维度理解？一致性指标理解？
数据仓库中如何保证数据质量？有哪些常见的数据质量问题？
数据治理在数据仓库中的作用是什么？如何实现数据治理？
说说你从0-1搭建数仓都做了什么？你觉得最有挑战的是什么？
流批一体有什么好处？为什么要搞流批一体？
原子指标、修饰类型、修饰词、时间周期、派生指标
数仓每一层有什么难点？
维度退化是什么？
事实表分类？
事实表分类？
数据治理中的数据安全、数据规范、数据质量如何去保障？
一、数据仓库特点(4个特点)
1.1、数据仓库是面向主题的
1.2、数据仓库是集成的
1.3、数据仓库的数据是稳定的
1.4、数据仓库中的数据是随时间变化而变化的
二、数据仓库分层(特点or意义)
2.1、把复杂问题简单化
2.2、减少重复开发
2.3、隔离原始数据
三、数据仓库核心理论
数据仓库建模的目标是通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点
当有了适合业务和基础数据存储环境的模型（良好的数据模型），那么就能获得以下好处：
性能：快速的查询我们所需要的数据，减少数据的I/O吞吐。
成本：极大的减少不必要的数据冗余，实现计算结果复用，降低数据的存储和计算成本。
效率：极大的改善用户使用数据的体验，提高使用数据的效率。
质量：改善数据统计口径的不一致性，减少数据计算错误的可能性
ER模型（范式模型），更多用来梳理业务配合维度建模使用，E为实体，多数情况下落为维度数据；R为实体的关系，多数情况下落为事实数据
维度模型，在维度建模的基础上又可分为三种模型：星型模型、雪花模型、星座模型
数仓建模就是业务模型->概念模型->逻辑模型->物理模型的这样一个流程，下面我们详细解释一下各个模型阶段都要做什么
业务建模：需求沟通
领域（概念）建模：画图想好怎么做
逻辑建模：表设计
物理建模：建表
选择业务过程
声明粒度
确定维度
确定事实
Bill Inmon推崇自上而下的方式（这里的上指的是数据源出发），一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图
Ralph Kimball推崇自下而上的方式（这里的下指的是从业务需求出发），建设数据仓库应该按照实际的应用需求，加载需要的数据，不需要的数据不要加载到数据仓库中
1）命名规范，词根+表名等，主要用于库表字段
2）开发规范，需求->反讲->开发->测试->上线/发布->DQC/报警
需求文档格式
技术文档格式，数据探查、逻辑理解、代码开发
通用测试案例，极大、极小、平均、填充、枚举之类的
多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact)
总线矩阵：业务过程和维度的交点。矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并
一致性维度：同一集市的维度表，内容相同或包含。一致性维度要么是统一的，要么是维度表的一个子集。在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集
一致性事实：不同集市的同一事实，需保证口径一致，单位统一。指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存
事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表
Kimball的维度模型设计方法有以下四个步骤：选择业务过程、声明粒度、确定维度、确定事实
3.8.3、事实表分类
事务型事实表，事务事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度，事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求
周期快照事实表，周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标
累计快照事实表，累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。用于记录当前事务的状态变化
星型模型是一张事实表，根据主键关联多张一级维度表
星型架构是一种非规范化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。很多统计查询不需要做外部的连接，通过冗余换取运行效率
雪花模式是星型模式的扩展，其中某些维表被规范化，进一步分解到附加维度表中。
优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。常用于数据关系更复杂的场景。也称事实星座模型
常见的缓慢变化维处理方式有三种：
1）直接覆盖：不记录历史数据，薪数据覆盖旧数据
2）新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存）
3）新加两个字段（横向扩展）：一个是previous，一个是current，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）
拉链表是什么：记录数据的历史状态以及变化记录。记录一个事物从开始，一直到当前状态的所有变化的信息。拉链表可以避免按每一天存储所有记录造成的海量存储问题，同时也是处理缓慢变化数据的一种方式，适用场景：
单张表数据量很大；
表中的部分字段会被update更新操作，如用户联系方式，产品的描述信息，订单的状态等等；
需要查看某一个时间点或者时间段的历史快照信息
变化的比例和频率不是很大，比如，总共有1000万的会员，每天新增和发生变化的有10万
技术信息梳理，来源媒介，存储媒介，计算方式
业务信息梳理，业务来源梳理、数据内容分类梳理、数据形式梳理等
采集方式，根据4.1的业务信息梳理确定采集方式写入到kafka，供下游使用，具体如下：
客户端埋点数据，API采集，写入kafka；
服务端埋点数据也可以采用API，也可以采用flumeNG采集磁盘数据；
业务库数据可以采用binlog采集，比如flinkcdc的方式；
外部数据采用API采集，如三方转化数据等
数据清洗，分为离线和实时两类处理，存储媒介分为kafka、hdfs类、olap类
实时数据清洗，方式为flinksql，存储到kafka 或者 olap 如clickhouse、doris
离线数据清洗，方式为sparksql/hivesql 存储到olap 或者hdfs中
数仓建设规范-维度建模，自低向上、数据域+业务过程、4层结构
数仓命名规范-表名、任务名、字段名称、通用词根、业务名称等等
数仓开发规范-需求理解、需求反讲、需求开发、需求测试、需求上线等
数仓评价标准-1987
业务元数据，数据归属业务主题、业务描述
技术元数据，数据来源信息、加工等技术类的信息情况
应用元数据，使用场景，口径信息等情况
表血缘、字段血缘，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误，如何构建依赖树，如何构建联级重跑
对外提供要求数据口径一致，性能分级保障；形式库表、文件和API接口；API接口共享可以使用API网关实现，常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等