拓冰网站定制 
后端可观测性APM链路追踪微服务【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址https://gitcode.com/gh_mirrors/pi/pinpoint点击查看免费下载Pinpoint 作为面向大规模分布式系统的 APMApplication Performance Management工具其链路追踪、调用关系统计、Agent 元数据等全部落地在 HBase 中。本指南以仓库 hbase/scripts 目录下的 5 个.hbase脚本为主体系统讲解如何用 HBase shell 一键创建、删除、flush 与 major compact Pinpoint 全部数据表逐表说明表结构、预分区策略与 TTL 取值并结合仓库源码给出 TTL 调整的实战方法。读完本文你将能够独立完成 Pinpoint 的 HBase 存储初始化、按需调整数据保留周期以及掌握日常维护命令的适用场景。一、脚本全景5 个辅助脚本各司其职hbase/scripts/目录下提供了 5 个可直接喂给 HBase shell 的脚本文件覆盖建表—压缩建表—删表—维护完整生命周期脚本文件作用性质hbase-create.hbase创建 Pinpoint 运行所需的全部 HBase 表默认无压缩初始化hbase-create-snappy.hbase以 Snappy 压缩方式创建同样一组表需系统安装 snappy初始化hbase-drop.hbase停用disable并删除dropPinpoint 创建的全部表清理hbase-flush-table.hbase对所有表执行 flush将内存中的 MemStore 刷写为 HFile维护hbase-major-compact-htable.hbase对所有表执行 major compaction合并并清理 HFile维护按照原文档的说明hbase-flush-table.hbase与hbase-major-compact-htable.hbase纯粹用于日常维护purely for maintenance而建表与删表脚本用于存储初始化与整体重置。仓库中的 Docker 化部署脚本 hbase/hbase-docker/check-table.sh 给出了脚本的典型自动化用法启动时先探测AgentId表是否存在不存在则等待 15 秒后自动执行hbase-create.hbase完成初始化实现幂等的表创建。二、执行方式把.hbase文件喂给 HBase shell所有脚本本质上都是 HBase shell 的命令序列原文档给出的标准执行方式为$HBASE_HOME/bin/hbase shell $PATH_TO_SCRIPTS/hbase-create.hbase将$HBASE_HOME替换为 HBase 安装目录、$PATH_TO_SCRIPTS替换为 hbase/scripts 的实际路径即可。脚本结尾统一包含list建表脚本或直接exit维护类脚本执行完毕会自动退出 shell。注意两个使用前提执行前请确认 HBase 集群已启动、当前 shell 能连通 ZooKeeper 与 HBase Master建表脚本会输出大量创建日志可通过list命令的输出核对全部表是否创建成功。除了脚本文件HBase shell 也支持标准输入方式如echo list | hbase shellhbase/hbase-docker/check-table.sh 正是用echo -e exists AgentId | hbase shell探测表是否存在两种方式可结合使用。三、hbase-create.hbase 详解Pinpoint 核心表结构hbase-create.hbase是存储初始化的核心共创建 21 张表。下面按数据职能分组说明表名、列族、TTL、编码方式均以 hbase-create.hbase 实际内容为准。3.1 Agent 基础信息表表名列族TTL秒数据块编码说明AgentInfoInfo31536000PREFIXAgent 基础信息IP、hostname、agent 版本、启动时间等ApplicationIndexAgents31536000无应用 ID 下注册的 agentId 索引AgentLifeCycleS5184000PREFIXAgent 生命周期数据启动/关闭事件AgentEventE5184000PREFIX各类 Agent 事件如线程转储请求等ApplicationA31536000无应用与应用 ID 的映射AgentIdA5184000无Agent 与 agentId 的映射3.2 元数据表Meta-table表名列族TTL秒数据块编码说明ApiMetaDataApi31536000PREFIX方法API元信息用于还原调用栈中的方法名SqlMetaData_Ver2Sql15552000PREFIXSQL 语句元数据当前版本SqlUidMetaDataSql15552000PREFIX以 UID 方式存储的 SQL 元数据StringMetaDataStr15552000PREFIX字符串元数据如方法参数、异常类名等3.3 链路Trace数据表表名列族TTL秒数据块编码说明TraceV2S5184000PREFIX事务跟踪数据当前版本按事务 ID 存储完整调用栈TraceIndexI、M5184000PREFIX事务索引数据ApplicationTraceIndexI、M5184000PREFIX按应用维度的事务索引用于按时间范围检索 trace3.4 应用地图Server Map统计表原文档中描述的ApplicationMapStatisticsCaller、ApplicationMapStatisticsCallee、ApplicationMapStatisticsSelf、HostApplicationMap在当前脚本中均以_Ver2后缀创建用于存储各 Agent 之间的 RPC 调用统计表名列族TTL秒数据块编码说明ApplicationMapStatisticsCaller_Ver2C5184000PREFIX调用方视角的 RPC 统计ApplicationMapStatisticsCallee_Ver2C5184000PREFIX被调用方视角的 RPC 统计ApplicationMapStatisticsSelf_Ver2C5184000PREFIX应用自身调用统计HostApplicationMap_Ver2M5184000PREFIX主机与应用的映射关系MapAppSelfC5184000PREFIX应用自调用统计Server Map 用MapAgentSelfC5184000PREFIXAgent 自调用统计MapAppOutC5184000PREFIX应用出向调用统计MapAppInC5184000PREFIX应用入向调用统计MapAppHostC5184000PREFIX应用-主机调用统计3.5 预分区策略SPLITS 与 UniformSplit为了让高写入量的表在集群中均匀分布脚本对大部分表做了预分区显式 SPLITSStringMetaData、ApiMetaData使用 7 个分区键\x01~\x07SqlMetaData_Ver2、SqlUidMetaData、ApplicationTraceIndex、ApplicationMapStatisticsCaller_Ver2、ApplicationMapStatisticsCallee_Ver2使用 15 个分区键\x02~\x1eApplicationMapStatisticsSelf_Ver2使用 7 个分区键HostApplicationMap_Ver2使用 3 个分区键。分区键选择与行键前缀的取值域对应使数据按行键首字节落入不同 Region自动拆分TraceV2、TraceIndex、MapAppSelf、MapAgentSelf、MapAppOut、MapAppIn、MapAppHost使用{NUMREGIONS 256, SPLITALGO UniformSplit}在创建时按UniformSplit算法均匀切分为 256 个 Region适合高并发写入的链路与统计场景。3.6 DATA_BLOCK_ENCODING PREFIX绝大多数表启用了DATA_BLOCK_ENCODING PREFIX前缀编码这是 HBase 的一种数据块编码方式针对行键前缀高度重复的数据能显著降低 HFile 体积、减少磁盘 IO。需要注意的是它只在数据块层面编码与下文介绍的 Snappy 全表压缩并不冲突——snappy 版本脚本同时开启了两者。另外可以留意一个细节原文档中提到的AgentStatAgent 统计CPU load、GC、堆内存等与ApplicationStatAggre应用聚合统计并未出现在当前建表脚本中。从仓库看Agent 统计表已演进为AgentStatV2由 hbase-schema-definition 中的 XML Schema如 hbase-schema-1.9.0.xml以版本化方式管理而非通过scripts下的命令脚本创建——这也是脚本建表与Schema 管理建表两种方式的分工所在详见第八节。四、hbase-create-snappy.hbaseSnappy 压缩版本hbase-create-snappy.hbase与普通版本的表结构、分区策略完全一致唯一的差异是为每张表额外增加了COMPRESSION SNAPPY配置例如create AgentInfo, { NAME Info, TTL 31536000, COMPRESSION SNAPPY, DATA_BLOCK_ENCODING PREFIX }前提条件如原文档所强调使用该脚本要求系统已安装 snappynative 压缩库且 HBase 侧已完成对应配置。若未安装 snappy 而执行此脚本建表会失败或后续读写报错。选择建议对存储成本敏感、磁盘 IO 紧张的生产环境可优先评估 Snappy 版本无压缩版本则在依赖更少的前提下提供了基准性能。五、hbase-drop.hbase停用并删除全部表hbase-drop.hbase用于整体清空 Pinpoint 存储先对每张表执行disableHBase 删除表的前置步骤期间该表停止对外服务再逐一drop。脚本覆盖了建表脚本创建的全部 21 张表末尾exit退出。需要特别提醒这是一个破坏性脚本执行后 Pinpoint 全部历史数据将不可恢复生产环境务必先做好备份或离线导出从脚本内容看SqlUidMetaData在 drop 前没有对应的disable语句实际执行时需确保该表已处于 disabled 状态否则 HBase 会报错若出现该情况可在 shell 中手动执行disable SqlUidMetaData后再 drop删除后如需恢复直接重新执行 hbase-create.hbase或 Snappy 版本即可重建全部表。六、维护类脚本flush 与 major compacthbase-flush-table.hbase对全部表执行flush将 Region 内 MemStore 中尚未落盘的数据刷写为 HFile。适用场景包括需要强制落盘以便备份、导出 HFile、或观察写入后的磁盘占用情况。hbase-major-compact-htable.hbase对全部表执行major_compact合并各 Region 的 HFile、清理被删除或过期TTL 到期的数据并重写文件。适用场景包括大量数据过期后的空间回收、读性能劣化时的例行优化。两者的共同注意事项维护操作会占用 RegionServer 的 CPU 与磁盘 IO建议在业务低峰期执行对超大数据集全表 major compact 耗时较长可按表分批执行两者都属于按需执行的维护手段HBase 本身有自动 compaction 机制脚本适合在需要主动触发时使用。七、TTL 配置原则与实战调整TTLTime To Live决定 HBase 中数据的最长保留时间是 Pinpoint 存储规划的核心参数。原文档给出了两条必须遵守的原则此处完整保留并结合仓库扩展。7.1 两条基本原则TTL 不是强制值你不必使用脚本文件中的 TTL 值完全可以根据自身业务需求与环境把它设置为任何期望的数据保留周期例如保留 7 天、30 天或 2 年TTL 比例无需严格遵循但要理解高低差异的原因某些表 TTL 更高是因为它们保存的数据一旦被删除会牵连影响其他表的数据可用性。7.2 为什么 ApiMetaData 需要高 TTL原文档以ApiMetaData为例说明了这一设计如果ApiMetaData的 TTL 短于某个 Agent 的存活时间那么当该 Agent 的 API 元数据被删除后历史 trace 中的方法名将无法被正确还原——链路数据虽然还在却会因元数据缺失而残缺。因此在当前脚本中ApiMetaData与AgentInfo同为 31536000 秒约 365 天明显高于 60 天档位的 trace 数据表。同理StringMetaData、SqlMetaData_Ver2、SqlUidMetaData这类还原信息也被设置为 15552000 秒约 180 天长于 trace 数据的 5184000 秒约 60 天。当前脚本三类 TTL 档位归纳如下TTL 值折算适用表31536000约 365 天AgentInfo、ApplicationIndex、ApiMetaData、Application15552000约 180 天StringMetaData、SqlMetaData_Ver2、SqlUidMetaData5184000约 60 天AgentLifeCycle、AgentEvent、TraceV2、TraceIndex、ApplicationTraceIndex、全部统计表、AgentId7.3 用环境变量定制 TTL源码级实战仓库在 hbase/hbase-docker/configure-hbase.sh 中提供了更工程化的 TTL 定制手段脚本用sed按表名替换建表脚本中的 TTL 值每个表对应一个可注入的环境变量未设置时使用脚本默认值。例如sed -i /AgentInfo/s/TTL .[[:digit:]]*/TTL ${AGENTINFO_TTL:-31536000}/g hbase-create.hbase即设置AGENTINFO_TTL环境变量即可覆盖AgentInfo表的 TTL未设置则回退为 31536000。可用的环境变量默认值包括AGENTINFO_TTL31536000、APPINDEX_TTL31536000、AGENTLIFECYCLE_TTL5184000、AGENTEVENT_TTL5184000STRINGMETADATA_TTL15552000、APIMETADATA_TTL31536000、SQLMETADATA_TTL15552000TRACEV2_TTL5184000、APPTRACEINDEX_TTL5184000、TRACEINDEX_TTL5184000APPMAPSTATCALLERV2_TTL、APPMAPSTATCALLEV2_TTL、APPMAPSTATSELFV2_TTL、HOSTAPPMAPV2_TTL、MAPAPPSELF_TTL、MAPAGENTSELF_TTL、MAPAPPOUT_TTL、MAPAPPIN_TTL、MAPAPPHOST_TTL均 5184000APPLICATION_TTL31536000、AGENTID_TTL5184000该脚本还顺带生成hbase-update-ttl.hbase把create替换为alter用于对已存在的表在线修改 TTL适合先按默认建表、后续再调保留周期的场景。7.4 调整 TTL 的落地建议规划保留周期时请遵循 7.1 的两条原则至少保证元数据类表 TTL ≥ 其引用的数据表 TTL避免 trace 因元数据过期而无法还原修改 TTL 只影响之后写入数据的过期时间不会立即删除已存在数据调低 TTL 后如需尽快回收空间可配合执行 hbase-major-compact-htable.hbase 触发 major compaction 清理过期数据。八、两种建表方式的对比命令脚本与 Schema 管理除hbase/scripts的命令式脚本外仓库还提供了版本化的 Schema 管理机制两者服务于不同场景命令式脚本本文主体hbase-create.hbase等直接面向 HBase shell适合手工初始化、Docker 启动自动化见 hbase/hbase-docker/check-table.sh等场景简单直接、依赖少Schema 管理hbase/hbase-schema 模块通过 XML 定义表结构如 hbase-schema-1.9.0.xml 中的createTable/createColumnFamily/split描述由 hbase-schema-manager 按 changeSet 增量执行并记录变更日志适合需要版本化演进表结构的长期运维AgentStatV2 等新表即由此方式引入。两套体系在表结构定义上保持一致TTL、DATA_BLOCK_ENCODING、分区策略均能一一对应例如 XML 中AgentInfo的timeToLive为 31536000、dataBlockEncoding为 PREFIX与脚本完全一致实际部署时按团队习惯二选一即可。九、运维速查场景命令 / 脚本首次初始化建表$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-create.hbaseSnappy 压缩建表$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-create-snappy.hbase需安装 snappy整体重置存储$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-drop.hbase破坏性操作先备份强制落盘$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-flush-table.hbase空间回收 / 读优化$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-major-compact-htable.hbase低峰期执行定制 TTL参考 hbase/hbase-docker/configure-hbase.sh 的环境变量方式综上hbase/scripts提供了一套覆盖建表—压缩建表—删表—维护的完整脚本工具链。理解每张表的职责、预分区与 TTL 设计是规划 Pinpoint 存储容量与数据保留策略的前提结合环境变量与 Schema 管理模块则能在不重写脚本的前提下实现存储策略的持续演进。赞分享后端可观测性APM链路追踪微服务【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址https://gitcode.com/gh_mirrors/pi/pinpoint点击查看免费下载相关推荐从磁盘爆炸到空间自由Pinpoint HBase TTL配置终极优化指南从磁盘爆炸到空间自由Pinpoint HBase TTL配置终极优化指南 你是否正遭遇Pinpoint监控系统磁盘空间告急日志告警频繁触发、查询性能持续下降后端可观测性APM链路追踪微服务Pinpoint数据存储深度优化HBase表结构设计Pinpoint数据存储深度优化HBase表结构设计 当分布式系统面临TB级链路追踪数据时如何在保证查询性能的同时控制存储成本Pinpoint作为开源AP后端可观测性APM链路追踪微服务Unity 辅助脚本完全指南generate_test_runner 自动生成测试运行器与 unity_test_summary 结果聚合Unity 辅助脚本完全指南generate_test_runner 自动生成测试运行器与 unity_test_summary 结果聚合 导读 Unity序列化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Pinpoint HBase 辅助脚本完全指南：表结构、TTL 配置与日常运维
后端可观测性APM链路追踪微服务【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址https://gitcode.com/gh_mirrors/pi/pinpoint点击查看免费下载Pinpoint 作为面向大规模分布式系统的 APMApplication Performance Management工具其链路追踪、调用关系统计、Agent 元数据等全部落地在 HBase 中。本指南以仓库 hbase/scripts 目录下的 5 个.hbase脚本为主体系统讲解如何用 HBase shell 一键创建、删除、flush 与 major compact Pinpoint 全部数据表逐表说明表结构、预分区策略与 TTL 取值并结合仓库源码给出 TTL 调整的实战方法。读完本文你将能够独立完成 Pinpoint 的 HBase 存储初始化、按需调整数据保留周期以及掌握日常维护命令的适用场景。一、脚本全景5 个辅助脚本各司其职hbase/scripts/目录下提供了 5 个可直接喂给 HBase shell 的脚本文件覆盖建表—压缩建表—删表—维护完整生命周期脚本文件作用性质hbase-create.hbase创建 Pinpoint 运行所需的全部 HBase 表默认无压缩初始化hbase-create-snappy.hbase以 Snappy 压缩方式创建同样一组表需系统安装 snappy初始化hbase-drop.hbase停用disable并删除dropPinpoint 创建的全部表清理hbase-flush-table.hbase对所有表执行 flush将内存中的 MemStore 刷写为 HFile维护hbase-major-compact-htable.hbase对所有表执行 major compaction合并并清理 HFile维护按照原文档的说明hbase-flush-table.hbase与hbase-major-compact-htable.hbase纯粹用于日常维护purely for maintenance而建表与删表脚本用于存储初始化与整体重置。仓库中的 Docker 化部署脚本 hbase/hbase-docker/check-table.sh 给出了脚本的典型自动化用法启动时先探测AgentId表是否存在不存在则等待 15 秒后自动执行hbase-create.hbase完成初始化实现幂等的表创建。二、执行方式把.hbase文件喂给 HBase shell所有脚本本质上都是 HBase shell 的命令序列原文档给出的标准执行方式为$HBASE_HOME/bin/hbase shell $PATH_TO_SCRIPTS/hbase-create.hbase将$HBASE_HOME替换为 HBase 安装目录、$PATH_TO_SCRIPTS替换为 hbase/scripts 的实际路径即可。脚本结尾统一包含list建表脚本或直接exit维护类脚本执行完毕会自动退出 shell。注意两个使用前提执行前请确认 HBase 集群已启动、当前 shell 能连通 ZooKeeper 与 HBase Master建表脚本会输出大量创建日志可通过list命令的输出核对全部表是否创建成功。除了脚本文件HBase shell 也支持标准输入方式如echo list | hbase shellhbase/hbase-docker/check-table.sh 正是用echo -e exists AgentId | hbase shell探测表是否存在两种方式可结合使用。三、hbase-create.hbase 详解Pinpoint 核心表结构hbase-create.hbase是存储初始化的核心共创建 21 张表。下面按数据职能分组说明表名、列族、TTL、编码方式均以 hbase-create.hbase 实际内容为准。3.1 Agent 基础信息表表名列族TTL秒数据块编码说明AgentInfoInfo31536000PREFIXAgent 基础信息IP、hostname、agent 版本、启动时间等ApplicationIndexAgents31536000无应用 ID 下注册的 agentId 索引AgentLifeCycleS5184000PREFIXAgent 生命周期数据启动/关闭事件AgentEventE5184000PREFIX各类 Agent 事件如线程转储请求等ApplicationA31536000无应用与应用 ID 的映射AgentIdA5184000无Agent 与 agentId 的映射3.2 元数据表Meta-table表名列族TTL秒数据块编码说明ApiMetaDataApi31536000PREFIX方法API元信息用于还原调用栈中的方法名SqlMetaData_Ver2Sql15552000PREFIXSQL 语句元数据当前版本SqlUidMetaDataSql15552000PREFIX以 UID 方式存储的 SQL 元数据StringMetaDataStr15552000PREFIX字符串元数据如方法参数、异常类名等3.3 链路Trace数据表表名列族TTL秒数据块编码说明TraceV2S5184000PREFIX事务跟踪数据当前版本按事务 ID 存储完整调用栈TraceIndexI、M5184000PREFIX事务索引数据ApplicationTraceIndexI、M5184000PREFIX按应用维度的事务索引用于按时间范围检索 trace3.4 应用地图Server Map统计表原文档中描述的ApplicationMapStatisticsCaller、ApplicationMapStatisticsCallee、ApplicationMapStatisticsSelf、HostApplicationMap在当前脚本中均以_Ver2后缀创建用于存储各 Agent 之间的 RPC 调用统计表名列族TTL秒数据块编码说明ApplicationMapStatisticsCaller_Ver2C5184000PREFIX调用方视角的 RPC 统计ApplicationMapStatisticsCallee_Ver2C5184000PREFIX被调用方视角的 RPC 统计ApplicationMapStatisticsSelf_Ver2C5184000PREFIX应用自身调用统计HostApplicationMap_Ver2M5184000PREFIX主机与应用的映射关系MapAppSelfC5184000PREFIX应用自调用统计Server Map 用MapAgentSelfC5184000PREFIXAgent 自调用统计MapAppOutC5184000PREFIX应用出向调用统计MapAppInC5184000PREFIX应用入向调用统计MapAppHostC5184000PREFIX应用-主机调用统计3.5 预分区策略SPLITS 与 UniformSplit为了让高写入量的表在集群中均匀分布脚本对大部分表做了预分区显式 SPLITSStringMetaData、ApiMetaData使用 7 个分区键\x01~\x07SqlMetaData_Ver2、SqlUidMetaData、ApplicationTraceIndex、ApplicationMapStatisticsCaller_Ver2、ApplicationMapStatisticsCallee_Ver2使用 15 个分区键\x02~\x1eApplicationMapStatisticsSelf_Ver2使用 7 个分区键HostApplicationMap_Ver2使用 3 个分区键。分区键选择与行键前缀的取值域对应使数据按行键首字节落入不同 Region自动拆分TraceV2、TraceIndex、MapAppSelf、MapAgentSelf、MapAppOut、MapAppIn、MapAppHost使用{NUMREGIONS 256, SPLITALGO UniformSplit}在创建时按UniformSplit算法均匀切分为 256 个 Region适合高并发写入的链路与统计场景。3.6 DATA_BLOCK_ENCODING PREFIX绝大多数表启用了DATA_BLOCK_ENCODING PREFIX前缀编码这是 HBase 的一种数据块编码方式针对行键前缀高度重复的数据能显著降低 HFile 体积、减少磁盘 IO。需要注意的是它只在数据块层面编码与下文介绍的 Snappy 全表压缩并不冲突——snappy 版本脚本同时开启了两者。另外可以留意一个细节原文档中提到的AgentStatAgent 统计CPU load、GC、堆内存等与ApplicationStatAggre应用聚合统计并未出现在当前建表脚本中。从仓库看Agent 统计表已演进为AgentStatV2由 hbase-schema-definition 中的 XML Schema如 hbase-schema-1.9.0.xml以版本化方式管理而非通过scripts下的命令脚本创建——这也是脚本建表与Schema 管理建表两种方式的分工所在详见第八节。四、hbase-create-snappy.hbaseSnappy 压缩版本hbase-create-snappy.hbase与普通版本的表结构、分区策略完全一致唯一的差异是为每张表额外增加了COMPRESSION SNAPPY配置例如create AgentInfo, { NAME Info, TTL 31536000, COMPRESSION SNAPPY, DATA_BLOCK_ENCODING PREFIX }前提条件如原文档所强调使用该脚本要求系统已安装 snappynative 压缩库且 HBase 侧已完成对应配置。若未安装 snappy 而执行此脚本建表会失败或后续读写报错。选择建议对存储成本敏感、磁盘 IO 紧张的生产环境可优先评估 Snappy 版本无压缩版本则在依赖更少的前提下提供了基准性能。五、hbase-drop.hbase停用并删除全部表hbase-drop.hbase用于整体清空 Pinpoint 存储先对每张表执行disableHBase 删除表的前置步骤期间该表停止对外服务再逐一drop。脚本覆盖了建表脚本创建的全部 21 张表末尾exit退出。需要特别提醒这是一个破坏性脚本执行后 Pinpoint 全部历史数据将不可恢复生产环境务必先做好备份或离线导出从脚本内容看SqlUidMetaData在 drop 前没有对应的disable语句实际执行时需确保该表已处于 disabled 状态否则 HBase 会报错若出现该情况可在 shell 中手动执行disable SqlUidMetaData后再 drop删除后如需恢复直接重新执行 hbase-create.hbase或 Snappy 版本即可重建全部表。六、维护类脚本flush 与 major compacthbase-flush-table.hbase对全部表执行flush将 Region 内 MemStore 中尚未落盘的数据刷写为 HFile。适用场景包括需要强制落盘以便备份、导出 HFile、或观察写入后的磁盘占用情况。hbase-major-compact-htable.hbase对全部表执行major_compact合并各 Region 的 HFile、清理被删除或过期TTL 到期的数据并重写文件。适用场景包括大量数据过期后的空间回收、读性能劣化时的例行优化。两者的共同注意事项维护操作会占用 RegionServer 的 CPU 与磁盘 IO建议在业务低峰期执行对超大数据集全表 major compact 耗时较长可按表分批执行两者都属于按需执行的维护手段HBase 本身有自动 compaction 机制脚本适合在需要主动触发时使用。七、TTL 配置原则与实战调整TTLTime To Live决定 HBase 中数据的最长保留时间是 Pinpoint 存储规划的核心参数。原文档给出了两条必须遵守的原则此处完整保留并结合仓库扩展。7.1 两条基本原则TTL 不是强制值你不必使用脚本文件中的 TTL 值完全可以根据自身业务需求与环境把它设置为任何期望的数据保留周期例如保留 7 天、30 天或 2 年TTL 比例无需严格遵循但要理解高低差异的原因某些表 TTL 更高是因为它们保存的数据一旦被删除会牵连影响其他表的数据可用性。7.2 为什么 ApiMetaData 需要高 TTL原文档以ApiMetaData为例说明了这一设计如果ApiMetaData的 TTL 短于某个 Agent 的存活时间那么当该 Agent 的 API 元数据被删除后历史 trace 中的方法名将无法被正确还原——链路数据虽然还在却会因元数据缺失而残缺。因此在当前脚本中ApiMetaData与AgentInfo同为 31536000 秒约 365 天明显高于 60 天档位的 trace 数据表。同理StringMetaData、SqlMetaData_Ver2、SqlUidMetaData这类还原信息也被设置为 15552000 秒约 180 天长于 trace 数据的 5184000 秒约 60 天。当前脚本三类 TTL 档位归纳如下TTL 值折算适用表31536000约 365 天AgentInfo、ApplicationIndex、ApiMetaData、Application15552000约 180 天StringMetaData、SqlMetaData_Ver2、SqlUidMetaData5184000约 60 天AgentLifeCycle、AgentEvent、TraceV2、TraceIndex、ApplicationTraceIndex、全部统计表、AgentId7.3 用环境变量定制 TTL源码级实战仓库在 hbase/hbase-docker/configure-hbase.sh 中提供了更工程化的 TTL 定制手段脚本用sed按表名替换建表脚本中的 TTL 值每个表对应一个可注入的环境变量未设置时使用脚本默认值。例如sed -i /AgentInfo/s/TTL .[[:digit:]]*/TTL ${AGENTINFO_TTL:-31536000}/g hbase-create.hbase即设置AGENTINFO_TTL环境变量即可覆盖AgentInfo表的 TTL未设置则回退为 31536000。可用的环境变量默认值包括AGENTINFO_TTL31536000、APPINDEX_TTL31536000、AGENTLIFECYCLE_TTL5184000、AGENTEVENT_TTL5184000STRINGMETADATA_TTL15552000、APIMETADATA_TTL31536000、SQLMETADATA_TTL15552000TRACEV2_TTL5184000、APPTRACEINDEX_TTL5184000、TRACEINDEX_TTL5184000APPMAPSTATCALLERV2_TTL、APPMAPSTATCALLEV2_TTL、APPMAPSTATSELFV2_TTL、HOSTAPPMAPV2_TTL、MAPAPPSELF_TTL、MAPAGENTSELF_TTL、MAPAPPOUT_TTL、MAPAPPIN_TTL、MAPAPPHOST_TTL均 5184000APPLICATION_TTL31536000、AGENTID_TTL5184000该脚本还顺带生成hbase-update-ttl.hbase把create替换为alter用于对已存在的表在线修改 TTL适合先按默认建表、后续再调保留周期的场景。7.4 调整 TTL 的落地建议规划保留周期时请遵循 7.1 的两条原则至少保证元数据类表 TTL ≥ 其引用的数据表 TTL避免 trace 因元数据过期而无法还原修改 TTL 只影响之后写入数据的过期时间不会立即删除已存在数据调低 TTL 后如需尽快回收空间可配合执行 hbase-major-compact-htable.hbase 触发 major compaction 清理过期数据。八、两种建表方式的对比命令脚本与 Schema 管理除hbase/scripts的命令式脚本外仓库还提供了版本化的 Schema 管理机制两者服务于不同场景命令式脚本本文主体hbase-create.hbase等直接面向 HBase shell适合手工初始化、Docker 启动自动化见 hbase/hbase-docker/check-table.sh等场景简单直接、依赖少Schema 管理hbase/hbase-schema 模块通过 XML 定义表结构如 hbase-schema-1.9.0.xml 中的createTable/createColumnFamily/split描述由 hbase-schema-manager 按 changeSet 增量执行并记录变更日志适合需要版本化演进表结构的长期运维AgentStatV2 等新表即由此方式引入。两套体系在表结构定义上保持一致TTL、DATA_BLOCK_ENCODING、分区策略均能一一对应例如 XML 中AgentInfo的timeToLive为 31536000、dataBlockEncoding为 PREFIX与脚本完全一致实际部署时按团队习惯二选一即可。九、运维速查场景命令 / 脚本首次初始化建表$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-create.hbaseSnappy 压缩建表$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-create-snappy.hbase需安装 snappy整体重置存储$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-drop.hbase破坏性操作先备份强制落盘$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-flush-table.hbase空间回收 / 读优化$HBASE_HOME/bin/hbase shell hbase/scripts/hbase-major-compact-htable.hbase低峰期执行定制 TTL参考 hbase/hbase-docker/configure-hbase.sh 的环境变量方式综上hbase/scripts提供了一套覆盖建表—压缩建表—删表—维护的完整脚本工具链。理解每张表的职责、预分区与 TTL 设计是规划 Pinpoint 存储容量与数据保留策略的前提结合环境变量与 Schema 管理模块则能在不重写脚本的前提下实现存储策略的持续演进。赞分享后端可观测性APM链路追踪微服务【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址https://gitcode.com/gh_mirrors/pi/pinpoint点击查看免费下载相关推荐从磁盘爆炸到空间自由Pinpoint HBase TTL配置终极优化指南从磁盘爆炸到空间自由Pinpoint HBase TTL配置终极优化指南 你是否正遭遇Pinpoint监控系统磁盘空间告急日志告警频繁触发、查询性能持续下降后端可观测性APM链路追踪微服务Pinpoint数据存储深度优化HBase表结构设计Pinpoint数据存储深度优化HBase表结构设计 当分布式系统面临TB级链路追踪数据时如何在保证查询性能的同时控制存储成本Pinpoint作为开源AP后端可观测性APM链路追踪微服务Unity 辅助脚本完全指南generate_test_runner 自动生成测试运行器与 unity_test_summary 结果聚合Unity 辅助脚本完全指南generate_test_runner 自动生成测试运行器与 unity_test_summary 结果聚合 导读 Unity序列化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考