大数据技术提升与学习指南

如果你想提升大数据技术能力，寻找专业指导，持续学习，并找到一份满意的工作，欢迎加入我的知识星球。我开通知识星球已有大半年时间，星球上沉淀了大量有价值的内容。

星球的定位是专注于大数据内容的干货输出，帮助大家提升大数据技术，带领大家共同学习。 星球内容以及语雀文档都是经过我精心总结和整理的。

数据治理

为什么需要做数据治理？

• 公司内数据孤岛现象严重，阻碍数据内部共享
• 数据治理难以及时满足业务预期，无法助力数据挖掘产生价值
• 难以兼顾数据流通和数据安全的平衡，数据风险一直存在
• 数据资产无法持续运营，找不到数据、并且难以管理，完全不清楚公司有那些数据？都分布在哪个系统？哪些已经采集了？
• 用户看不懂数据，数据标准不一致，定义难以理解
• 信不过数据，数据质量较差，导致数据价值难以呈现，且风险高
• 数据开发效率低，数据产生时效不高
• 数据模型待完善，模型复用度很低，当前烟囱式开发严重，浪费很多开发成本，开发效率还很低

数据治理的挑战和难度

• 数据治理开展和推动难
  • 需要由一个权级非常高的人去牵头并推动，需要各个团队配合协作
• 数据治理落地难
  • 治理效益和业务影响的矛盾
    • 业务系统、生产流程的改造会影响业务
    • 各个业务的需求都不一致，从全局策略去落地较难
    • 治理团队核心保障治理大目标，无法顾及业务个性需求
    • ROI（投入产出比）评估难：包括治理收益、时间周期、业务影响，很难去向上汇报治理成果
  • 规范“人”的动作难度大
    • 人员能力参差不齐，对齐目标和优先级困难
    • 治理操作依靠人，规范对人偏差容忍度低
    • 组织文化差异，各个业务对使用数据治理的落地方法、调整、成效都不一样，很难统一去治理
  • 治理涉及的组织和管理难度大
    • 角色多、范围广、链路长
    • 治理目标对齐、管理、跟进难度大
    • 组织越复杂，数据治理难度越大
    • 跨部门、跨系统难度大
  • 缺乏适配性强的产品工具
    • 现状、问题客观工具缺失
    • 无全局视角工具，直接跳入治理细节
    • 跨部门、跨系统治理目标对齐、协商工具缺失
    • 缺乏全链路治理的工具
    • 工具不灵活，只能解决通用治理问题
• 治理周期长，有始无终，持续治理
• 治理效果难以量化和评估

如何开展数据治理工作？

1. 梳理现有业务现状和痛点，需求收集、任务等级划分。
2. 成立数据委员会，划分各方的工作内容，责任归属，角色和职能，管理、决策、执行相关流程和内容。
3. 盘点数据资产、梳理核心治理项、治理指标，架构设计。
   • 发现问题制定目标，围绕服务好业务，并且制定可实现的目标
   • 针对问题进行拆解，设计可衡量的指标。
4. 制定相关标准和规范
5. 对具体问题，制定相关的解决方案及标准，通过对事件的全链路监控，建设和完善对应的工具化
6. 推广运营，拿结果为核心目标，对不同角色采用不同策略，重点关注问题解决过程是否会和用户利益有冲突，让治理有序进行
7. 平台化和体系化建设，结合实际业务，设计出平台化的产品，统一运营和管理，数据全生命周期管理，实现数据从生产到应用，安全共享，分层协调，全面治理。
8. 总结沉淀方法论，迭代认知，探索问题的最优解，优化治理方案和能力

元数据管理

元数据分类

• 业务元数据（模型之上）
  • 1、业务定义，业务术语解释等，比如UUID表示啥？
  • 2、业务指标名称、计算口径、衍生指标等
  • 3、业务引擎的规则（比如身份证号码校验规则），数据质量的检验规则、数据挖掘算法
  • 4、数据的安全等级、数据的分级、脱敏
