Superset和grafana

数仓架构师需要具备基础平台搭建、业务逻辑开发、人员规划和排期、数据治理、运维和监控、架构迭代、全方位优化的能力。

1、基础平台搭建

基层平台搭建包括熟悉业务、数据规模测算、技术架构设计、机器节点规划、高可用多机房部署。

1.1、熟悉业务

1.1.1、业务的战略目标或愿景是什么

单位负责人或实际控制人的真实想法。 

1.1.2、业务线或产品线有哪些

1.1.3、梳理各业务场景、业务架构

1.1.4、业务现状如何，有哪些业务痛点

例如运营方想通过用户标签或产品标签快速圈选目标人群、目标商品，但痛点是取数的链路长、取数效率低。可以从几方面解决：

（1）采用数据仓库解决方案——提前与业务方沟通，把所需数据提前准备好，存放在数仓的ADS层（由DIM和DWS加工得到），供业务方自助取数。

（2）采用湖仓一体解决方案——仓外挂湖，也就是把数据仓库中的表数据与hive、hudi或iceberg中的数据做链接，即数仓表的外表。可行的技术栈是：Doris作数仓，Hudi或Iceberg作数据湖（DataX+FlinkCDC实现全量+增量业务数据导入湖中），在Doris建模时链接湖中的数据。

1.1.5、需求收集

与业务方开会，收集业务方的各种需求。在符合战略目标或愿景的前提下，为收集到的各种需求分配优先级，然后根据资源限制(人力资源、资金、开发复杂度)把最高优先级的数量做限制，例如当前把最急需的需求控制在3个以内

1.1.6、需求调研

1）业务调研

业务调研的流程分三个步骤：

（1）输入调研模板。

（2）针对产品和运营进行调研。

（3）归纳产出：业务过程&数据域。

2）需求分析

需求分析的三个步骤：

（1）输入调研模板，研究报表&数据体系。

（2）与分析师&运营讨论收集信息。

（3）归纳产出：指标体系

3）数据调研

（1）数据调研需要做好数据探查工作，需要了解数据库类型，数据来源，全量数据情况及数据每年增长情况，更新机制；还需要了解数据是否结构化，是否清洗，是接口调用还是直接访问库，有哪些类型的数据，数据结构之怎样的。

（2）数据开发，模型建设之前，先了解数据结构，数据内容，数据特性，对数据有一个整体把控

（3）探查一下本次需求能不能实现，怎么实现，有没有隐藏bug，数据质量如何

1.1.7、产出

A）概念图：业务架构图

各业务模块之间、业务内部子模块之间的交互关系（层级关系、包含关系、平行关系、主次关系）

B）逻辑图：业务关联（E-R模型+流程图）

1）概念模型：E-R图（Entity-Relationship Model）

作用：

E-R模型用于描述产品或业务内部各模块之间的关系，能帮助快速学习业务逻辑和产品逻辑，也能从中发现业务或产品中存在的问题

绘制E-R图步骤：

1，确定对产品或业务实体有重大影响的实体。例如：用户、订单、商品、优惠券或积分、物料、耗材  

2，确定能影响到产品或业务正常运转的关键属性。随着业务或产品发展，可能有一些属性独立出来变成实体，例如“收货地址”  

3，确定实体之间的关系。需要多人配合一起讨论，找出实体之间存在的所有联系

E-R图的使用建议： 

1，在新接触一个业务或产品时，先使用 E-R 图帮助建立相关的概念，为下一步要绘制的流程图预备知识

2，在落实到新产品或新业务开发时，通过E-R图理清一款产品或一项业务需要哪些功能、服务于哪些用户、需要搭配什么系统

2）逻辑模型：流程图 （对业务的发展变化过程可视化）

流程图与 E-R 图的区别：

流程图关注的是整件事情的各种处理过程以及各过程之间的逻辑关系和时间顺序，所以流程图关注的是动态的事情，E-R图关注的是最终态的事情。下面解释为什么：  例如一个“订单”实体，其中的一个属性“订单金额”由当前订单下的商品数量、单价、优惠券、下单时间共同决定，由于下单商品数量会增减，优惠券组合也不同，而且用户下单时间也不固定，所以直到用户下单的一刻“订单金额”属性的值才能确定。整个下单过程就是动态的、变化的。

绘制流程图的六个元素：

(1) 参与者：  可以是用户、部门、系统、定时任务

(2) 活动：  做的事情、任务、活动，这些内容是流程图要重点展示的

(3) 次序、顺序：  用箭头表示活动或环节的先后发生顺序和依赖关系。由于有并行的任务，所以有同向的多个箭头；并行之后也可以在某个环节合并成为一个环节，所以有汇合的箭头

(4) 输入：  活动或任务的输入可以是依赖的信息或者上游的任务。依赖的信息举例：为用户推荐商品，就必须依赖用户最近的浏览历史、购买历史

(5) 输出：  每个活动或任务结束后产生的结果。当前活动或流程的输出可以作为下一个流程的输入，可以向多个活动或流程输出结果

(6) 标准化：  就是用标准的符号表示流程图的内容。例如矩形表示活动或流程，圆角矩形表示整个流程图的开始或结束，箭头表示活动之间的顺序，菱形表示数据

带泳道和阶段的流程图：

当业务流程涉及几个阶段，参与方涉及多人、跨部门，并且需要让每个参与方清楚各自负责的步骤，此时需要带泳道和阶段的流程图。下面展示了两个实例

物理模型：  继概念模型和逻辑模型之后，物理模型的数据库、表映射业务架构。

1.2、数据规模测算

1.2.1、数据规模测算

1）根据数据平台的数据特点来预估

数据特点包括数据来源、种类、结构(结构化、半结构化、非结构化)、粒度、时效性。

2）根据存储容量和数据增长速度预估

2.1）根据数据平台现有的存储容量和数据增长速度，可以初步预估未来一段时间内的数据规模，以满足业务需求、避免资源浪费和过度投资，合理分配存储、计算和网络带宽资源。

2.2）收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算。

3）需要考虑到数据质量问题

有质量问题的数据包括：未去重的数据、无效的数据、错误的数据等。这些有问题的数据会影响存储和计算规模。

4）结合业务场景和实际需求进行预估

根据业务场景和实际需求，结合前面三步的分析结果，对数据平台的未来数据规模做预估；同时，要持续监控各种资源的使用情况，以便调整和优化资源的分配。例如，如果业务场景中涉及到海量数据的处理和分析，那么数据平台的存储容量和处理能力就需要相应提高，也就是考虑平台的可扩展性。

5）考虑数据安全和隐私保护问题

需要考虑数据的加密、备份、恢复等方面对存储和处理的制约，还有相关法律法规对数据安全和隐私保护的要求。

1.2.2、任务数评估

方法概述

基于历史任务做分析，统计各类数据处理任务的数量波动，从中发现趋势，根据趋势做预估，如果是新建的平台尚未有历史任务，那么用以下方法：根据该平台将要承载的业务需求做预估，例如预估固定报表有几张、制作每张报表所需的数据量是多大、每个报表的加工链路有几个算子、集群的资源是多少，然后在该平台模拟一些数据处理任务，以观察任务运行期间对资源的消耗情况。当发现集群在同时运行 XXXX个任务时占满了集群的所有资源，此时的 XXXX 值可作为最大并发任务数。

步骤

1）理清数据处理需求：根据数据平台的处理需求以及之前做的数据规模预估结果，粗略算出需要运行的任务类型和数量，包括OLAP任务、批处理任务、流处理任务的数量和任务周期。

2）考虑数据来源和多样性：根据数据的来源、格式、大小、频率等，粗略估算需要运行的任务数量和类型。

3）根据数据平台的数据处理能力评估：也就是要根据容量评估，具体包括计算资源、存储资源、网络资源等，以确定能够同时运行的任务数量和类型。

4）要考虑任务调度和并发控制：这是为了保证所有任务按照预定顺序和优先级运行，避免任务之间的冲突和竞争。

