如果你想提升大数据技术能力，如果你想找人指导，如果你想持续学习，如果你想找到一份满意工作，那么可以来我的知识星球，我开通知识星球大半年时间了，星球上沉淀了很多有价值的内容，星球的定位就是专注于大数据内容的干货输出，帮助大家提升大数据技术，带领大家一块学习。星球内容以及语雀文档都是本人经过用心总结和整理的。
知识星球里包含1200份资料，包含常见面试问题，调优资料、大厂实践、公众号原创文章，代码等，需要自取。另专为星球成员整理了一份比较详细的语雀知识库，包含常见面试问题总结，项目视频，技术总结，各项调优资料等另外说明加入星球后支持三天无理由退款，不满意无条件随时退。
进入星球可享受以下服务：
一、 提供最全的大数据知识库，不限设备，随时随地打开看的在线文档。二、免费答疑解惑、交流技术
三、面试指导、模拟面试
四、各类pdf文档下载、星球代码下载
五、提供简历模板，简历修改指导服务，星球成员免费提供简历修改指导
基础平台搭建
1，熟悉业务
（1）业务的战略目标或愿景是什么
（2）业务线或产品线有哪些
（3）梳理各业务场景、业务架构
（4）业务现状如何，有哪些业务痛点
例如运营方想通过用户标签或产品标签快速圈选目标人群、目标商品，但痛点是取数的链路长、取数效率低。可以从几方面解决： （1）采用数据仓库解决方案——提前与业务方沟通，把所需数据提前准备好，存放在数仓的ADS层（由DIM和DWS加工得到），供业务方自助取数 （2）采用湖仓一体解决方案——仓外挂湖，也就是把数据仓库中的表数据与hive、hudi或iceberg中的数据做链接，即数仓表的外表。可行的技术栈是：Doris作数仓，Hudi或Iceberg作数据湖（DataX+FlinkCDC实现全量+增量业务数据导入湖中），在Doris建模时链接湖中的数据
（5）需求收集
与业务方开会，收集业务方的各种需求。在符合战略目标或愿景的前提下，为收集到的各种需求分配优先级，然后根据资源限制(人力资源、资金、开发复杂度)把最高优先级的数量做限制，例如当前把最急需的需求控制在3个以内
(6) 需求调研
业务调研
业务调研的流程分三个步骤：• 输入调研模板。• 针对产品和运营进行调研。• 归纳产出：业务过程&数据域。
需求分析
需求分析的三个步骤：• 输入调研模板，研究报表&数据体系。• 与分析师&运营讨论收集信息。• 归纳产出：指标体系
数据调研
数据调研需要做好数据探查工作，需要了解数据库类型，数据来源，全量数据情况及数据每年增长情况，更新机制；还需要了解数据是否结构化，是否清洗，是接口调用还是直接访问库，有哪些类型的数据，数据结构之怎样的。• 数据开发，模型建设之前，先了解数据结构，数据内容，数据特性，对数据有一个整体把控 • 探查一下本次需求能不能实现，怎么实现，有没有隐藏bug，数据质量如何
（7）产出
概念图：业务架构图
各业务模块之间、业务内部子模块之间的交互关系（层级关系、包含关系、平行关系、主次关系）
逻辑图：业务关联（E-R模型+流程图）
概念模型：E-R图 Entity-Relationship Model
作用：E-R模型用于描述产品或业务内部各模块之间的关系，能帮助快速学习业务逻辑和产品逻辑，也能从中发现业务或产品中存在的问题
绘制E-R图步骤： 1，确定对产品或业务实体有重大影响的实体。例如：用户、订单、商品、优惠券或积分、物料、耗材 2，确定能影响到产品或业务正常运转的关键属性。随着业务或产品发展，可能有一些属性独立出来变成实体，例如“收货地址” 3，确定实体之间的关系。需要多人配合一起讨论，找出实体之间存在的所有联系
E-R图的使用建议： 1，在新接触一个业务或产品时，先使用 E-R 图帮助建立相关的概念，为下一步要绘制的流程图预备知识 2，在落实到新产品或新业务开发时，通过E-R图理清一款产品或一项业务需要哪些功能、服务于哪些用户、需要搭配什么系统
逻辑模型：流程图 （对业务的发展变化过程可视化）
流程图与 E-R 图的区别： 流程图关注的是整件事情的各种处理过程以及各过程之间的逻辑关系和时间顺序，所以流程图关注的是动态的事情，E-R图关注的是最终态的事情。下面解释为什么： 例如一个“订单”实体，其中的一个属性“订单金额”由当前订单下的商品数量、单价、优惠券、下单时间共同决定，由于下单商品数量会增减，优惠券组合也不同，而且用户下单时间也不固定，所以直到用户下单的一刻“订单金额”属性的值才能确定。整个下单过程就是动态的、变化的
绘制流程图的六个元素
(1) 参与者： 可以是用户、部门、系统、定时任务
(2) 活动： 做的事情、任务、活动，这些内容是流程图要重点展示的
(3) 次序、顺序： 用箭头表示活动或环节的先后发生顺序和依赖关系。由于有并行的任务，所以有同向的多个箭头；并行之后也可以在某个环节合并成为一个环节，所以有汇合的箭头
(4) 输入： 活动或任务的输入可以是依赖的信息或者上游的任务。依赖的信息举例：为用户推荐商品，就必须依赖用户最近的浏览历史、购买历史
(5) 输出： 每个活动或任务结束后产生的结果。当前活动或流程的输出可以作为下一个流程的输入，可以向多个活动或流程输出结果
(6) 标准化： 就是用标准的符号表示流程图的内容。例如矩形表示活动或流程，圆角矩形表示整个流程图的开始或结束，箭头表示活动之间的顺序，菱形表示数据
带泳道和阶段的流程图：
当业务流程涉及几个阶段，参与方涉及多人、跨部门，并且需要让每个参与方清楚各自负责的步骤，此时需要带泳道和阶段的流程图。下面展示了两个实例
物理模型： 继概念模型和逻辑模型之后，物理模型的数据库、表映射业务架构
2，数据规模测算
数据规模测算
1. 根据数据平台的 数据特点来预估
数据特点包括数据来源、种类、结构(结构化、半结构化、非结构化)、粒度、时效性
2. 根据存储容量和 数据增长速度预估
根据数据平台现有的存储容量和数据增长速度，可以初步预估未来一段时间内的数据规模，以满足业务需求、避免资源浪费和过度投资，合理分配存储、计算和网络带宽资源
收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算
3. 需要考虑到数据质量问题
有质量问题的数据包括：未去重的数据、无效的数据、错误的数据等。这些有问题的数据会影响存储和计算规模
4. 结合业务场景和实际需求进行预估
根据业务场景和实际需求，结合前面三步的分析结果，对数据平台的未来数据规模做预估；同时，要持续监控各种资源的使用情况，以便调整和优化资源的分配。例如，如果业务场景中涉及到海量数据的处理和分析，那么数据平台的存储容量和处理能力就需要相应提高，也就是考虑平台的可扩展姓
5. 考虑数据安全和隐私保护问题
需要考虑数据的加密、备份、恢复等方面对存储和处理的制约，还有相关法律法规对数据安全和隐私保护的要求
任务数评估
方法概述——基于历史任务做分析，统计各类数据处理任务的数量波动，从中发现趋势，根据趋势做预估，如果是新建的平台尚未有历史任务，那么用以下方法：根据该平台将要承载的业务需求做预估，例如预估固定报表有几张、制作每张报表所需的数据量是多大、每个报表的加工链路有几个算子、集群的资源是多少，然后在该平台模拟一些数据处理任务，以观察任务运行期间对资源的消耗情况。当发现集群在同时运行 XXXX个任务时占满了集群的所有资源，此时的 XXXX 值可作为最大并发任务数
步骤
1. 理清数据处理需求:根据数据平台的处理需求以及之前做的数据规模预估结果，粗略算出需要运行的任务类型和数量，包括OLAP任务、批处理任务、流处理任务的数量和任务周期
2. 考虑数据来源和多样性: 根据数据的来源、格式、大小、频率等，粗略估算需要运行的任务数量和类型
3. 根据数据平台的数据处理能力评估: 也就是要根据容量评估，具体包括计算资源、存储资源、网络资源等，以确定能够同时运行的任务数量和类型
4. 要考虑任务调度和并发控制: 这是为了保证所有任务按照预定顺序和优先级运行，避免任务之间的冲突和竞争
为什么要考虑任务之间的依赖关系和并发控制？第一个原因，如果任务之间的依赖关系处理不当，会导致任务执行效率低或者出现错误，就提高整体的作业数量。第二个原因，如果并发控制不好，会导致任务之间的竞争和冲突，从而降低任务执行的稳定性
容量评估
如何评估
收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算
存储资源
单条数据大小*日数据量*周期*副本数
HHD
SSD
机器存储节点数
数据总量/（单台服务器总磁盘大小*0.8）
cpu
单台配置推荐64核，cpu和内存之间建议1：2或者1：4
内存
单台推荐128G或256G
网络带宽
10亿级别，千兆网卡可以支持，推荐万兆网卡
大数据机器集群规划
数据特征
数据格式
数据压缩
序列化方式
文件类型
产出文档
cpu内存、核数、单块磁盘大小、挂载数量、机器数量、成本预算相关文档
3，技术架构设计
可选的数据平台架构
lambda架构： 离线数据链路； 流式数据链路
kapa架构： 批流一体
pulsar+flink
flink+MPP
存算一体
存算分离
IOTA架构
IOTA大数据架构是一种基于AI生态下的、全新的数据架构模式，这个概念由易观于2018年首次提出。IOTA的整体思路是设定标准数据模型，通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中，以统一的数据模型贯穿始终，从而提高整体的计算效率，同时满足计算的需要，可以使用各种Ad-hoc Query来查询底层数据。
去ETL化：ETL和相关开发一直是大数据处理的痛点，IOTA架构通过Common Data Model的设计，专注在某一个具体领域的数据计算，从而可以从SDK端开始计算，中央端只做采集、建立索引和查询，提高整体数据分析的效率。
Ad-hoc即时查询：鉴于整体的计算流程机制，在手机端、智能IOT事件发生之时，就可以直接传送到云端进入real time data区，可以被前端的Query Engine来查询。此时用户可以使用各种各样的查询，直接查到前几秒发生的事件，而不用在等待ETL或者Streaming的数据研发和处理。
边缘计算（Edge-Computing）：将过去统一到中央进行整体计算，分散到数据产生、存储和查询端，数据产生既符合Common Data Model。同时，也给予Realtime model feedback，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。
LakeHouse架构：湖仓一体
仓外挂湖
湖上建仓
湖中建仓
如何选型
1，考虑数据架构适用的数据处理场景，例如离线数仓、实时计算、实时数仓、批流一体、湖仓一体、DataOps
2，同一功能的不同框架之间的对比：适用的数据处理场景、更新是否频繁、数据处理(查询或写入)性能、容错性、是否易用、是否要求高并发点查、exactly-once、是否方便运维(包括故障排查）
3，选定框架或组件之后，做好相关的压力测试(最好做一次全链路压测以提前发现薄弱环节)，然后出具压力测试报告
4，产出：生成《选型建议》 , 涵盖四项内容
一、各框架或组件的对比文档
二、从第3步的压测报告中选取各项关键指标的对比结果，做出选型建议
三、技术架构图
四、完整的Demo演示： 数据的全链路处理流程演示
架构实现方式
Hadoop生态
MPP
Hadoop + MPP
数据湖+MPP
4, 机器节点的规划
集群各节点规划
安装、部署和运维
参数调整
LDAP、权限管理
5，高可用多机房部署
多机房规划
容灾、备份
数据仓库建设
数据采集模块
采集方式
离线定时采集
sqoop
实时采集、增量采集
日志：flume、logstash
数据库
dataX
flinkCDC
canal、maxwell
cloudCanal
tis
离线、实时、增量采集
SeaTunnel
可配置的流任务开发平台 (在web页配置)
对接kafka满足大部分的 流处理需求任务
例如： 埋点数据上报到kafka之后，只需要在web 页面配置flink的源topic、字段声明及加工逻辑、sink目标表、数据校验规则、告警规则
一致性保证 (如何确保ExactlyOnce)
框架本身是否已实现
kafka 是否已实现、如何实现： kafka的客户端支持消息写入topic的幂等性
Flink 是否以实现、如何实现：
两阶段提交事务
预写日志事务
lableid+state+checkpontInterval flush
流处理任务的监控
数据源端(kafka)监控指标有哪些：
sink端(湖、仓中的表)监控指标有哪些：
数据仓库建设
分成哪几层，每层的功能是什么
分层的意义
隔离原始数据
不论是数据的异常还是数据的敏感性,使真实数据与统计数据解耦开. 不必改一次业务就需要重新接入数据。另外，随着业务的变化，只需要调整底层的数据，对应用层对业务的调整零感知。
清晰数据结构体系
每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。
数据血缘追踪
由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低。
减少重复开发和资源浪费
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；清晰明了的结构使得开发、维护的成本降低；减少重复计算和存储的资源浪费；
复杂问题简单化
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
数据安全
通过分层，可以更方便地对不同层，不同的数据模型进行权限管理，特定业务场景下，对不同的开发人员和业务人员屏蔽一些敏感的数据。
每一层的作用
ODS:存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区，数据原则上全量保存
DWD:以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。数据粒度一般保持和ODS层一样的，并且提供一定的数据质量保证。同时为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。同时在此层会采用明细宽表，复用关联计算，减少数据扫描（逻辑事实表）
DWS:以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。（汇总数据层 + 主题宽表） 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
DIM：基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。维度层的表通常也被称为维度逻辑表。高基数维度数据一般是用户资料表、商品资料表等类似的资料表。数据量可能是千万级或者上亿级别。低基数维度数据一般是配置表，比如枚举值对应的中文含义，比如国家、城市、县市、街道等维表。数据量可能是个位数或者几千几万。
ADS：这是应用服务层,一般就直接对接OLAP分析,或者业务层数据调用接口了 这是最顶层,一般都是结果类型数据,可以直接拿去使用或者展示的数据了.也是对数据抽离分析程度最高的一层数据 这一层是需求最明确的一层,根据业务需求来决定数据维度和结果分析.类似代码最外层,接口是相对最固化的.
分层原则
（1）清晰简洁原则：分层设计应该简洁明了，每个层次的功能和任务应该清晰明确，不重复，避免冗余和混淆。
（2）独立可扩展原则：每个层次应该是独立的，可以单独进行扩展和修改，而不会对其他层次造成影响。
（3）数据一致性原则：分层设计应该保证数据的一致性和完整性，确保数据在不同的层次之间能够正确地传递和转换。
（4）性能和效率原则：分层设计应该考虑到数据的查询和分析性能，合理地设计和构建汇总层，以提高数据的查询速度和分析效率。
（5）灵活性和可用性原则：分层设计应该提供灵活的数据查询和报表功能，以满足用户的不同需求和要求。
模型选择
维度模型（自下而上）
星型模型
雪花模型
星座模型
ER模型
3NF
Data Vault模型
Hubs：表示实体或业务概念
Links：表示实体之间的关系。
Satellites：存储描述实体和关系的属性数据。
Anchor模型
模型设计原则
1.高内聚，低耦合
所谓的"高内聚低耦合"是指同一个主题内部高内聚，不同主题之间低耦合。
模型分离
建立核心模型和扩展模型体系。在业务建设过程中，我们通常会对一些核心业务建设核心模型，在核心模型中的字段主要用来支撑一些通用的主流的核心业务，同时也会针对一些特殊和定制化的少量需求建设扩展模型，在这种情况下，我们应当避免将扩展模型中的字段侵入到核心模型中，以免破坏核心模型架构的可维护性和通用性。
公共处理逻辑下沉
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。
成本与性能平衡
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚
处理逻辑不变，在不同时间可多次运行，多次运行如果结果不一致要明确原因。
一致性
具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解
表命名需清晰、一致，表名易于理解和使用。
模型阶段性划分
业务模型
业务模型主要解决业务层面的分解和程序化
(1) 划分业务:根据业务部门进行划分,理清部门之间的关系.
(2) 熟悉业务:了解详细业务逻辑和数据处理逻辑,提供业务/数据处理流程文档、数据源访问信息.
(3) 明确数据需求:提供页面原型、需求文档、指标口径文档: ①用户查询方式:导出到数据库,导出文件,提供数据服务; ②用户查询频率及数据延迟; ③历史数据保存期限.
(4) 项目开发评估:确定项目人员分配、项目周期,评估项目风险.
领域模型
对业务模型进行抽象处理
运用实体建模法,将业务模型抽象化,合并类似的概念,细化概念;
将业务抽象成实体、事件和说明这三部分,理清实体与实体之间的关联,生成概念模型并整理为ER图.
主题域的划分
逻辑模型
将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化
实例化每一个抽象的实体，并丰富实体的一些细致的属性。
找出抽象实体间的联系，并将其实例化。
找出抽象事件的关系，并对其进行说明。
表的结构和属性、表之间的关系
提供与生产一致版本的数据结构，准确完善的数据字典，符合分析需求的样本数据;并能对样本数据分析中的问题进行及时准确的回复跟踪。并产出逻辑模型文档
物理模型
解决逻辑模型针对不同关系型数据库的物理化以及性能问题
数据结构性质、表的存储和压缩
ETL工具
数仓组件
代码开发
脚本编写
性能要求
任务调度
性能优化
业务模型主要解决业务层面的分解和程序化 领域模型是为了建立实体以及它们的属性和关系。如：主题域的划分、维度、事实 逻辑数据模型定义了数据元素的结构，并设置了它们之间的关系。如：表的字段信息、表之间的逻辑关系 物理数据模型描述了数据模型在数据库中具体的实现方式。如：代码设计与开发、性能优化，日志收集，表的存储与压缩格式。。。。
建模流程
数据建模是一个“通过良好的结构设计，建设满足要求的数据集合”的过程。
流程
1.系统边界关系模型设计
要做的决策类型有哪些?
决策者感兴趣的是什么问题?
这些问题需要什么样的信息?
要得到这些信息需要包含原有数据库系统的哪些部分的数据?
2、事件流产生业务模型设计
3、数据域的划分
数据分域分为三个步骤：收集、提炼、归纳。
1. 收集：业务数据需求、存量数据梳理
2. 提炼：业务过程、业务梳理
3. 归纳：数据域1：收集：业务数据需求、存量数据梳理
• 核心目的：对现有数据和业务诉求需要的数据进行merge，保障数据仓库的完整性，形成数据全集。
• 核心对象：分析师、业务运营人员、数仓开发者。
• 核心输出：粒度、维度、数据指标、使用场景等信息。
2：提炼：业务过程、业务梳理
业务过程：指企业的业务活动行为，如点击、浏览、下单等，业务过程是一个不可拆分的行为事件。
• 核心目的：对收集的数据全集，进行业务关键词（包括业务过程、业务元素）提炼，根据经验罗列分类。
• 核心对象：数据模型架构师。
• 核心输出：业务过程、业务元素列表。
3：归纳：数据域
数据域：面向业务，根据业务过程进行分类，组合抽象而成的数据集合。数据域不能轻易变动，在划分数据域时，既能覆盖当前所有的业务场景数据，又能在新业务进入时被融入，或对整体架构无影响下的扩展新数据域。
• 核心目的：对业务过程、业务元素的列表进行抽象，尽量避免边界模糊不清，归纳出数据域名称。
• 核心对象：数据模型架构师。
• 核心输出：数据域大图，包括核心业务过程与元素的包含关系。数据域和主题域的区别？
数据域是对数据的分类，主题域和业务域是对业务的分类。主题域和数据域最终都是对数据的分类，只是一个是数据视角，一个是业务视角。
数据域和主题域的区别？
数据域：面向业务过程，将业务过程或者维度进行抽象的集合。它是以业务系统的角度，对业务过程进行归纳，抽象出来的数据域。根据业务过程进行划分，需要注意的是一个业务过程只能属于一个数据域。主题域：与业务分析相关的。
主题域是数仓中的一个更细粒度的概念，用于描述和分析特定的业务领域或主题。数据域和主题域之间存在一定的层次关系。数仓中的每个数据域都包含了一个或者多个主题域。
主题域是从业务视角自上而下分析。从整体业务环节中升华出来大的专项分析模块，结合对接的业务范围和行业形态从更高的视角去洞察整个业务流程。因此，主题域是由多个数据域组成的，这些数据域提供了主题域所需的数据。
区别 数据域是自下而上，以业务数据视角来划分数据，一般进行完业务系统数据调研之后就可以进行数据域的划分。主题域则自上而下，以业务分析视角来划分数据，一般进行完业务需求调研之后才可以进行主题域的划分。
数据域：ODS|CDM
主题域：ADS|APPMCEE原则：相互穷尽，不重叠。完全穷尽，不遗漏
我们之前提到数据域的划分，要尽可能的满足MECE原则。但按对象分，和按过程分，两者不可避免的会产生重叠，这种情况怎么处理？有两种方式：（1）在过程域和对象域之间建立从属关系，看谁跟谁离得近就归给谁。例如供应商这个对象，虽然采购过程会有，营销、交易、售后过程也都会涉及。但是“供应商”这个对象离采购更近，我们归给采购这个域内。如果是非常复杂的业务，我们则可以建立一个二级的数据域叫做“采购-供应商”，这个域以供应商为核心，不仅只包括采购的数据，也包括营销、交易、售后服务的数据。这样就可以保证数据域之间尽可能的不重不漏。（2）接受数据域之间的重叠部分，并通过一致性维度来保证不同数据域之间数据的一致性。
4、总线矩阵
主题域
业务过程
维度
颗粒度
度量值
5、明确指标统计
统一指标命名
统一指标计算口径
指标拆解、指标分级
原子指标
派生指标
一级指标
(1)一级指标(Tier 1 Metrics)：公司战略层面指标 一级指标必须是全公司都认可的、衡量业绩的核心指标。
二级指标
2)二级指标(Tier 2 Metrics)：业务策略层面指标 二级指标是针对一级指标的路径分析拆解，是流程中的指标。一般是部门领导人所关心的指标；
三级指标
(3)三级指标(Tier 3 Metrics)：业务执行层面指标 三级指标是针对二级指标的路径分析拆解，通常以子流程或个体的方式定义。一般作为问题分析的重要关注点。
衍生指标
一级指标
二级指标
三级指标
如何拆解
公式拆解法：是指通过一级指标的计算公式进行二级指标的拆解
漏斗拆解法：是指通过用户的使用流程或者步骤逐步拆解二级指标
维度拆解法：是指将一级指标按照不同维度细分的方式进行拆解。
指标拆解步骤
第一步，找到主指标,明确指标定义和计算公式
GMV = 购买人数 X 客单价
第二步，找到与主指标的直接关系的子指标。核心业务转化流程拆解。这一步也很重要，因为很多指标不止一种拆解方法。到底怎么拆合适呢？要看拆完以后，是否有对应主指标的子指标。如果有的话，就能根据指标变化做改善。如果没有，那拆了也白拆。
（1）梳理业务转化流程
（2）「购买人数」拆解
购买人数 = 活跃用户数 X 商品详情页触达率 X 加购率 X 订单提交率 X 支付成功率
（3）拆解结果
第三步，对子指标再进行继续拆解，同时确认各级指标都有数据采集。这一步是确认拆解是否可以继续进行的关键一步，因为指标的背后是数据采集，如果没有数据采集，那拆解就进行不下去了。（如下图）
（1）「活跃用户数」拆解
活跃用户数 = 新活跃用户人数 + 老活跃用户人数
（2）拆解结果
第四步，列出拆解公式，进行数据对比。这里呈现的就是最终结果，可以去进行分析了
指标生命周期管理
统一外部数据输出归口
建立指标字典
6、规范化定义
词根规范
行业术语(一般指翻译不太准的)
数据分析师协作
业务方协作
词根评审
是否必要
是否存在
词根维护
id
所属分类
英文词根
中文词根
使用频率
数据类型
长度
责任人
评审日期
数据字典
用途
数据字典是各类数据描述的集合 -数据字典是进行详细的数据收集和数据分析所获得的主要结果 -数据字典在数据库设计中占有很重要的地位
内容
数据项；数据结构；数据流；数据存储；处理过程。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。
字典数据表模板
字典类型表模板
命名规范
库命名
表命名
指标命名
任务命名
建模评审规范
指导理论
数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性维度和事实。参考阿里onedata建模
模型层次
参考数仓分层逻辑
实施步骤
选择已经确定业务进行梳理，了解业务流程（参考产品数据文档）
ER关系：输出ER关系图，了解实体关系，验证数据是否一致 PDM
现有数据流梳理：输出数据流程图 PDM
结合提数模型，指标，产品需求文档等，优化目前模型：基于上一步PDM输出优化模型，记录优化点；（数据流跟数据模型结合）
基于以上文档进行评审，不通过进行迭代
评审通过后进行开发，上线：开发在目前系统上实施，优先级降低，任务时间戳开
开发规范
开发原则
支持重跑
数据生命周期合理
任务迭代不会严重影响任务产出时间
公共规范
所有单词小写 单词之间下划线分割（反例：appName 或 AppName） 可读性优于长度 (词根，避免出现同一个指标，命名一致性) 禁止使用 sql 关键字，如字段名与关键字冲突时 +col 数量字段后缀 _cnt 等标识... 金额字段后缀 _price 标识 天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd） 小时分区使用字段 hh，范围（00-23） 分钟分区使用字段 mi，范围（00-59） 布尔类型标识：is_{业务}，不允许出现空值
sql编写规范
多表连接时，使用表的别名来引用列。如 t1.user_id t2.user_name
表名前面需要加上项目名，一个是比较清晰，另一个是如果需要把该任务整段代码移到其他项目去跑的时候（比如分析查询项目），需要手动加上项目名，否则会报错
不要出现select * 这样的操作
增加必要注释，以增强代码的可读性。
层次调用规范
禁止反向调用
ODS 只能被 DWD 调用。
DWD 可以被 DWS 和 ADS 调用。
DWS 只能被 ADS 调用。
数据应用可以调用 DWD、DWS、ADS，但建议优先考虑使用汇总度高的数据。
ODS->DWD->DWS>ADS
ODS->DWD->ADS
同一主题域内对于DWD生成DWD的表，原则上要尽量避免，否则会影响ETL的效率。
安全规范
至少做到表级别的权限控制，实在不行就分库。
ODS 层不对外开放，只对 ODS-DWD 层相关部分开发人员可见。
特别敏感数据，如用户年龄、号码、身份证好、地址等，应该放到专门的数据库里，数仓主库只存放用户 ID 和其它必须字段。例如年龄应该脱敏成年龄区间或开发特定的 UDF 转化函数。
7、明细、汇总模型设计
宽表加工
宽表设计的多宽合适
分区
压缩
建模步骤
1、确定业务过程
业务过程是业务活动事件，如下单，支付，退款都是业务过程，把这些过程转换为事实表中的事实，多数事实表只记录某一业务过程的结果。业务过程的选择非常重要，因为业务过程定义了特定的设计目标以及对粒度、维度、事实的定义。
2、声明粒度
声明粒度是维度设计的重要步骤，粒度用于确定某一事实表中的行表示什么。在选择维度或事实前必须声明粒度，因为每个维度或事实必须与定义的粒度保持一致。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。我们要预判所有分析需要细分的程度，从而决定选择的粒度。
3、确定维度
维度是度量的环境，用来反映业务的一类属性。这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。用于分析时进行分组和筛选。
4、确定事实订单事实表得有维度，而原子指标没有维度。故而，订单事实表没有原子指标。
事实 涉及来自业务过程事件的度量，基本上都是以数据值表示。事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。在设计过程中，可以选择不同类型的事实表，它们有各自的适用场景
事务型事实表
一种详细记录某个具体事务全过程的事实表
它保存的是各业务过程的原子操作事件，即最细粒度的操作事件
只有在事件发生时产生记录
事实可加：如订单金额
周期快照事实表
以具有规律性的、可预见的时间间隔来记录事实
可以清晰地反映业务数据的周期性变化
用快照采样状态
事实半可加：最大值、最小值、平均值...
主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。
累计快照事实表
基于一个业务流程中的多个关键业务过程联合处理而构建的事实表
累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。
用于时间跨度不确定的不断变化的业务流程
每行代表一个实体的生命周期
事实不可加
8、模型验证和测试
9、任务编排与上线
依赖设计
将ETL抽象为多个相互依赖的代码节点形成上下游依赖关系，要求如下：一个节点仅产出一张表，一张表仅由一个节点产出。下游节点的输入数据来自于上游节点的产出数据。多并行、少串行（在分布式系统下可发挥其优势）。
运行周期
如果数据研发的场景是在常见T+1离线计算场景，则应将不同调度任务按照实际业务需求，赋予小时、日、周、月和季度等不同的调度粒度。
设置基线
在传统T+1（每日计算的是前一日产生的业务数据）的场景下，数据理应在第二天某个时间点按时产出以支撑BI或其他应用场景，因此应设置如下基线报警策略。最终产出任务基线：规定产出最终数据的任务必须在公司规定的X点X分完成，否则视为破线（同时推送相应报警）。中间任务报警：产出最终数据的任务的上游任务应稳定、按时运行完成。如果出现出错、变慢（运行时间明显长于历史过往平均运行时间）等可能影响最终任务完成时间的事件，则应第一时间推送报警给第一任务责任人。
设置优先级
基于有限的计算资源来设置任务优先级，以保证在已有资源被充分调配利用的情况下，可以按照顺序产出数据，保证重要任务的准时产出。调度设计完成后，需要产出调度设计文档。
指标管理平台
指标字典
指标编码
主题模块
指标类别
指标名称
指标命名四要素
量化词
如金额、次数、人数...
业务过程
统计对象
如订单、用户、商家...
限定词
推荐呈现方式
指标口径
计算公式
维度
度量
维度管理
数据集管理
指标需求
业务域管理
权限管理
指标管理的几大步骤
建立指标生产协同机制：指标的诞生要经过需求申请、审核、数据开发、上线应用流程，收口指标创建过程，避免指标建设的随意性带来的“污染”
制定指标命名、口径说明规范：按照原子指标+业务限定+统计维度的方式，将规则集成到平台内，通过系统规则来把控指标输出。
指标字典线上化：解决线下文档(excel)管理指标存在的共享难、更新不及时、权限管控缺失等问题
指标数据逻辑绑定：即除了维护指标的业务元数据外，还要建立指标的技术元数据，指标数据从哪个模型、哪个字段、何种计算逻辑得到。
指标输出：指标管理最大的价值还是为数据产品提供数据输出。
指标生命周期
指标校验/上线
指标的修改
指标下线
什么是好的指标体系？
1. 系统性
能够发现局部与整体的关系及问题定位，当数据发生异动时，通过指标体系的逻辑拆解，能迅速定位到大致的异动模块及原因。
2、全面性
指标体系应该包含多个维度和角度，能够全面评估一个对象或过程的方方面面，而不仅仅是单一的视角。
3. 认知统一
指标体系服务于不同角色群体，简单科学可解释，符合大众认知，大家都共同认可。
4. 真实性
指标体系要能反映产品真实情况，杜绝华而不实的虚荣指标；指标是为了让公司，业务，或者项目的成员围绕着一个可量化的目标展开一系列的工作的。如果数据指标没有贴合业务核心目标的话，那么给公司，业务或者项目带来的会是巨大的损失
5. 可迭代
指标体系随不同生命周期阶段而改变，指标体系要在发展中保持迭代。
6. 可操作
KPI 达标率：如果你的核心指标是 KPI 指标，那就直接根据 KPI 达标率来判断即可。这个应该是最常见的一种方式。
竞品对标：如果你能从靠谱渠道搜集到竞品相关数据，那以竞品为参照物进行判断。
环比对比：查看环比数据，如果业务走势呈明显周期性，选择一个历史数据较为不错的数据进行对比。
同比对比：查看同比数据，预估每个周期增长多少个百分点，与上一周期数据进行对比，看是否达标。
标签体系建设
首先，收集业务方的标签需求， 再根据战略目标、实现的复杂度、ROI来确定各种标签的优先级，为当前阶段搭建标签体系
ID-Mapping
全局唯一ID关联
Hbase+redis
sparkGraphx
图数据库nebula-algorithm
机器学习+图模型
标签的开发
离线标签
规则类标签
挖掘类标签
标签相似度计算
标签组和计算
朴素贝叶斯
NLP
预测类标签
统计类标签
按照实际业务需求、场景划分分类主题，标签粒度
实时标签
用户特征库加工
用户分群、人群圈选
bitmap+物化视图
打通数据服务层
标签存储方案
存储方案
Hive
hbase
es
starrocks
表设计
宽表
主要适用于前导流程为离线ETL，模型相对固定可以基于宽表模型构建物化视图，加速圈选查询效率 另外宽表模型，对于基于UID查用户明细，应对高并发场景也比较友好
高表
适用于前导为实时ETL，模型变动较快，如当日有新增属性标签， 纵表模型避免了做schema change相对灵活 缺点：难以命中物化视图，建表时也需要考虑数据倾斜相关难点
宽表+高表
主键模型宽表+Starrocks高表（聚合模型）====》合并成宽表
标签的生命周期
涉及标签的新增、修改、删除，标签的上线、下线；记录标签的增删改记录；监控标签的访问频次以便及时删除标签数据、节省存储成本
标签权重计算
行为类型权重
根据业务活动的重要性划分
时间衰减系数
用户行为次数
TF–IDF计算标签权重
总结：用户标签权重=行为类型权重×时间衰减×用户行为次数×TF–IDF计算标签权重
评估标准
（1）准确率 标签的准确率指的是被打上正确标签的用户占被打上标签用户的比例。准确率是用户画像最核心的指标，一个准确率非常低的标签是没有应用价值的。准确率一般是对每个标签分别评估，多个标签放在一起评估准确率是没有意义的。
2）覆盖率 标签的覆盖率指的是被打上标签的用户占全量用户的比例。覆盖率既可以对单一标签计算，也可以对某一类标签计算，还可以对全量标签计算。人均标签数是指所有被打上标签的用户的总标签数除以被打上标签的用户数。覆盖率和准确率是一对矛盾的指标，需要对二者进行权衡，一般的做法是在准确率符合一定标准的情况下，尽可能地提升覆盖率。
3）时效性 有些标签的时效性很强，如兴趣标签、出现轨迹标签等，有效期可能只有一周或一个月。有些标签的时效性很差，或者说稳定性很强，如性别、城市等，可以有一年到几年的有效期。对于不同的标签，需要建立合理的更新机制，以保证标签时间上的有效性。
（4） 其他指标 除上述指标外，有些指标难以量化，但在搭建用户画像时也需要注意。如：可解释性：标签需要有一定的可解释性，便于业务方面理解；可扩展性：标签需要有一定的可扩展性，方便后续标签的添加和维护
标签使用度
标签使用度=标签被引用使用次数/ 所有标签中被引用次数的最大值 + 标签被分析使用次数/ 所有标签中被分析使用次数的最大值 + 标签被调用次数/ 所有标签中被调用次数的最大值
标签关注度
标签关注度= 标签查看次数 + 标签收藏次数
标签应用效果
标签应用效果=标签CTR / 所有标签最大的CTR
数据仓库常见问题汇总
离线数仓数据源变更及应对方案
1：业务方的相关业务下线，表数据一直未更新
源头表未使用这种场景不会导致数仓任务报错，但是比较致命和浪费集群资源，可以在表入仓时，标记好相关表的更新频率，在线业务表，变更会比较频繁，字典表、码表之类的变更没那么频繁，可以针对在线业务表进行binlog监控，如果30天甚至更久都没有变化，可以发一个告警通知给相关方，并且创建需求备忘录，如果没有影响，则由项目负责人进行关闭。
2：业务逻辑变化，某些字段暂停使用
这种场景下只有通过监控字段的空值率来判断，关键字段空值率高了就告警。
3：业务新增字段。
新增字段对于数仓现有业务影响不大的，可暂时忽略，只需通知出来即可，但是数仓为了任务不报错，在开发数据同步任务时需要指定同步的字段。
4：业务删除字段。
删除字段这种情况数仓如果未提前做处理，必然会导致数仓报错，可在同步系统添加一个源表字段和数仓表字段的映射关系校验，发现源头没有的字段，数仓有的进行紧急告警。
5：业务新增业务，新建表。
新建表这种数仓不会有任何报错，可以在binlog监控到这种情况后，提示通知数据分析人员，可能有新增业务。
6：业务删除表。
业务删除表，如果数仓正在用这个表，任务未提前下线，数仓任务会报错,这种场景可以在拉数据前，先判断一下表是否存在。
总结
数据模型设计好以后，上游业务侧增加、修改或删除字段，需要从以下方面来保证：事前：与上游建立知会机制与协同流程，及时同步业务与模型变更；接管 ODS 层，控制源头，ODS 是业务数据进入数仓的第一站，是所有数据加工的源头，控制住源头，才能从根本上防止一个重复的数据体系的出现。事中：通过技术手段捕捉上游元数据与字典值变更，从而方便以后问题追踪与影响分析 对于这种变化，人工处理的话，就是手动在数仓对应的表中增加、修改字段，然后修改同步任务；这个最好可以搞成自动化的，比如，自动监控上游表结构的变更，变化后，自动去修改数仓中的表结构，自动修改同步任务。事后：通过事后复盘优化流程与迭代技术
数仓优劣指标化判断
O:数仓优劣判断; S:数据监控、元数据管理、业务流程的理解、预先计算好的中间表或者应用表; M:核心度量指标;
内部的评价标准主要是通过跨层引用率、表引用数、引用链路长度、表命名规范率、表迭代次数、数据泄露率、数据准时率、数据正确率等指标来判断， 外部主要通过”三易”来判断，易找、易查、易用，既数据找起来容易，无歧义，数据查询效率高，数据使用安全便捷，质量靠谱，具体可考虑通过以下指标来判断:数据查阅数、数据用户数占比、数据授权人数、数据服务业务数、自助取数平均耗时、自助取数生成平均耗时等。
实时数据仓库数据质量保证
数据质量平台主要需要支持时间字段延迟、空值监控、字段监控、数据一致性和自定义指标监控五种监控类型。
1、时间字段延迟 ：时间字段延迟实际是指数据的生产延迟或者写入延迟，是指数据从产生到写入kafka的延迟情况。实际的计算方式是数据写入kafka的时间（从消息header中获取的kafka LogAppendTime）减去用户配置的代表事件时间的字段时间。如用户配置的字段时间是11:50:00，写入kafka的LogAppendTime是11:50:01，则认为写入延迟为1秒。
2、空值监控：空值监控用于检查用户指定字段的空值率，超过阈值即报警。其计算方式也很直接，直接计算特定时间段内，指定字段空值的数量/总的数据条数。
3、字段监控：字段监控的处理逻辑更为简单，直接将字段的值（30秒的聚合结果）写入TSDB。主要使用场景是用来监控字段的值是否在预期的范围内。
4、数据一致性监控
端到端的exactly-once保证
数据去重
mysql-》ods 维护一张同步任务批次数据表，分别记录同步前和同步后该条数据是否落入这张表里。同步当前批次数据第一条或者最后一条数据：库名+表名+主键+时间戳+offset+MD5(整条数据的MD5)，同步后的库名+表名+主键+时间戳+offset+MD5(整条数据的MD5) 是否一致。ods --》dwd count(distinct id)计数
5、自定义指标监控：自定义指标监控是基于用户自定义的SQL计算结果进行的监控。用户可根据Flink SQL的语法，将需要监控的指标用SQL的形式表达出，然后对计算结果配置报警条件。
实时数仓如何验证指标结果正确
1：消息中间件是可以支持重复消费的，另起一个实时监控任务和实时计算任务的数据结果比对。
2：使用pulsar类消息中间件，完成一条离线的监控任务，离线与实时的一致性，需要保证使用数据源一致、加工业务逻辑与统计粒度一致，以及幂等输出。
OLAP模块
支撑的应用
即席查询(Ad-hoc Query)
BI
powerBI
superset
datart
davinci
metabase
springboot
选型
clickhouse
starrocks
presto
数据服务&数据应用
统一的数据服务
为什么要统一的 数据服务接口
如何实现 统一服务接口
自助查询和取数、 BI报表、指标体系 、标签体系
任务编排和调度 （若干个可用的开源工具）
Apache Airflow: 用于编排和调度工作流的平台，可用于创建和管理实时流任务。它提供了一个灵活的编程接口，可以定义任务依赖关系、工作流参数等;支持多种任务类型，包括MapReduce、Hive、Pig等
Apache Falcon: Apache Falcon是一个面向数据管道的任务调度和数据管理平台，可用于编排和调度实时流任务，帮助用户轻松创建、部署和管理数据管道，并支持多种数据处理需求
Apache Ambari： Apache Ambari是一个用于管理和监控Apache Hadoop集群的开源工具，提供了任务调度和编排功能，可用于实时流任务的编排和调度
Cloudera Manager: CM 是一个功能强大的管理平台，可以轻松地安装、配置和管理Apache Hadoop集群。它提供了丰富的监控、报警和自动化功能，可以帮助用户更好地管理和调度实时流任务
Apache DolphinScheduler 是一个分布式易扩展的可视化DAG工作流任务调度开源系统。适用于企业级场景，提供了一个可视化操作任务、工作流和全生命周期数据处理过程的解决方案。 Apache DolphinScheduler 旨在解决复杂的大数据任务依赖关系，并为应用程序提供数据和各种 OPS 编排中的关系。 解决数据研发ETL依赖错综复杂，无法监控任务健康状态的问题。 DolphinScheduler 以 DAG（Directed Acyclic Graph，DAG）流式方式组装任务，可以及时监控任务的执行状态，支持重试、指定节点恢复失败、暂停、恢复、终止任务等操作。
模型的评估标准
扩展性
新增加的模型是否和老的模型出现冲突
时效性
能否保证日常的sla（时效保障）
准确性
输出的指标数据质量能够保证
低成本
存储成本
计算成本
健壮性
业务快速更新迭代的情况下不会太影响底层模型
规范度
主题域归属
表归类率 = 有分层信息与主题域信息的表的数量占比
任务命名规范
复用度
模型引用系数：模型被读取并产出下游模型的平均数量
dw，dws下游直接产出的表的数量
完善度
汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例
同层level>2的占比等量化指标
快速响应业务方的需求
比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化
数据模型评分卡
人员规划和排期
业务模块的划分
工作量的划分以及分工
排期规划
人员配置
周期
每个人负责的内容
项目开发、自测、bug修复、演练、上线的起始时间
项目管理
项目进度跟进
开发、测试、仿真、bug修复进度和结果确认
进度checklist
相关开发人员确认
对接人员确认
团队负责人确认
新增需求
评估工作量
需求评审
通过、重新规划，并做好排期
跟进进度，做好确认
放置在2.0阶段开发
需求无意义，暂不做
需求变更
发起需求变更流程
变更需求评审
不通过，驳回
通过，合并需求
评估工作量
做好规划和排期
团队建设
面试招聘
人员培训
业务、技术分析
相关工作的分配