• 技术元数据（模型实体）
  • 1、数仓的数据库表名称、列名称、字段类型、长度、约束信息、数据依赖关系等
  • 2、数据存储类型、存储位置、存储格式、是否压缩、压缩格式、文件大小等
  • 3、库表字段级血缘关系、sql脚本信息、ETL信息、接口信息等
  • 4、调度依赖关系、调度信息、任务进度、数据更新频率
• 操作元数据（模型操作）
  • 1、数据所有者、归属group、使用者。比如哪些人申请了读写权限
  • 2、数据的访问方式，访问时间、访问限制、变更记录
  • 3、数据的访问权限，组和角色关系
  • 4、数据处理作业的结果、系统运行日志
  • 5、数据备份、归档、归档人、归档时间...
• 管理元数据（管理模型）
  • 数据的来源
  • 数据的功用
  • 数据的价值体现等
  • 数据的负责人

• 业务元数据描述的对象，是数据的业务含义、业务规则等
• 技术元数据是用于开发和日常管理数据仓库时用的数据
  • 数据本身技术元数据有
  • 数据质量和运维相关元数据
  • 分布式计算系统运行元数据
• 操作元数据描述了数据的操作属性，比如管理部门、管理责任人等
• 管理元数据包含了数据管理的信息在其中，例如：表的业务属主、表的技术负责人

元数据应用

• 数据地图
  • 数据地图整合集市一级和二级主题分类
• 业务系统数据字典
  • 支持业务系统元数据存储和查询功能
• 场景化搜索
  • 提供hive数据库表和字段的列表式查询
• 血缘分析
  • 显示数据库、表和字段上下游依赖可检索和下载
  • 血缘收集的三种方式
    • 通过静态解析 SQL，获得输入表和输出表；
    • 静态解析 SQL，可以使用 Antlr4 仿照 Hive 的 SQL 解析来实现，但是不能保证 SQL 的准确性，因为任务都没有执行。
    • 数据血缘不准确
    • 通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
    • 通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。
  • 审计日志
    • 时效性差
  • 常见血缘工具
    • datahub
      • 优势: 强大的数据发现和搜索功能，方便用户快速定位所需数据。提供数据质量元数据，帮助用户理解和信任数据。支持多种数据源，包括传统的关系数据库和现代的数据湖。社区活跃，不断有新功能和改进加入。
      • 劣势: 初学者可能会觉得界面和配置相对复杂。开发语言是Python,做二开时可能对部分大数据组件的集成会相对麻烦，另外调度一般会配合airflow 在某些情况下，集成新的数据源可能需要额外的开发工作。版更更新迭代快，使用后升级是个难题。中文资料不多，中文交流社群也不多。
    • atlas
      • 优势: 与Apache Hadoop生态系统深度集成，特别适合Hadoop用户。提供强大的数据血缘和分类功能，有助于数据治理。支持自定义的元数据类型和模型。开源，有较大的社区支持和贡献。
      • 劣势: 主要针对Hadoop生态系统，可能不适合非Hadoop环境。用户界面和用户体验不如一些商业产品。依赖组件会比较多，一旦其中一个挂掉，容易影响血缘展示
    • OpenMetadata:
      • 优势: 设计现代且用户友好，易于使用。强调社交元数据管理，如用户评分、评论和讨论。提供丰富的API，便于与其他系统集成。持续更新和改进，反映了最新的数据管理趋势。
      • 劣势: 相比Datahub和Atlas，社区相对较小，可能在某些特定功能上支持有限。作为较新的平台，可能还在某些方面需要时间来成熟。
  • 如何选型
    • 1、梳理数据源
      • 如果企业需要管理的数据源主要是大数据组件，Hive和Spark为主的hadoop体系，可以使用Atlas快速的搭建一个元数据管理平台，由于原生的支持，基本不需要做很多的适配，只要安装配置好就可以。但是如果企业收集元数据不限于此，建议选择更灵活的Datahub和Openmetadata，反正都要做适配，做二次开发，不如直接选一个更灵活的。
    • 2、明确需求
      • Altas有搜索，数据血缘（含字段级别的），标签，术语表等功能。Datahub有搜索，数据血缘，数据分析，标签，术语表等功能，也可以集成数据质量框架，如GreatExceptions。Openmetadata有搜索，数据血缘，数据质量，数据分析，标签，术语表功能，并且有团队协作的功能。二开这里简单说一下，如果是元数据管理平台+数据治理工具的组合，建议选择Datahub基本可以覆盖所有的元数据管理功能，也有很好的扩展性。而如果想选择一个平台大而全，可以考虑在Openmetadata基础上二开，毕竟支持的功能多一些。
    • 3、可行性
      • 真正实现元数据管理的难度是巨大的。如果需要二开，则必须考虑开发难度。Atlas后端主要为Java，需要高级的Java开发人员进行钻研，如需要更改页面，也需要前端人员的配合。Datahub后端Java和Python都有的，而核心的数据摄取部分，主要是Python为主，熟悉Python框架的同学会更好上手。如需要更改页面，也需要前端人员的配合。Openmetadata后端为Java，前端为TS。同样都是要有相关经验的人员参与的
    • 4、学习成本与易用性
      • DataHub:中文资料不多，中文交流社群也不多。界面和配置相对复杂。Atlas: 启动和依赖组件较多。OpenMetadata:社区较小，不太活跃。功能支持有限。