为什么要考虑任务之间的依赖关系和并发控制？第一个原因，如果任务之间的依赖关系处理不当，会导致任务执行效率低或者出现错误，就提高整体的作业数量。第二个原因，如果并发控制不好，会导致任务之间的竞争和冲突，从而降低任务执行的稳定性。

1.2.3、容量评估

如何评估

收集历史数据，包括计算资源、存储资源、网络带宽的使用量和峰值，以便掌握业务对资源的需求波动情况，然后进行容量规划和估算。

存储资源

单条数据大小*日数据量*周期*副本数。

• HHD
• SSD

机器存储节点数

数据总量/（单台服务器总磁盘大小*0.8）

cpu

单台配置推荐64核，cpu和内存之间建议1：2或者1：4

内存

单台推荐128G或256G

网络带宽

10亿级别，千兆网卡可以支持，推荐万兆网卡

大数据机器集群规划

1.2.4、数据特征

• 数据格式
• 数据压缩
• 序列化方式
• 文件类型

1.2.5、产出文档

cpu内存、核数、单块磁盘大小、挂载数量、机器数量、成本预算相关文档

1.3、技术架构设计

1.3.1、可选的数据平台架构

1）lambda架构：  离线数据链路；  流式数据链路

2）kapa架构： 批流一体

pulsar+flink

flink+MPP

• 存算一体
• 存算分离

3）IOAT架构

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，让客户端传送数据的同时马上进行反馈，而不需要所有事件都要到中央端处理之后再进行下发。

4）LakeHouse架构：湖仓一体

1.3.2、如何选型

1）考虑数据架构适用的数据处理场景，例如离线数仓、实时数仓、批流一体、湖仓一体、DataOps