• 数据血缘
  
• 作业运行状况
  • 支持表对应作业的运行ID、运行日志和状态
• 数值分布
  • 提供多维度字段的属性值分布情况
• 变更通知
  • 支持元数据变更时告警和通知
• hive目录
  • 提供hive数据库表和字段的列表式查询
    

数据质量

稽核维度

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

保障机制

• 事前预防
  • 数据探查
  • 梳理表字段
  • 制定资产等级
  • 制定数据质量标准
  • 制定检验规则
• 事中监控
  • 针对不同的表配置不同的DQC规则。DQC规则分为表级，字段级和自定义三种。
  • sql校验
  • 监控原始数据质量
  • 监控数据中心质量
  • 指标波动稽核
  • 异常告警
• 事后改善
  • 修复数据质量问题
  • 收集数据质量需求
  • 完善数据质量管理制度
  • 完善数据质量标准
  • 表评分算法
  • 数据质量管理系统报表查询
  • 订阅

实施流程

1. 质量需求：发现数据问题；信息提报、收集需求；检核规则的需求等。
2. 提炼规则：梳理规则指标、确定有效指标、检核指标准确度和衡量标准。
3. 规则库构建：检核对象配置、调度配置、规则配置、检核范围确认、检核标准确定等。
4. 执行检核：调度配置、调度执行、检核代码。
5. 问题检核：检核问题展示、分类、质量分析、质量严重等级分类等。
6. 分析报告：数据质量报告、质量问题趋势分析，影响度分析，解决方案达成共识。
7. 落实处理：方案落实执行、跟踪管理、解决方案Review及标准化提炼。
8. 知识库体系形成：知识经验总结、标准方案沉淀、知识库体系建设。

数据质量常见应用场景

数据标准

组成

• 业务
  • 通过对实体数据的标准化定义，可以解决数据不一致、不完整、不准确等问题，。通过对数据的标准化定义让数据在企业内有一个全局的定义，大大减少了各部门、各系统间的沟通成本。
• 技术
  • 统一、标准的数据及数据结构是企业信息共享的基础；标准的数据模型和标准数据元为新建系统提供支撑，提示应用开发的实施效率；很大程度上数据质量管理都是依赖于数据标准，在数据标准之上才能定义数据质量。
• 管理
  • 通过数据的标准化定义，明确数据的责任主体，为数据安全、数据质量提供保障

分类

• 基础数据标准
  • 业务属性
  • 标准主题
  • 标准大类
    
  • 标准中类
  • 标准小类
  • 标准编码
  • 标准中文名称
  • 标准英文名称
  • 业务定义
  • 业务规则
  • 引用相关标准
  • 标准来源和依据
  • 技术属性
  • 数据类型
  • 长度
  • 约束信息
  • 数据格式
  • 代码编码规则
  • 取值范围
  • 管理属性
  • 标准定义者
  • 标准管理者
  • 标准使用者
  • 标准版本
  • 应用领域
  • 使用系统
• 指标数据标准
  • 业务属性
  • 指标编码
  • 指标中文名称
  • 指标英文名称
  • 指标主题
  • 指标分类
  • 原子
  • 派生
  • 衍生
  • 指标类型
  • 指标定义
  • 业务规则
  • 指标来源
  • 取数规则
  • 统计维度
  • 计算公式
  • 显示精度
  • 相关基础数据标准
  • 技术属性
  • 数据来源系统
  • 指标使用系统
  • 数据源表
  • 数据类型
  • 度量单位
  • 取值范围
  • 指标生成频度
  • 指标计算周期
  • 指标取数精度
  • 管理属性
  • 归口业务部门
  • 业务负责人
  • 技术负责人
  • 指标权限范围

使用场景

• 建立统一的数据视图：建立通用的元模型规范，支持用户自定义扩展，对多源异构数据表进行信息抽象提取，形成统一的元数据层。所有的数据开发完成后发布到数据标准维护的统一的数据目录，通过不同维度的数据目录进行多维筛选，满足各类用户的检索需要，达到资产的可管、可用、可查的目标。
• 建立统一的数据认知：通过对多源异构数据的标准化描述，就算数据在不同系统的称呼千奇百怪，但是至少流入大数据的场景后就会统一描述，使管理方、开发方、使用方统一认知。
• 建立质量审核体系：在数据标准统一的前提下，我们就可以基于标准的元数据信息，进行质量的监控和审核，提升数据质量，更大化的体现数据价值
• 面向未来的数据治理：工具的终极目的都是为了降本提效。效率的提升要依靠流程规范，流程主够规范，在某种程度上就可实现流程自动化流转，所以数据治理如果要成为流程自动化、阶段智能化的阶段，那么就需要数据标准的支持。

设计原则

实施流程

1. 制定目标和界定范围
2. 数据标准调研
   • 基础数据标准
   • 业务术语标准
   • 命名规范标准
   • etl开发标准
   • 代码
   • 源系统字典维护
   • 公共字典维护
   • 源系统字典和公共字典的映射
   • 应用标准
   • 维度管理
   • 指标管理
   • 标准流程管理
3. 明确组织和流程
4. 数据标准编制与发布
5. 数据标准宣贯
6. 数据标准平台落地运营

数据安全

安全管控策略

安全从哪些方面建设

• 数据获取安全
  • 能够支持数据获取需要经过申请与审批流程，保障数据获取安全。
• 数据脱敏
  • 能够支持数据脱敏规则、脱敏算法及脱敏任务的管理及应用，一般情况下，脱敏方式有动态脱敏和静态脱敏两种
• 统一认证
  • 定义数据安全策略，定义用户组设立和密码标准等
• 租户隔离
  • 管理用户，密码，用户组和权限；
• 角色授权
  • 划分信息等级，使用密级分类模式，对企业数据和信息产品进行分类
• 日志审计
  • 审计数据安全，监控用户身份认证和访问行为，支持经常性分析
• 异常监控
  • 指对账号异常行为的监控，如同一账号异地登录、同时多 IP 登录、多次重复登录等
• 数据分类分级
  • 能够支持对数据资产安全进行敏感分级管理，并支持根据各级别生成对应的数据安全策略。
    
    

数据治理梳理文档

公众号文章： 关于数据治理的一些梳理

公众号文章： 数据治理手稿

评估数据治理的成效

数据质量分

• 稽核规则覆盖度
• 监控作业稳定性
• 告警响应度
• 数据完善度、一致性、准确性
• 作业及时性
• 作业性能分

数据安全分

• 角色管理
• 数据表分级
• 权限管控
• 数据脱敏
• 数据展示
• 定期扫描（闲置表归类或下线）