2）同一功能的不同框架之间的对比：适用的数据处理场景、更新是否频繁、数据处理(查询或写入)性能、容错性、是否易用、exactly-once、是否方便运维(包括故障排查）

3）选定框架或组件之后，做好相关的压力测试(最好做一次全链路压测以提前发现薄弱环节)，然后出具压力测试报告

4）产出：生成《选型建议》，涵盖四项内容：

一、各框架或组件的对比文档

二、从第3步的压测报告中选取各项关键指标的对比结果，做出选型建议

三、技术架构图

四、完整的Demo演示：  数据的全链路处理流程演示

1.3.3、架构实现方式

1）Hadoop生态

2）MPP

3）Hadoop + MPP

4）数据湖+MPP

1.4、机器节点的规划

1）集群各节点规划

2）安装、部署和运维

3）参数调整

4）LDAP、权限管理

1.5、高可用多机房部署

1）多机房规划

2）容灾、备份

2、业务逻辑开发

2.1、数据采集模块

2.1.1、采集方式

1）离线定时采集：

sqoop

2）实时采集、增量采集：

• 日志：flume、logstash
• 数据库：dataX、flinkCDC、（canal、maxwell）、cloudCanal、tis

3）离线、实时、增量采集：

SeaTunnel 

4）可配置的流任务开发平台 (在web页配置)

对接kafka满足大部分的流处理需求任务。

例如：埋点数据上报到kafka之后，只需要在web   页面配置flink的源topic、字段声明及加工逻辑、sink目标表、数据校验规则、告警规则。

2.1.2、一致性保证 (如何确保ExactlyOnce)

1）框架本身是否已实现

kafka 是否已实现、如何实现：  kafka的客户端支持消息写入topic的幂等性

Flink 是否以实现、如何实现：

• 两阶段提交事务
• 预写日志事务
• lableid+state+checkpontInterval flush

2）流处理任务的监控

数据源端(kafka)监控指标有哪些：

sink端(湖、仓中的表)监控指标有哪些：

2.2、数据仓库建设

2.2.1、分成哪几层，每层的功能是什么

2.2.2、分层原则

（1）清晰简洁原则：分层设计应该简洁明了，每个层次的功能和任务应该清晰明确，不重复，避免冗余和混淆。

（2）独立可扩展原则：每个层次应该是独立的，可以单独进行扩展和修改，而不会对其他层次造成影响。

（3）数据一致性原则：分层设计应该保证数据的一致性和完整性，确保数据在不同的层次之间能够正确地传递和转换。

（4）性能和效率原则：分层设计应该考虑到数据的查询和分析性能，合理地设计和构建汇总层，以提高数据的查询速度和分析效率。

（5）灵活性和可用性原则：分层设计应该提供灵活的数据查询和报表功能，以满足用户的不同需求和要求。

2.2.3、模型选择

维度模型（自下而上）

• 星型模型
• 雪花模型
• 星座模型

ER模型

• 3NF

Data Vault模型

• Hubs：表示实体或业务概念
• Links：表示实体之间的关系。
• Satellites：存储描述实体和关系的属性数据。

Anchor模型

2.2.4、模型设计原则

高内聚，低耦合

所谓的"高内聚低耦合"是指同一个主题内部高内聚，不同主题之间低耦合。

模型分离

建立核心模型和扩展模型体系。在业务建设过程中，我们通常会对一些核心业务建设核心模型，在核心模型中的字段主要用来支撑一些通用的主流的核心业务，同时也会针对一些特殊和定制化的少量需求建设扩展模型，在这种情况下，我们应当避免将扩展模型中的字段侵入到核心模型中，以免破坏核心模型架构的可维护性和通用性。

公共处理逻辑下沉

越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。

成本与性能平衡

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

数据可回滚

处理逻辑不变，在不同时间可多次运行，多次运行如果结果不一致要明确原因。

一致性

具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。

命名清晰、可理解

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

2.2.5、模型阶段性划分

业务模型

业务模型主要解决业务层面的分解和程序化

(1) 划分业务：根据业务部门进行划分,理清部门之间的关系.

(2) 熟悉业务：了解详细业务逻辑和数据处理逻辑,提供业务/数据处理流程文档、数据源访问信息.

(3) 明确数据需求：提供页面原型、需求文档、指标口径文档：①用户查询方式：导出到数据库，导出文件，提供数据服务； ②用户查询频率及数据延迟；③历史数据保存期限。

(4) 项目开发评估：确定项目人员分配、项目周期，评估项目风险。

领域模型

对业务模型进行抽象处理

（1）运用实体建模法，将业务模型抽象化，合并类似的概念，细化概念；

（2）将业务抽象成实体、事件和说明这三部分，理清实体与实体之间的关联，生成概念模型并整理为ER图。

（3）主题域的划分

逻辑模型

将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化：

（1）实例化每一个抽象的实体，并丰富实体的一些细致的属性。

（2）找出抽象实体间的联系，并将其实例化。

（3）找出抽象事件的关系，并对其进行说明。包括表的结构和属性、表之间的关系。

（4）提供与生产一致版本的数据结构，准确完善的数据字典，符合分析需求的样本数据;并能对样本数据分析中的问题进行及时准确的回复跟踪。并产出逻辑模型文档

物理模型

解决逻辑模型针对不同关系型数据库的物理化以及性能问题

数据结构性质、表的存储和压缩：

• ETL工具
• 数仓组件
• 代码开发
• 脚本编写
• 性能要求
• 任务调度
• 性能优化

业务模型主要解决业务层面的分解和程序化，领域模型是为了建立实体以及它们的属性和关系。如：主题域的划分、维度、事实 逻辑数据模型定义了数据元素的结构，并设置了它们之间的关系。如：表的字段信息、表之间的逻辑关系 物理数据模型描述了数据模型在数据库中具体的实现方式。如：代码设计与开发、性能优化，日志收集，表的存储与压缩格式。。。。

2.2.6、建模流程

流程

1.系统边界关系模型设计

• 要做的决策类型有哪些?
• 决策者感兴趣的是什么问题?
• 这些问题需要什么样的信息?
• 要得到这些信息需要包含原有数据库系统的哪些部分的数据?

2、事件流产生业务模型设计

3、数据域的划分

数据分域分为三个步骤：收集、提炼、归纳。1. 收集：业务数据需求、存量数据梳理 2. 提炼：业务过程、业务梳理 3. 归纳：数据域

4、总线矩阵

• 主题域
• 业务过程
• 维度
• 颗粒度
• 度量值

5、明确指标统计

• 统一指标命名
• 统一指标计算口径
• 指标拆解、指标分级：原子指标、派生指标（一级、二级）、衍生指标（一级、二级）
• 指标生命周期管理
• 统一外部数据输出归口
• 建立指标字典

6、规范化定义

（1）词根规范：

行业术语(一般指翻译不太准的)：

• 数据分析师协作
• 业务方协作

词根评审

• 是否必要
• 是否存在

词根维护

• id
• 所属分类
• 英文词根
• 中文词根
• 使用频率
• 数据类型
• 长度
• 责任人
• 评审日期

（2）数据字典

用途

数据字典是各类数据描述的集合 -数据字典是进行详细的数据收集和数据分析所获得的主要结果 -数据字典在数据库设计中占有很重要的地位

内容

数据项；数据结构；数据流；数据存储；处理过程。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

• 字典数据表模板
• 字典类型表模板

（3）命名规范

• 库命名
• 表命名
• 指标命名
• 任务命名

（4）建模评审规范

指导理论：

数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性维度和事实。参考阿里onedata建模

模型层次：

参考数仓分层逻辑

实施步骤：

1）选择已经确定业务进行梳理，了解业务流程（参考产品数据文档）

2）ER关系：输出ER关系图，了解实体关系，验证数据是否一致 PDM

3）现有数据流梳理：输出数据流程图 PDM

4）结合提数模型，指标，产品需求文档等，优化目前模型：基于上一步PDM输出优化模型，记录优化点；（数据流跟数据模型结合）

5）基于以上文档进行评审，不通过进行迭代

6）评审通过后进行开发，上线：开发在目前系统上实施，优先级降低，任务时间戳开

（5）开发规范

开发原则：

• 支持重跑
• 数据生命周期合理
• 任务迭代不会严重影响任务产出时间

公共规范：

• 所有单词小写
• 单词之间下划线分割（反例：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 转化函数。

（6）明细、汇总模型设计

宽表加工：宽表设计的多宽合适

分区

压缩

建模步骤：

1、确定业务过程

业务过程是业务活动事件，如下单，支付，退款都是业务过程，把这些过程转换为事实表中的事实，多数事实表只记录某一业务过程的结果。业务过程的选择非常重要，因为业务过程定义了特定的设计目标以及对粒度、维度、事实的定义。

2、声明粒度

声明粒度是维度设计的重要步骤，粒度用于确定某一事实表中的行表示什么。在选择维度或事实前必须声明粒度，因为每个维度或事实必须与定义的粒度保持一致。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。我们要预判所有分析需要细分的程度，从而决定选择的粒度。

3、确定维度

维度是度量的环境，用来反映业务的一类属性。这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。用于分析时进行分组和筛选。

4、确定事实

事实 涉及来自业务过程事件的度量，基本上都是以数据值表示。事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。在设计过程中，可以选择不同类型的事实表，它们有各自的适用场景

1）事务型事实表

• 一种详细记录某个具体事务全过程的事实表
• 它保存的是各业务过程的原子操作事件，即最细粒度的操作事件
• 只有在事件发生时产生记录
• 事实可加：如订单金额

2）周期快照事实表

• 以具有规律性的、可预见的时间间隔来记录事实
• 可以清晰地反映业务数据的周期性变化
• 用快照采样状态
• 事实半可加：最大值、最小值、平均值...
• 主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。

3）累计快照事实表

• 基于一个业务流程中的多个关键业务过程联合处理而构建的事实表
• 累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。
• 用于时间跨度不确定的不断变化的业务流程
• 每行代表一个实体的生命周期
• 事实不可加

（7）模型验证和测试

（8）任务编排与上线

依赖设计：

将ETL抽象为多个相互依赖的代码节点形成上下游依赖关系，要求如下：一个节点仅产出一张表，一张表仅由一个节点产出。下游节点的输入数据来自于上游节点的产出数据。多并行、少串行（在分布式系统下可发挥其优势）。

运行周期：

如果数据研发的场景是在常见T+1离线计算场景，则应将不同调度任务按照实际业务需求，赋予小时、日、周、月和季度等不同的调度粒度。

设置基线：

在传统T+1（每日计算的是前一日产生的业务数据）的场景下，数据理应在第二天某个时间点按时产出以支撑BI或其他应用场景，因此应设置如下基线报警策略。最终产出任务基线：规定产出最终数据的任务必须在公司规定的X点X分完成，否则视为破线（同时推送相应报警）。中间任务报警：产出最终数据的任务的上游任务应稳定、按时运行完成。如果出现出错、变慢（运行时间明显长于历史过往平均运行时间）等可能影响最终任务完成时间的事件，则应第一时间推送报警给第一任务责任人。

设置优先级：

基于有限的计算资源来设置任务优先级，以保证在已有资源被充分调配利用的情况下，可以按照顺序产出数据，保证重要任务的准时产出。调度设计完成后，需要产出调度设计文档。

2.2.7、指标管理平台

• 指标字典
• 维度管理
• 数据集管理
• 指标需求
• 业务域管理
• 权限管理

指标管理的几大步骤：

建立指标生产协同机制：指标的诞生要经过需求申请、审核、数据开发、上线应用流程，收口指标创建过程，避免指标建设的随意性带来的“污染”

制定指标命名、口径说明规范：按照原子指标+业务限定+统计维度的方式，将规则集成到平台内，通过系统规则来把控指标输出。

指标字典线上化：解决线下文档(excel)管理指标存在的共享难、更新不及时、权限管控缺失等问题

指标数据逻辑绑定：即除了维护指标的业务元数据外，还要建立指标的技术元数据，指标数据从哪个模型、哪个字段、何种计算逻辑得到。

指标输出：指标管理最大的价值还是为数据产品提供数据输出。

2.2.8、标签体系建设

1）首先，收集业务方的标签需求， 再根据战略目标、实现的复杂度、ROI来确定各种标签的优先级，为当前阶段搭建标签体系

2）ID-Mapping

• 全局唯一ID关联
• Hbase+redis
• sparkGraphx
• 图数据库nebula-algorithm
• 机器学习+图模型

ID-Mapping在心动公司探索实践

3）标签的开发

3.1）离线标签：

规则类标签

挖掘类标签

• 标签相似度计算
• 标签组和计算
• 朴素贝叶斯
• NLP

预测类标签

统计类标签：按照实际业务需求、场景划分分类主题，标签粒度

3.2）实时标签

3.3）用户特征库加工

3.4）用户分群、人群圈选

bitmap+物化视图

3.5）打通数据服务层

4）标签存储方案

存储方案：

• Hive
• hbase
• es
• starrocks

表设计：

宽表

主要适用于前导流程为离线ETL，模型相对固定可以基于宽表模型构建物化视图，加速圈选查询效率 另外宽表模型，对于基于UID查用户明细，应对高并发场景也比较友好

高表

适用于前导为实时ETL，模型变动较快，如当日有新增属性标签， 纵表模型避免了做schema change相对灵活 缺点：难以命中物化视图，建表时也需要考虑数据倾斜相关难点

宽表+高表

主键模型宽表+Starrocks高表（聚合模型）====》合并成宽表

5）标签的生命周期

涉及标签的新增、修改、删除，标签的上线、下线；记录标签的增删改记录；监控标签的访问频次以便及时删除标签数据、节省存储成本

标签权重计算：

• 行为类型权重（根据业务活动的重要性划分）
• 时间衰减系数
• 用户行为次数
• TF–IDF计算标签权重

总结：用户标签权重=行为类型权重×时间衰减×用户行为次数×TF–IDF计算标签权重

6）评估标准

（1）准确率

标签的准确率指的是被打上正确标签的用户占被打上标签用户的比例。准确率是用户画像最核心的指标，一个准确率非常低的标签是没有应用价值的。准确率一般是对每个标签分别评估，多个标签放在一起评估准确率是没有意义的。

2）覆盖率

标签的覆盖率指的是被打上标签的用户占全量用户的比例。覆盖率既可以对单一标签计算，也可以对某一类标签计算，还可以对全量标签计算。人均标签数是指所有被打上标签的用户的总标签数除以被打上标签的用户数。覆盖率和准确率是一对矛盾的指标，需要对二者进行权衡，一般的做法是在准确率符合一定标准的情况下，尽可能地提升覆盖率。

3）时效性

有些标签的时效性很强，如兴趣标签、出现轨迹标签等，有效期可能只有一周或一个月。有些标签的时效性很差，或者说稳定性很强，如性别、城市等，可以有一年到几年的有效期。对于不同的标签，需要建立合理的更新机制，以保证标签时间上的有效性。

（4） 其他指标

除上述指标外，有些指标难以量化，但在搭建用户画像时也需要注意。如：可解释性：标签需要有一定的可解释性，便于业务方面理解；可扩展性：标签需要有一定的可扩展性，方便后续标签的添加和维护

2.3、OLAP模块

2.3.1、支撑的应用

1）即席查询(Ad-hoc Query)

2）BI

• powerBI
• superset
• datart
• davinci
• metabase

3）springboot

2.3.2、选型

• clickhouse
• starrocks
• presto

2.4、数据服务&数据应用

1）统一的数据服务

为什么要统一的 数据服务接口

如何实现 统一服务接口

2）自助查询和取数、 BI报表、指标体系 、标签体系

2.5、任务编排和调度 （若干个可用的开源工具）

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）流式方式组装任务，可以及时监控任务的执行状态，支持重试、指定节点恢复失败、暂停、恢复、终止任务等操作。

2.6、模型的评估标准

1）扩展性

新增加的模型是否和老的模型出现冲突

2）时效性

能否保证日常的sla（时效保障）

3）准确性

输出的指标数据质量能够保证

4）低成本

• 存储成本
• 计算成本

5）健壮性

业务快速更新迭代的情况下不会太影响底层模型

6）规范度

• 主题域归属（表归类率 = 有分层信息与主题域信息的表的数量占比）
• 任务命名规范

7）复用度

• 模型引用系数：模型被读取并产出下游模型的平均数量
• dw，dws下游直接产出的表的数量

8）完善度

• 汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
• 跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例
• 同层level>2的占比等量化指标
• 快速响应业务方的需求
• 比较好的模型，使用方是可以直接从该模型获取所有想要的数据的，如果dws，ads，dm层直接引用ods层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化

9）数据模型评分卡

3、人员规划和排期

3.1、业务模块的划分

3.1.1、工作量的划分以及分工

排期规划：

• 人员配置
• 周期
• 每个人负责的内容
• 项目开发、自测、bug修复、演练、上线的起始时间

3.2、项目管理

3.2.1、项目进度跟进

开发、测试、仿真、bug修复进度和结果确认

3.2.2、进度checklist

相关开发人员确认

对接人员确认

团队负责人确认

3.2.3、新增需求

评估工作量

需求评审：

• 通过、重新规划，并做好排期（跟进进度，做好确认）
• 放置在2.0阶段开发
• 需求无意义，暂不做

3.2.3、需求变更

发起需求变更流程

变更需求评审：

• 不通过，驳回
• 通过，合并需求（评估工作量，做好规划和排期）

3.2.4、团队建设

面试招聘

人员培训

业务、技术分析

相关工作的分配

4、数据治理

4.1、元数据管理

4.1.1、元数据分类

业务元数据（模型之上）：

1、业务定义，业务术语解释等，比如UUID表示啥？

2、业务指标名称、计算口径、衍生指标等

3、业务引擎的规则（比如身份证号码校验规则），数据质量的检验规则、数据挖掘算法

4、数据的安全等级、数据的分级、脱敏

技术元数据（模型实体）：

1、数仓的数据库表名称、列名称、字段类型、长度、约束信息、数据依赖关系等

2、数据存储类型、存储位置、存储格式、是否压缩、压缩格式、文件大小等

3、库表字段级血缘关系、sql脚本信息、ETL信息、接口信息等

4、调度依赖关系、调度信息、任务进度、数据更新频率

操作元数据（模型操作）：

1、数据所有者、归属group、使用者。比如哪些人申请了读写权限

2、数据的访问方式，访问时间、访问限制、变更记录

3、数据的访问权限，组和角色关系

4、数据处理作业的结果、系统运行日志

5、数据备份、归档、归档人、归档时间...

4.1.2、元数据应用

1）数据地图

数据地图整合集市一级和二级主题分类

2）业务系统数据字典

支持业务系统元数据存储和查询功能

3）场景化搜索

提供hive数据库表和字段的列表式查询

4）血缘分析

显示数据库、表和字段上下游依赖可检索和下载

4.1）血缘收集的三种方式：

• 通过静态解析 SQL，获得输入表和输出表；（静态解析 SQL，可以使用 Antlr4 仿照 Hive 的 SQL 解析来实现，但是不能保证 SQL 的准确性，因为任务都没有执行。）
• 通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
• 通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。（审计日志）

4.2）常见血缘工具

• atlas
• metacat
• datahub

4.3）作业运行状况

支持表对应作业的运行ID、运行日志和状态

4.4）数值分布

提供多维度字段的属性值分布情况

4.5）变更通知

支持元数据变更时告警和通知

4.6）hive目录

提供hive数据库表和字段的列表式查询

4.2、数据质量

4.2.1、稽核维度

• 规范性
• 完整性
• 一致性
• 关联性
• 及时性
• 真实性
• 准确性
• 唯一性

4.2.2、保障机制

（1）事前预防

• 数据探查
• 梳理表字段
• 制定资产等级
• 制定数据质量标准
• 制定检验规则

（2）事中监控

• 针对不同的表配置不同的DQC规则。DQC规则分为表级，字段级和自定义三种。
• sql校验
• 监控原始数据质量
• 监控数据中心质量
• 指标波动稽核
• 异常告警

（3）事后改善

• 修复数据质量问题
• 收集数据质量需求
• 完善数据质量管理制度
• 完善数据质量标准
• 表评分算法
• 数据质量管理系统报表查询
• 订阅

4.2.3、实施流程

质量需求：发现数据问题；信息提报、收集需求；检核规则的需求等。

提炼规则：梳理规则指标、确定有效指标、检核指标准确度和衡量标准。

规则库构建：检核对象配置、调度配置、规则配置、检核范围确认、检核标准确定等。

执行检核：调度配置、调度执行、检核代码。

问题检核：检核问题展示、分类、质量分析、质量严重等级分类等。

分析报告：数据质量报告、质量问题趋势分析，影响度分析，解决方案达成共识。

落实处理：方案落实执行、跟踪管理、解决方案Review及标准化提炼。

知识库体系形成：知识经验总结、标准方案沉淀、知识库体系建设。

4.3、数据标准

4.3.1、组成

1）业务

通过对实体数据的标准化定义，可以解决数据不一致、不完整、不准确等问题。通过对数据的标准化定义让数据在企业内有一个全局的定义，大大减少了各部门、各系统间的沟通成本。

2）技术

统一、标准的数据及数据结构是企业信息共享的基础；标准的数据模型和标准数据元为新建系统提供支撑，提示应用开发的实施效率；很大程度上数据质量管理都是依赖于数据标准，在数据标准之上才能定义数据质量。

3）管理

通过数据的标准化定义，明确数据的责任主体，为数据安全、数据质量提供保障

4.3.2、分类

1）基础数据标准

业务属性：标准主题、标准大类、标准中类、标准小类、标准编码、标准中文名称、标准英文名称、业务定义、业务规则、引用相关标准、标准来源和依据

技术属性：数据类型、长度、约束信息、数据格式、代码编码规则、取值范围

管理属性：标准定义者、标准管理者、标准使用者、标准版本、应用领域、使用系统

2）指标数据标准

业务属性：指标编码、指标中文名称、指标英文名称、指标主题、指标分类（原子、派生、衍生）、指标类型、指标定义、业务规则、指标来源、取数规则、统计维度、计算公式、显示精度、相关基础数据标准

技术属性：数据来源系统、指标使用系统、数据源表、数据类型、度量单位、取值范围、指标生成频度、指标计算周期、指标取数精度

管理属性：归口业务部门、业务负责人、技术负责人、指标权限范围

4.3.3、使用场景

建立统一的数据视图：建立通用的元模型规范，支持用户自定义扩展，对多源异构数据表进行信息抽象提取，形成统一的元数据层。所有的数据开发完成后发布到数据标准维护的统一的数据目录，通过不同维度的数据目录进行多维筛选，满足各类用户的检索需要，达到资产的可管、可用、可查的目标。

建立统一的数据认知：通过对多源异构数据的标准化描述，就算数据在不同系统的称呼千奇百怪，但是至少流入大数据的场景后就会统一描述，使管理方、开发方、使用方统一认知。

建立质量审核体系：在数据标准统一的前提下，我们就可以基于标准的元数据信息，进行质量的监控和审核，提升数据质量，更大化的体现数据价值

面向未来的数据治理：工具的终极目的都是为了降本提效。效率的提升要依靠流程规范，流程主够规范，在某种程度上就可实现流程自动化流转，所以数据治理如果要成为流程自动化、阶段智能化的阶段，那么就需要数据标准的支持。

4.3.4、设计原则

4.3.5、实施流程

1.制定目标和界定范围 

2.数据标准调研  

基础数据标准：

• 业务术语标准
• 命名规范标准
• etl开发标准

代码：

• 源系统字典维护
• 公共字典维护
• 源系统字典和公共字典的映射

应用标准：

• 维度管理
• 指标管理
• 标准流程管理

3.明确组织和流程  

4.数据标准编制与发布  

5.数据标准宣贯  

6.数据标准平台落地运营

4.4、数据安全

4.4.1、安全管控策略

4.4.2、安全从哪些方面建设

1）数据获取安全

能够支持数据获取需要经过申请与审批流程，保障数据获取安全。

2）数据脱敏

能够支持数据脱敏规则、脱敏算法及脱敏任务的管理及应用，一般情况下，脱敏方式有动态脱敏和静态脱敏两种

3）统一认证

定义数据安全策略，定义用户组设立和密码标准等

4）租户隔离

管理用户，密码，用户组和权限；

5）角色授权

划分信息等级，使用密级分类模式，对企业数据和信息产品进行分类

6）日志审计

审计数据安全，监控用户身份认证和访问行为，支持经常性分析

7）异常监控

指对账号异常行为的监控，如同一账号异地登录、同时多 IP 登录、多次重复登录等

8）数据分类分级

能够支持对数据资产安全进行敏感分级管理，并支持根据各级别生成对应的数据安全策略

5、运维和监控

5.1、运维·压力测试

5.1.1、大数据平台的压力测试

1）压力测试的对象

压测对象是数据管道，也就是数据在大数据平台的一个或多个系统中经过的完整路径。对数据平台来说，数据处理作业有多种：全量数据导入新表、高并发的增量导入任务、Ad-hoc查询、多个OLAP任务同时访问同一张数据表，等等。简单来说，数据平台的压测就是要获取平台处理批量作业、实时作业、交互查询时的响应延迟、吞吐量、服务可用性等性能指标。

2）压测的目的

检验系统的稳定性和吞吐量，尽早发现瓶颈环节，有利于对系统做精确的性能预期规划和容量规划

3）怎么做压测

方法：模拟一定数量的客户端对目标系统的各种操作，    对数据管道逐步施压，即逐步增加客户端并发数和数据量

数据管道各环节分别做压力测试

3.1）数据采集环节的压测

• 埋点数据(用户行为数据)的采集
• 业务数据(交易类数据)的采集

3.2）数据存储环节的压测

• 全量数据导入新表
• 增量数据周期性导入
• 在做全量、增量导入时，测试数据平台存储引擎的写入性能

3.3）数据加工环节的压测

3.3.1）批处理作业，例如全量数据导入、ETL或ELT

3.3.2）实时流处理作业

数据源端：

producer的消息发送性能测试：    producer在不同的消息发送策略(ack值)    情况下的发送频率（XXXX条/s）

数据缓冲带（kafka或pulsar）：

压测对象：    消息写入存储介质的性能（主要是指分区不同副本数量的写入性能）    、故障恢复速度

数据消费端：

不同consumer group数量的消费能力（xxxxx条/s）;观察反压机制的效果

3.3.3）Ad-hoc 交互式查询

3.3.4）数据交换，例如数据湖、仓之间的数据迁移

3.4）数据共享或数据服务环节

例如，不同的数据需求方和数据应用需要同时访问同一个数据资源，在满足数据访问权限要求的前提下观察数据访问的相关指标（例如响应延迟、QPS）

4）全链路压测

全链路压测通过标准：

• 确保作业输入读取延迟为毫秒级，且无反压。
• CPU利用率整体不超过 60%。
• 计算最终结果和既定目标保持一致。

5）有什么工具

数据管道各环节对应着不同的技术组件，有些组件原生提供了性能测试工具；如果组件没有提供工具就需要使用第三方工具

5.2、监控·指标有哪些

5.2.1、flink

• IO
• CPU
• Threads 监控指标
• GC监控指标
• Network监控指标
• Cluster监控指标
• Checkpointing监控指标
• latencyMarker
• waterMarkLag
• sourceIdletime
• taskNumber、slotNumber...

5.2.2、starrocks

5.2.3、kafka

5.3、监控·如何采集指标

1）可以采用restful方式采集

2）如果针对自己搭建的集群（例如基于EMR云主机搭建），而且运行的机器和业务也不多，那么可以考虑使用开源组件Ganglia+Nagios(ganglia做监控，nagios作告警)

3）如果要监控的机器多、业务多，那么考虑采用PGA（Prometheus+ Grafana+ Alertmanager）监控告警平台，PGA的优点是在数据采集选型、存储工具选型、监控页面配置、告警方式选择以及配置方面更加灵活，使用场景更加广泛，功能、性能更加优秀和全面

4）如果是买的云平台产品，例如阿里云、华为云的产品，这些产品会提供监控、告警平台

5.4、监控·如何展示

开源免费方案：后端用时序数据库Prometheus存储指标数据， 前端采用Grafana配置和展示

商业方案：  购买云产品（云产品提供监控和告警功能）

6、架构迭代

6.1、k8s

6.1.1、优点

1）统一运维。公司统一化运维，有专门的部门运维 K8S

2）CPU 隔离和安全性。K8S Pod 之间 CPU 隔离，实时任务不相互影响，更加稳定；

3）存储计算分离。Flink 计算资源和状态存储分离，计算资源能够和其他组件资源进行 混部，提升机器使用率；

4）弹性扩缩容。大促期间能够弹性扩缩容，更好的节省人力和物力成本。

6.1.2、缺点

6.1.3、开源大数据产品

CloudEon

6.1.4、native和operator的区别

6.2、湖仓一体

6.2.1、数据湖

数据湖解决了离线数仓什么问题？

数据湖能够解决离线数仓所面临的一些问题，包括但不限于以下几点：数据类型和格式的限制：离线数仓通常只能处理结构化数据，而无法承载其他类型的数据。数据存储和处理效率：离线数仓需要批量处理大量历史数据，因此需要在处理过程中进行数据移动和转换，导致处理效率低下。数据质量：离线数仓在数据处理过程中容易发生数据质量问题，如数据重复、数据丢失、数据错误等。数据湖读时模式在读取数据时才检验数据增量更新问题。相比之下，数据湖能够解决这些问题，因为它具有以下特点：多样化的数据类型和格式：数据湖能够承载各种类型和格式的数据，包括结构化数据、半结构化数据和非结构化数据。高容量和弹性的存储：数据湖在存储方面比较灵活，可以存储大量的数据，并且能够随时扩容和缩容。处理速度和效率：数据湖具有在大规模数据处理方面的优势，因为它可以利用云计算和分布式技术来实现数据的处理和计算，从而提高处理速度和效率。数据质量保证：数据湖中的数据质量能够得到保证，因为它具有数据治理的功能，可以对数据进行验证、清洗、补充和校准。

一款好的数据湖需要具备哪些功能？

1：能够存储任意数据，结构化、非结构化、半结构化的数据

2：数据具有可访问性和开放性

3：丰富的计算引擎，从批处理、流式计算、交互式分析到机器学习，各类计算引擎都属于数据湖应该囊括的范畴。

4：多模态的存储引擎。理论上，数据湖本身应该内置多模态的存储引擎，以满足不同的应用对于数据访问需求（综合考虑响应时间/并发/访问频次/成本等因素）。但是，在实际的使用过程中，数据湖中的数据通常并不会被高频次的访问，而且相关的应用也多在进行探索式的数据应用，为了达到可接受的性价比，数据湖建设通常会选择相对便宜的存储引擎（如S3/OSS/HDFS/OBS），并且在需要时与外置存储引擎协同工作，满足多样化的应用需求。

5：持记录级别的 update/delete，以增量更新数据；

6：支持并发读写和事务的 acid 特性；支持MVCC

7：支持历史版本回溯；

8：支持模式约束和演化 schema evolution,schema enforecement。

9：灵活的元数据管理和组织形式

数据中台、数据仓库、大数据平台、数据湖的关键区别是什么？

1）基础能力上的区别

数据平台：提供的是计算和存储能力 数据仓库：利用数据平台提供的计算和存储能力，在一套方法论的指导下建设的一整套的数据表 数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值 数据湖：一个存储企业各种各样原始数据的大型仓库，包括结构化和非结构化数据，其中湖里的数据可供存取、处理、分析和传输

2）业务能力上的区别

数据平台：为业务提供数据主要方式是提供数据集 数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表 数据中台：企业级的逻辑概念，体现企业数据产生价值的能力，为业务提供服务的主要方式是数据API 数据湖：数据仓库的数据来源 总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务，数据中台在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

数据湖、数据仓库、湖仓一体之间的区别？

湖仓一体是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能，打通数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动。作为新一代大数据技术架构，将逐渐取代单一数据湖和数据仓库架构。湖仓一体 兼具数据湖的灵活性与数据仓库的成长性。

几款数据湖产品

• Delta Lake
• iceberg
• hudi
• paimon

选型对比

开放文件格式

• fileFormat
• tableFormat
• oneTable    

批流一体和湖仓一体的区别

流批一体是需求，湖仓一体是方案。从 lakehouse 提出的背景看，湖仓一体一定是流批一体，但流批一体不一定基于数据湖，事实上很多传统数仓都具备流批一体的能力。Lakehouse 的设计原则分为功能性设计要素和非功能性设计要素两类。其中，功能性设计要素包括：一体化架构、存算分离、事务和数据一致性、全数据类型。非功能性设计要素包括：弹性高可用、加强的数据治理、尽量少的数据冗余、高并发支持、运维可观测性、高开放性。统一表格式（table format)