数据标准分

• 研发规范
  • 命名规范
  • 调用规范
  • 开发规范
  • 评审规范
  • 数仓管理规范
• 应用规范
  • 闲置率
  • 穿透率
  • 覆盖率
  • 资产引用率
  • 资产规范率
  • 不良查询率
  • 同源重复导入
    

成本分

• 计算资源分
  • 系统优化
  • 任务优化
• 存储资源分
  • 表的存储与设计
  • 数据垃圾检测和清理
  • 数据生命周期管理
  • 数据共享方案

价值分

• 对业务的影响和支撑度
• 数据利用率
• 成本降低
• ROI
  

运维和监控

运维·压力测试

大数据平台的压力测试

• 压力测试的对象
  • 压测对象是数据管道，也就是数据在大数据平台的一个或多个系统中经过的完整路径。对数据平台来说，数据处理作业有多种：全量数据导入新表、高并发的增量导入任务、Ad-hoc查询、多个OLAP任务同时访问同一张数据表，等等。简单来说，数据平台的压测就是要获取平台处理批量作业、实时作业、交互查询时的响应延迟、吞吐量、服务可用性等性能指标。
• 压测的目的
  • 检验系统的稳定性和吞吐量，尽早发现瓶颈环节，有利于对系统做精确的性能预期规划和容量规划
• 怎么做压测
  • 方法： 模拟一定数量的客户端对目标系统的各种操作， 对数据管道逐步施压，即逐步增加客户端并发数和数据量
  • 数据管道各环节分别做压力测试
    • 数据采集环节的压测
      • 埋点数据(用户行为数据)的采集
      • 业务数据(交易类数据)的采集
    • 数据存储环节的压测
      • 全量数据导入新表
      • 增量数据周期性导入
      • 在做全量、增量导入时，测试数据平台存储引擎的写入性能
    • 数据加工环节的压测
      • 批处理作业，例如全量数据导入、ETL或ELT
      • 实时流处理作业
    • 数据源端
      • producer的消息发送性能测试： producer在不同的消息发送策略(ack值) 情况下的发送频率（XXXX条/s）
    • 数据缓冲带（kafka或pulsar）
      • 压测对象： 消息写入存储介质的性能（主要是指分区不同副本数量的写入性能） 、故障恢复速度
    • 数据消费端
      • 不同consumer group数量的消费能力（xxxxx条/s）;观察反压机制的效果
    • Ad-hoc 交互式查询
    • 数据交换，例如数据湖、仓之间的数据迁移
      
    • 数据共享或数据服务环节
      • 例如，不同的数据需求方和数据应用需要同时访问同一个数据资源，在满足数据访问权限要求的前提下观察数据访问的相关指标（例如响应延迟、QPS）
    • 全链路压测
      • 全链路压测通过标准
        • 确保作业输入读取延迟为毫秒级，且无反压。
        • CPU利用率整体不超过 60%。
        • 计算最终结果和既定目标保持一致。
          
          
• 有什么工具
  • 数据管道各环节对应着不同的技术组件，有些组件原生提供了性能测试工具；如果组件没有提供工具就需要使用第三方工具

监控·如何采集指标

• 可以采用restful方式采集
• 如果针对自己搭建的集群（例如基于EMR云主机搭建），而且运行的机器和业务也不多，那么可以考虑使用开源组件Ganglia+Nagios(ganglia做监控，nagios作告警)
• 如果要监控的机器多、业务多，那么考虑采用PGA（Prometheus+ Grafana+ Alertmanager）监控告警平台，PGA的优点是在数据采集选型、存储工具选型、监控页面配置、告警方式选择以及配置方面更加灵活，使用场景更加广泛，功能、性能更加优秀和全面
• 如果是买的云平台产品，例如阿里云、华为云的产品，这些产品会提供监控、告警平台

监控·指标有哪些

flink

• IO
• CPU
• Threads 监控指标
• GC监控指标
• Network监控指标
• Cluster监控指标
• Checkpointing监控指标
  • numberOfInProgressCheckpoints
  • lastCheckpointDuration
  • numberOfCompletedCheckpoints
  • lastChecpointFullSize
  • numberOfFailedCheckpoints
  • totalNumberOfCheckpoints
• latencyMarker
• waterMarkLag、currentInputWatermark、currentOutputWatermark
• sourceIdletime、uptime、numRestarts
• numRunningJobs、taskSlotsTotal、taskSlotsAvailable
• numRecordsInPerSecond、numRecordsOutPerSecond、numRecordsIn、numRecordsOut

starrocks

• 集群性能监控
  • CPU 使用率
    • cpu_util :CPU 使用率。cpu_system :cpu_system 使用率。cpu_user :cpu_user 使用率。cpu_idle :cpu_idle 使用率。cpu_guest :cpu_guest 使用率。cpu_iowait :cpu_iowait 使用率。cpu_irq :cpu_irq 使用率。cpu_nice :cpu_nice 使用率。cpu_softirq :cpu_softirq 使用率。cpu_steal :cpu_steal 使用率。starrocks_be_resource_group_cpu_limit_ratio:该资源组 CPU 配额比率的瞬时值 starrocks_be_resource_group_cpu_use_ratio:该资源组 CPU 使用时间占所有资源组 CPU 时间的比率
  • 内存使用
    • starrocks_be_resource_group_mem_limit_bytes Byte 瞬时值 该资源组内存配额比率的瞬时值 starrocks_be_resource_group_mem_allocated_bytes Byte 瞬时值 该资源组内存使用率瞬时值 Cluster BE Mem Stat : 每个 StarRocks 集群的 BE 内存使用情况概览。BE Mem ：这里是监控集群中每个BE的内存使用情况
  • 磁盘 I/O 使用率，磁盘使用量、磁盘空闲量
    • disk_free:空闲磁盘容量。disk_io_svctm:磁盘 IO 服务时间。disk_io_util:磁盘使用率。disk_used:已用磁盘容量
  • 发包带宽、收包带宽，发包数、收包数
• 集群查询监控
  • QPS
  • 平均响应时间
  • 50/75/90/95/99/999 分位响应时间
  • starrocks_fe_query_resource_group_latency
  • starrocks_fe_query_resource_group_err
• 数据导入量监控
  • 发起导入次数
  • fe_loading_broker_load_job
  • 导入行数
  • 导入数据量
• 数据组合并（Compaction）监控
  • 基线合并数据量
  • be_base_compaction_bytes_per_second
  • 基线合并数据量
  • be_base_compaction_rowsets_per_second
  • 增量合并数据组速率
  • be_cumulative_compaction_bytes_per_second
  • 增量合并数据量
  • be_cumulative_compaction_rowsets_per_second

kafka

• Broker
  • 资源使用指标
    • 活跃控制器数量:ActiveControllerCount
    • 非同步分区数量:UnderReplicatedPartitions
    • 离线分区数量:OfflinePartitionsCount
    • 离线日志目录数量:OfflineLogDirectoryCount
    • 网络处理器的平均空闲百分比:NetworkProcessorAvgIdlePercent
    • 请求处理器的平均空闲百分比:RequestHandlerAvgIdlePercent
  • 网络传输指标
    • 流入字节：BytesInPerSec
    • 流出字节:BytesOutPerSec
    • 流入消息:MessagesInPerSecBytesInPerSec
    • 每秒处理的请求数:RequestsPerSec
  • 副本同步指标
    • 分区数量:PartitionCount
    • leader 分区数量：LeaderCount
    • 处于欠同步状态的分区数量:UnderReplicatedPartitions
    • 同步副本集（ISR）缩小和扩大的速率:IsrShrinksPerSec和IsrExpandsPerSec
  • 磁盘使用指标
    • 日志刷新的速率和时间:LogFlushRateAndTimeMs
    • 日志段文件的大小:Size
  • Broker性能指标
    • Page cache reads ratio
    • Disk usage
    • CPU usage
    • Network bytes sent/received