6.2.2、湖仓一体的几种方式

• 湖中建仓
• 湖上建仓
• 仓外挂湖

6.2.3、常见架构

• flink+paimon+olap mpp
• flink+MPP+数据湖存储

6.3、集群迁移、升级

6.3.1、迁移、升级工作评估

1）迁移工具

2）迁移方案

3）迁移测试

4）迁移实施

• 一致性
• 稳定性
• 容量、带宽等资源
• 权限
• 迁移过程中的容错保障

5）迁移结果验证

6.3.2、任务迁移、升级

flink任务升级：

1、找到需要停机的任务的job_id和yid

2、执行savepoint操作，需要带上job_id，yid和保存目标路径

3、停止旧的任务、提交新的任务时需要指定-s：savepoint目录

Starrocks任务升级

6.4、DataOps

7、全方位优化

7.1、数据倾斜优化

7.1.1、hive

（a）参数调节：hive.map.aggr = true 在map端部分聚合,hive.groupby.mapaggr.checkinterval = 100000在 Map 端进行聚合操作的条目数目

（b）参数调节：hive.groupby.skewindata=true 数据倾斜时负载均衡

（c）sql语句调节：join时选择key值分布较均匀的表作为驱动表，同时做好列裁剪和分区裁剪，以减少数据量

（d）sql语句调节：大小表join时，小表先进内存

（e）参数条件：开启mapSide join

（f）sql语句调节：大表join大表时，把key值为空的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，因此处理后不影响最终结果

（h）sql语句调节：大表join大表时，sort merge bucket join

（i）sql语句调节：聚合计算依赖的 key 分布不均匀时就会发生数据倾斜 用两次 group by 代替 count distinct 不同指标的 count distinct 放到多段 SQL 中执行，执行后再 UNION 或 JOIN 合并

（j）参数条件：set hive.optimize.skewjoin = true;

（k）参数条件：set hive.skewjoin.key = 250000000

（l）sql语句调节: group by维度过小：采用sum() ，group by的方式来替换count(distinct(字段名))完成计算。

7.1.2、spark

• 使用Hive ETL预处理数据
• 过滤少数导致倾斜的key
• 提高shuffle操作的并行度
• 两阶段聚合（局部聚合+全局聚合）
• 将reduce join转为map join（broadcast大变量）
• 采样倾斜key并分拆join操作
• 使用随机前缀和扩容RDD进行join
• 自定义分区器
• spark AQE

7.1.3、flink

1）keyBy 之前发生数据倾斜

• 提高任务并行度
• 使用shuffle、rebalance 或 rescale算子将数据均匀分配