• Producer
  • 消息发送指标
    • 每秒发送的消息记录数:record-send-rate
    • 每秒发送的字节数:byte-rate
    • 消息压缩率:compression-rate
  • 请求指标
    • 每秒发送的请求数:request-rate
    • 请求的平均延迟:request-latency-avg
    • 请求的最大延迟:request-latency-max
  • 错误指标
    • 每秒发送失败的消息记录数:record-error-rate
    • 每秒发送失败的批次数:failed-batch-rate
    • 每秒重试的次数:retry-rate
• Consumer
  • 消息消费指标
    • 每秒消费的消息记录数:records-consumed-rate
    • 每秒消费的字节数:bytes-consumed-rate
    • 每秒拉取的次数:fetch-rate
  • 请求指标
    • 拉取请求的平均延迟:fetch-latency-avg
    • 拉取请求的最大延迟:fetch-latency-max
    • 拉取请求被限流的平均时间:fetch-throttle-time-avg
    • 拉取请求被限流的最大时间:fetch-throttle-time-max
  • 位移指标
    • 每秒提交位移的次数:commit-rate
    • 提交位移的平均延迟:commit-latency-avg
    • 提交位移的最大延迟:commit-latency-max
• Topic
  • 生产者指标
    • ProduceMessageConversionsPerSec：每秒进行的消息转换次数
    • TotalProduceRequestsPerSec：每秒收到的生产请求总数
  • 消费者指标
    • TotalFetchRequestsPerSec：每秒收到的拉取请求总数
    • BytesConsumedPerSec：每秒消费的字节数
    • MinFetchRate：消费者最小拉取的速率
    • MessagesPerSec：消息的消费速度
    • BytesPerSec：消费者的网络吞吐量
  • 副本指标
    • ReplicationBytesInPerSec：每秒从Leader副本传输到Follower副本的字节数。
    • ReplicationBytesOutPerSec：每秒从Follower副本传输到Leader副本的字节数。
    • UnderReplicatedPartitions：处于欠同步状态的分区数量。
• Lag监控指标
  • MaxLag：滞后follower和leader的最大消息长度
  • ConsumerLag：滞后follower的消息长度

k8s

• node节点CPU使用率
  • node_cpu_seconds_total (counter类型指标，用来统计CPU每种模式下所花费的时间，是CPU时间片的一个累积值)
  • 如果需要计算node节点CPU使用率：CPU使用率是cpu除空闲(idle)状态之外的其他所有CPU状态的时间总和除以总的CPU时间得到的结果。即：
    • (1- sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance) / sum(rate(node_cpu_seconds_total[1m])) by (instance)) *100
  • 如果需要采集节点vcpu指标信息：例如4u的一个节点，监控每个u的使用率，可参考公式:
    • (1- sum(rate(node_cpu_seconds_total{mode="idle"}[1m])) by (instance,cpu) / sum(rate(node_cpu_seconds_total[1m])) by (instance,cpu)) *100
• Node节点内存使用率
  • node_memory_MemTotal_bytes ：节点总内存
  • node_memory_MemFree_bytes ：节点真正尚未被使用的物理内存数量
  • node_memory_MemAvailable_bytes ：从应用程序的角度看到的可用内存；linux 内核为了提升磁盘操作的性能，会消耗一部分内存去缓存磁盘数据。就是buffer和cache。从应用程序角度来说avaliable = free + buffer +cache, 不过这只是一个理想的公式，实际中的数据会有较大偏差。
    • (1-(node_memory_Buffers_bytes + node_memory_Cached_bytes + node_memory_MemFree_bytes )/node_memory_MemTotal_bytes)*100
    • (1- node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes)*100
• 节点磁盘容量监控
  • node_filesystem_avail_bytes 磁盘可用空间
  • node_filesystem_size_bytes 磁盘总空间
  • 磁盘使用率：1- (node_filesystem_avail_bytes{fstype="ext4"}) / (node_filesystem_size_bytes{fstype="
    end