2）keyBy 后的聚合操作存在数据倾斜

使用LocalKeyBy的思想：在 keyBy 上游算子数据发送之前，首先在上游算子的本地 对数据进行聚合后再发送到下游，使下游接收到的数据量大大减少，从而使得 keyBy 之后的聚合操作不再是任务的瓶颈。（本地聚合攒批之后发往下游）

3）keyBy 后的窗口聚合操作存在数据倾斜

两阶段聚合：

1、第一阶段聚合：key 拼接随机数前缀或后缀，进行 keyby、开窗、聚合 注意：聚合完不再是 WindowedStream，要获取 WindowEnd 作为窗口标记作为第二阶段分组依据，避免不同窗口的结果聚合到一起）

2、第二阶段聚合：去掉随机数前缀或后缀，按照原来的 key 及 windowEnd 作 keyby、聚合

7.2、背压问题

7.2.1、flink背压

1）反压场景

系统接收数据的速率高于它处理速率的效率，经常出现在促销、秒杀活动的场景。

2）危害

影响checkpoint的时长：checkpoint时间变长可能导致checkpoint超时失败。

影响state大小：可能拖慢checkpoint甚至导致OOM

3）反压原理

3.1）TCP反压

TCP 包的格式结构，有 Sequence number 这样一个机制给每个数据包做一个编号，还有 ACK number 这样一个机制来确保 TCP 的数据传输是可靠的，除此之外还有一个很重要的部分就是 Window Size，接收端在回复消息的时候会通过 Window Size 告诉发送端还可以发送多少数据。TCP 就是通过这样一个滑动窗口算法的机制实现 feedback。

1、跨TaskManager，反压如何从InputChannel到ResultSubPartition中

（1）当Producer速率大于Consumer速率的时候，一段时间后 InputChannel 的 Buffer 被用尽。InputChannel都向LocalBufferPool申请Buffer空间，然后LocalBufferPool再向NetWork BufferPool申请内存空间。当Network BufferPool也用尽的时候，这时 Netty AutoRead 就会被禁掉，Netty 就不会从 Socket 的 Buffer 中读取数据了。过不多久Socket的buffer也会被用尽（receive buffer），这是window=0发送给发送端。这时候socket停止发送。

（2）发送端的 Socket 的 Buffer 也被用尽（send buffer），Netty 检测到 Socket 无法写了之后就会停止向 Socket 写数据。所有的数据就会阻塞在 Netty 的 Buffer 当中，很快Netty的buffer也不能在写数据了，数据就会积压到ResultSubPartition中。和接收端一样ResultSubPartition会不断的向 Local BufferPool 和 Network BufferPool 申请内存。Local BufferPool 和 Network BufferPool 都用尽后整个 Operator 就会停止写数据，达到跨 TaskManager 的反压。

2、TaskManagern内部，反压如何从ResultSubPartition到InputChannel中

由于operator下游的buffer耗尽，此时Record Writer就会被阻塞，又由于Record Reader、Operator、Record Writer 都属于同一个线程，所以Record Reader也会被阻塞。这时上游数据还在不断写入，不多久network buffer就会被用完，然后跟前面类似，经是netty和socket，压力就会向上游传递。

缺点

只要TaskManager执行的一个Task触发反压，该TaskManager与上游TaskManager的Socket就不能再传输数据，从而影响到所有其他正常的Task，以及Checkpoint Barrier的流动，可能造成作业雪崩；

反压的传播链路太长，且需要耗尽所有网络缓存之后才能有效触发，延迟比较大。

3.2）基于Credit的反压过程

在每一次ResultSubPartition向InputChannel发送消息时，都会发送一个backlog size告诉下游准备发送多少消息，下游会计算 Buffer空间大小去接收消息，如果有充足的Buffer就返还给上游一个Credit告知可以发送消息的大小（图中ResultSubPartition和InputChannel之间的虚线表示最终还是需要通过Netty和Socket去通信，并不是直接通信）。

优点

基于credit的反压过程，效率比之前要高，因为只要下游InputChannel空间耗尽，就能通过credit让上游ResultSubPartition感知到，不需要在通过netty和socket层来一层一层的传递。

另外，它还解决了由于一个Task反压导致 TaskManager和TaskManager之间的Socket阻塞的问题。

4）定位反压

4.1）先把 operator chain 禁用，方便定位到具体算子。

通过 Flink Web UI 自带的反压监控面板；

• A.该节点的发送速率跟不上它的产生数据速率。
• B.下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率。

4.2）利用 Metrics 定位

• backpressure Tab页面
• inpoolUsage=floatingBuffersUsage+exclusiveBuffersUsage

5）反压原因及处理

分析方式

• 使用火焰图分析
• 使用 GC 分析器
• 线程Dump、CPU profile

常见原因及解决方式

1）数据倾斜

2）增加资源

通过增加资源（例如 TaskManager、CPU、内存等）的方式，来提高整个系统的处理能力，从而降低背压的风险。需要注意的是，增加资源是一种比较暴力的解决方式，并非所有情况都适用。

3）调整拓扑结构

增加缓存队列的长度，以容纳更多的未处理数据。   优化算子之间的并行度数量，避免出现单节点瓶颈。上下游并行度保持一致，合并算子链，使用共享资源槽位组。   使用窗口（Window）或 State 来帮助管理状态，降低内存占用率。   对于大规模任务，可以将任务拆分成多个小任务，以减少单个算子积压数据的风险。   checkpoint、状态后端等相关优化

4）外部组件交互

如果发现我们的 Source 端数据读取性能比较低或者 Sink 端写入性能较差，需要检查第三方组件是否遇到瓶颈，还有就是做维表 join 时的性能问题。例如：1）Kafka 集群是否需要扩容，Kafka 连接器是否并行度较低；2）HBase 的 rowkey 是否遇到热点问题，是否请求处理不过来；3）ClickHouse 并发能力较弱，是否达到瓶颈。关于第三方组件的性能问题，需要结合具体的组件来分析，最常用的思路：1）异步 io+热缓存来优化读写性能 2）先攒批再读写 维表 join 的合理使用与优化

7.3、小文件优化

7.3.1、hive合并小文件

1: 使用命令，自动合并小文件

ORC：concatenate;

Parquet: hadoop -jar  parquet-tools-1.9.0.jar  merge xxx xxxx

2：调整参数减少Map数量

#此参数是在mapper中将多个文件合成一个split作为输入 set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 默认

#每个Map最大输入大小(这个值决定了合并后文件的数量) set mapred.max.split.size=256000000;   -- 256M

#一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并) set mapred.min.split.size.per.node=100000000;  -- 100M

#一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并) set mapred.min.split.size.per.rack=100000000;  -- 100M

#设置map端输出进行合并，默认为true set hive.merge.mapfiles = true;

#设置reduce端输出进行合并，默认为false set hive.merge.mapredfiles = true;

#设置合并文件的大小 set hive.merge.size.per.task = 256*1000*1000;   -- 256M

#当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge set hive.merge.smallfiles.avgsize=16000000;   -- 16M

3：减少Reduce的数量

直接设置reduce个数 set mapreduce.job.reduces=10;

设置每个reduce的大小，Hive会根据数据总大小猜测确定一个reduce个数 set hive.exec.reducers.bytes.per.reducer=5120000000; -- 默认是1G，设置为5G

4：distribute by

insert overwrite table test [partition(hour=...)] select * from test distribute by floor (rand()*5);

5. 使用hadoop的archive将小文件归档

#用来控制归档是否可用set hive.archive.enabled=true;#通知Hive在创建归档时是否可以设置父目录set hive.archive.har.parentdir.settable=true;#控制需要归档文件的大小set har.partfile.size=1099511627776;#使用以下命令进行归档ALTER TABLE A ARCHIVE PARTITION(dt='2020-12-24', hr='12');#对已归档的分区恢复为原文件ALTER TABLE A UNARCHIVE PARTITION(dt='2020-12-24', hr='12');

7.3.2、spark合并小文件

1、通过repartition或coalesce算子控制最后的DataSet的分区数（Spark Core）

2、spark AQE

3、HINT方式

4、独立的小文件合并 set spark.sql.merge.enabled=true; set spark.sql.merge.size.per.task=134217728; 

5、spark自定义异步合并工具类

6、增加batch大小（spark streaming）

7、自己调用foreach去append（spark streaming）

7.3.3、flink合并小文件

1.自定义 PartitionCommitPolicy 'sink.partition-commit.policy.kind' = 'metastore,success-file,custom', 'sink.partition-commit.policy.class' = 'me.lmagics.flinkexp.hiveintegration.util.ParquetFileMergingCommitPolicy'

2. flink1.12之后新增的 table/SQL 参数配置 auto-compaction=true compaction.file-size=1024M

3. flink StreamingFileSink

4. flink+hudi

compaction.max_memory 

write.task.max.size

compaction.max_memory

compaction.tasks

compaction.async.enabled(MOR) compaction.trigger.strategy compaction.delta_commits

5.flink+iceberg

.rewriteDataFiles() .targetSizeInBytes(128 * 1024 * 1024)

7.4、业务层面

• 思考业务逻辑的合理性、可行性、必要性
• 计算量太大是不是必须的，是否可以减少参与计算的用户量或者时间跨度
• 计算逻辑是否过于复杂，是否可以简化
• 根据业务特性做业务数据架构的优化

7.5、计算资源优化

• 开启动态资源分配 dynamicAllocation
• cpu/内存配比建议同集群总资源配比，最大化利用集群资源
• 开启broadcastjoin，有数大数据平台环境默认关闭（内存限制），spark官方建议开启，可极大提高join小表性能
• 调节parallelism和repartition参数，提高并行度
• 开启convertMetastoreParquet，充分利用spark读parquet性能
• lateral view explode优化，多次explode前，手动触发shuffle操作，减少单分区处理数据量大小
• 控制输出文件大小，减少小文件数，减轻nn压力
• 充分利用spark3 AQE优化
• cbo优化器
• Sorted streaming aggregate
• query cache
• spark、hive、flink资源合理分配 shuffle参数优化

7.6、综合优化

• 存算分离
• 计算引擎切换
• 通过Node label完成资源隔离
• 通过cgroup完成cpu进程的绑定，使其得到充分的利用。
• 数据结构的合理设计

7.7、表设计、存储优化

1）建表前：表分区、分桶

2）压缩存储 第一级：格式压缩，基于不同表，压缩为orc/textfile+snappy格式，压缩率在30~48%左右；第二级：使用纠删码技术，从3副本减少到1.5副本，压缩率在50%左右。

3）建表前：生产级压缩编码设置（ZSTD）

4）数据写入前：数据布局优化技术

5）表后期生命周期维护

• 分区TTL策略
• 存储冷热分离技术
• 无效表（目录）下线机制

6）建立数据共享方案

7）bitmap

8）表模型选择

7.8、sql、代码优化

1）列裁剪，避免select *

2）分区裁剪，使用分区字段过滤

3）条件限制

4）谓词下推

5）map端预聚合

6）大key的过滤

7）打散倾斜key

8）合适的join方式

8.1）Broadcast Hash Join

仅支持等值连接，join key不需要排序 支持除了全外连接(full outer joins)之外的所有join类型 Broadcast Hash Join相比其他的JOIN机制而言，效率更高。但是，Broadcast Hash Join属于网络密集型的操作(数据冗余传输)，除此之外，需要在Driver端缓存数据，所以当小表的数据量较大时，会出现OOM的情况 被广播的小表的数据量要小于spark.sql.autoBroadcastJoinThreshold值，默认是10MB(10485760) 被广播表的大小阈值不能超过8GB 基表不能被broadcast，比如左连接时，只能将右表进行广播。

适合很小的表和大表join

Broadcast阶段 ：小表被缓存在executor中 Hash Join阶段：在每个 executor中执行Hash Join

8.2）shuffle Hash Join

选择Shuffle Hash Join需要同时满足以下条件：spark.sql.join.preferSortMergeJoin为false，即Shuffle Hash Join优先于Sort Merge Join 右表或左表是否能够作为build table 是否能构建本地HashMap 以右表为例，它的逻辑计划大小要远小于左表大小（默认3倍）

适合小表和大表join

8.3）Shuffle Sort Merge Join

仅支持等值连接 支持所有join类型 Join Keys是排序的 参数spark.sql.join.prefersortmergeJoin (默认true)设定为true

适合大表和大表的join

Shuffle Phase : 两张大表根据Join key进行Shuffle重分区 Sort Phase: 每个分区内的数据进行排序 Merge Phase: 对来自不同表的排序好的分区数据进行JOIN，通过遍历元素，连接具有相同Join key值的行来合并数据集

8.4）Cartesian Product Join

仅支持内连接 支持等值和不等值连接 开启参数spark.sql.crossJoin.enabled=true

8.5）Broadcast Nested Loop Join

支持等值和非等值连接 支持所有的JOIN类型，主要优化点如下：当右外连接时要广播左表 当左外连接时要广播右表 当内连接时，要广播左右两张表

8.6）总结

（1）优先级为：Broadcast Hash Join > Sort Merge Join > Shuffle Hash Join > cartesian Join > Broadcast Nested Loop Join.

（2）等值连接的情况

有join提示(hints)的情况，按照下面的顺序：1.Broadcast Hint：如果join类型支持，则选择broadcast hash join 2.Sort merge hint：如果join key是排序的，则选择 sort-merge join 3.shuffle hash hint：如果join类型支持， 选择 shuffle hash join 4.shuffle replicate NL hint：如果是内连接，选择笛卡尔积方式

没有join提示(hints)的情况，则逐个对照下面的规则 1.如果join类型支持，并且其中一张表能够被广播(spark.sql.autoBroadcastJoinThreshold值，默认是10MB)，则选择 broadcast hash join 2.如果参数spark.sql.join.preferSortMergeJoin设定为false，且一张表足够小(可以构建一个hash map) ，则选择shuffle hash join 3.如果join keys 是排序的，则选择sort-merge join 4.如果是内连接，选择 cartesian join 5.如果可能会发生OOM或者没有可以选择的执行策略，则最终选择broadcast nested loop join

（3）非等值连接情况

有join提示(hints)，按照下面的顺序 1.broadcast hint：选择broadcast nested loop join. 2.shuffle replicate NL hint: 如果是内连接，则选择cartesian product join

没有join提示(hints)，则逐个对照下面的规则 1.如果一张表足够小(可以被广播)，则选择 broadcast nested loop join 2.如果是内连接，则选择cartesian product join 3.如果可能会发生OOM或者没有可以选择的执行策略，则最终选择broadcast nested loop join

9）用Distribute By Rand控制分区中数据量

10）group by优化

11）count(distinct)

12）中间结果的缓存和复用

13）并行执行

14）物化视图

15）hints优化

16）job数优化

• 减少job数：不论是外关联outer join还是内关联inner join，如果Join的key相同，不管有多少个表，都会合并为一个MapReduce任务。
• JOB输入输出优化：善用muti-insert、union all，不同表的union all相当于multiple inputs,同一个表的union all,相当map一次

17）union all优化

18）选择合理的排序

7.9、SLA保障

第一，SLA 监控主要监控整体产出指标的质量、时效性和稳定性。第二，链路任务监控主要对任务状态、数据源、处理过程、输出结果以及底层任务的 IO、CPU 网络、信息做监控。第三，服务监控主要包括服务的可用性和延迟。最后是底层的集群监控，包括底层集群的 CPU、IO 和内存网络信息

时效性的目标也有 3 个，接口延迟的报警、OLAP 引擎报警和接口表 Kafka 延迟报警。拆分到链路层面，又可以从 Flink 任务的输入、处理和输出三个方面进行分析：输入核心关注延迟和乱序情况，防止数据丢弃；处理核心关注数据量和处理数据的性能指标；输出则关注输出的数据量多少，是否触发限流等。

7.10、模型优化（设计合理的数仓模型）

1）是否有现成的数据可以使用或者基于现成的数据进行加工

2）是否可以将整个计算逻辑进行合理拆分，降低每个子任务的复杂度，同时提高复用的可能性

维度退化，空间和时间的权衡

3）链路长度优化

（1）长度限制：CDM层链路不宜过长，如果过长，请考虑复用&重构；

（2）深度限制：CDM层链路深度不宜过大，单个任务连路控制在一小时以内，否则数据重跑时间成本过大；

4）中间表

适用于数据量大，下游任务很多的表，应用好了可以节省很多的计算量和成本。也不建议用太多的中间表，因为中间表多依赖的层级也越多。

5）拉链表

6）合表

业务重叠或重复的表，进行任务和数量的合并

7）拆表

个别字段产出极慢，字段拆分为单独的表，这样就可以避免因为几个过慢的字段影响其它业务。

7.11、调度任务治理优化

• 任务优先级划分和梳理，优先保障高优先级别的产出、做好双链路切换
• 任务数评估，任务错峰调度
• 烟囱任务下沉&无用任务下线
• 数据倾斜任务经优化后仍无法解决，拆分任务，分批调度
• 尽量减少任务依赖。（天任务依赖小时任务，小时级别依赖分钟级别等）
• 任务自动分级和降级
• 减少任务依赖，尽可能缩短链路
• 资源腾挪调整
• 资源动态扩容
• 业务链路/逻辑重构/改写

7.12、操作系统层面优化

1. 硬件升级

2. 资源管理：合理管理系统资源，确保资源的分配和使用达到最优化。

3. 磁盘碎片整理

4. 缓存机制优化

5. 文件描述符和线程数限制

6. 降低或者禁用swap使用交换区会导致性能下降，建议降低swap的使用：

7. 零拷贝、页缓存

7.13、应用程序优化

多线程

并发编程

NIO

7.14、集群稳定性

1：起夜率

2：任务压测、削谷填峰

3：高可用HA

4：支持动态扩容和数据处理流程自动漂移

5：做好相关监控、建立起监控预警机制

6：弹性反脆弱

7：自动化运维

8：上游元数据变更抗性