Loki 背后的熵编码利器klauspost/compress huff0 包原理与实战指南【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本篇技术指南深入剖析当前仓库 vendor/github.com/klauspost/compress/huff0 子包它是 zstd 压缩器内部用于字面量literal熵编码的 Huffman 编解码器被 Loki 的块压缩链路间接依赖。读完本文你将掌握 huff0 的块模型、Compress1X/Compress4X压缩接口、错误语义、Scratch复用与表复用策略、ReadTableDecompress1X/4X解压流程以及无状态Decoder的并发解压用法。huff0 是什么为现代 CPU 设计的 Huffman 熵编码器huff0 是一个纯 Go 实现的 Huffman 编解码器其核心设计目标与 zstd 官方参考实现一致面向现代 CPU 的乱序执行Out-of-OrderOoO能力让多条算术逻辑单元ALU流水线并行处理比特流从而获得极快的压缩与解压速度。它的适用场景非常明确对存在大量相似取值的输入压缩到尽可能少的字节数。huff0 不做 LZ 类算法那样的多字节字典编码dictionary coding因此它不能替代 Snappy 等 LZ 压缩器但可以作为二级熵编码步骤叠加在 Snappy 这类只做 LZ 匹配、不做熵编码的压缩器之后进一步榨干冗余。在 huff0.go 的包注释中明确写道本包提供 zstd 所使用的 huff0 编码与解码。这意味着你几乎不需要直接调用它——但它正是 zstd 压缩链中最内层、最高频执行的熵编码模块。块模型一次压缩一个独立块huff0 对外提供的是低层low-level接口只负责压缩单个独立块每个块之间完全独立块与块之间没有任何内置的完整性校验调用方必须自己记录每个块的长度并在需要时自行计算校验和checksum单块未压缩输入的最大尺寸为BlockSizeMax 118 - 1即128 KiB 减去 1 字节见 huff0.go。这一点与 Loki 的生产场景高度契合Loki 在 pkg/compression/pool.go 中通过ZstdPool等池化接口使用github.com/klauspost/compress/zstd对应 go.mod 中的github.com/klauspost/compress v1.19.2而 zstd 内部正是用 huff0 对每个块的字面量流做熵编码。底层块格式自带长度边界与帧结构恰好弥补了 huff0 自身无完整性校验的缺口。压缩Compress1X 与 Compress4X压缩入口是两个包级函数见 compress.gofunc Compress1X(in []byte, s *Scratch) (out []byte, reUsed bool, err error) func Compress4X(in []byte, s *Scratch) (out []byte, reUsed bool, err error)Compress1X将整个输入作为单一比特流编码输出可被Decompress1X解码Compress4X把输入切成 4 个独立段每段各自按Compress1X的方式编码。输出格式为6 字节跳转表前 3 段的长度各 2 字节小端序 4 段压缩数据可被Decompress4X解码。对超过 12 字节的输入compress4X会把不足 65535 字节的段长写入跳转表见 compress.go。两者的返回值out为压缩结果reUsed指示本次是否复用了上一块的表err为可能的错误。调用时必须传入一个Scratch对象它承载了表复用所需的全部内部状态。错误语义即使正常操作也会返回的错误这是 huff0 与普通压缩库最大的不同下面这些错误在完全正常的运行过程中也会出现绝不能简单视为压缩失败调用方必须显式处理错误说明nil一切正常返回压缩输出ErrIncompressible输入被判定为太难压缩如每个符号最多出现一次或分布过于均匀见 compress.go 的maxCount 1 || maxCount len(in)7判定ErrUseRLE输入是单个字节值重复构成压缩器提示应改用 RLE 表示ErrTooBig输入块超过最大允许尺寸128 KiB(error)发生了内部错误从源码看此外还有一个 README 未列出的错误ErrMaxDecodedSizeExceeded输出超过MaxDecodedSize上限时由解码器返回以及ReusePolicyMust下无法复用表时也会返回ErrIncompressible见 huff0.go、compress.go。zstd 内部正是依赖这套语义在 zstd/dict.go 中遇到ErrIncompressible与ErrUseRLE时会分别走原样存储和RLE 块的降级路径而不是报错终止。一次典型压缩调用s : huff0.Scratch{TableLog: 11} // tableLog 合法范围是 5 ~ 11 out, reUsed, err : huff0.Compress1X(data, s) switch { case errors.Is(err, huff0.ErrIncompressible): // 存储原始数据或换其他编码 case errors.Is(err, huff0.ErrUseRLE): // 记录 RLE 标记与单字节值 case err ! nil: // 真正处理内部错误 default: // out 可用reUsed 决定接收端是否应调用 ReadTable }注意压缩器内部还会通过WantLogLess设定至少达到 log2 级别的体积缩减否则视为不可压缩的门槛默认0表示只要有任何改善即可见 huff0.go。Scratch 复用消除分配的关键每次压缩/解压都重新构造编解码表代价高昂。huff0 允许你把一个 Scratch 对象反复传入压缩与解压共用同一个对象即可。必须牢记的坑复用Scratch时其内部的Out输出缓冲区也会被复用。如果你在处理完输出之前就发起下一次压缩/解压一定要先把Scratch.Out字段置为nil否则上一次的输出会被下一次的结果覆盖。压缩和解压使用的是同一个输出缓冲。Scratch会在内部保留状态prevTable、prevTableLog等从而允许在后续调用中复用上一块的编码/解码表。此外它还提供MaxDecodedSize解压输出上限未设置时自动取BlockSizeMax超限返回ErrMaxDecodedSizeExceededMaxSymbolValue/TableLog覆盖下一块的最大符号值与表对数TableLog必须落在 5~11 之间否则prepare直接报错见 huff0.goTransferCTable(src)把另一个Scratch的压缩表拷贝过来实现跨对象传递表状态见 huff0.go。表复用策略ReusePolicy 的四种模式Huff0 允许复用上一块的编码表以节省空间但前提是这能带来更好/更快的结果。Scratch.Reuse字段ReusePolicy枚举控制该行为可在每个块之间随时切换四种模式定义在 huff0.go策略行为ReusePolicyAllow默认允许复用但只有当复用旧表产生的输出更小时才复用否则生成新表ReusePolicyPrefer激进复用。不比较新旧表体积除非旧表不可用或压缩结果比输入还大ReusePolicyNone完全禁用表复用速度略快但输出可能更大ReusePolicyMust必须复用且必须产出更小的输出否则返回ErrIncompressible复用决策的底层逻辑在compress()主流程中compress.go先做直方图统计countSimple用canUseTable判断旧表对新分布是否仍然有效旧表中对应符号的nBits必须非 0再按策略走复用旧表编码或构建新表两条路径。两个必须由调用方承担的责任表信息不会写进输出块。Compress1X/4X返回的reUsed布尔值告诉接收端这一块是否沿用了上一块的表调用方必须自己记录这个标记并据此决定接收端是否要调用ReadTable如果你想把表与数据分开存储可以直接使用Scratch.OutTable表数据与OutData压缩数据两个字段——它们是返回数据的切片视图见 huff0.go。另外EstimateSizes 可以在不实际编码的情况下估算新表体积 / 新表数据体积 / 复用旧表体积三种尺寸供上层在压缩前预判策略。解压流程先 ReadTable再 Decompress解压的第一步永远是通过ReadTable初始化解码表func ReadTable(in []byte, s *Scratch) (s2 *Scratch, remain []byte, err error)ReadTable接收完整的压缩块表 数据解析出表定义并返回remain——即紧随表之后的数据部分再把remain交给解压器。表头有两种形态见 decompress.go首字节 128未压缩的权重表每个权重占 4 bit 打包存储首字节 128FSE 压缩的权重表需先用包内的 FSE 解码器还原权重。随后调用func (s *Scratch) Decompress1X(in []byte) (out []byte, err error) func (s *Scratch) Decompress4X(in []byte, dstSize int) (out []byte, err error)Decompress4X需要显式传入期望的解压后总长度dstSize。必须把压缩阶段得到的输出原封不动、尺寸精确地交给解压器——哪怕只差一个字节都会导致解压失败或输出错位此时如果收到错误你的输入极可能已损坏。并发解压无状态 Decoder对于固定表 大量并发解压的场景可以从已初始化的Scratch获取一个无状态statelessDecoderd : huff0.Decoder{...} // 由 ReadTable 后的 Scratch 初始化 out, err : d.Decompress1X(dst, src) out, err : d.Decompress4X(dst, src)Decoder只要底层的Scratch不被改动就始终保持正确可安全地分发给多个 goroutine 并发使用其中dst切片的容量即期望的解压输出大小。在 amd64/arm64 平台上Decompress4X/Decompress1X的 8-bit 表主循环会自动切换到汇编实现见 decompress_asm.go对应 decompress_amd64.s 与 decompress_arm64.s当输出小于 800 字节fallback8BitSize时Go 版本反而更快会自动回退——这正是面向现代 CPU 的 OoO 设计落到指令级的一个缩影。完整性警告重要解压成功 ≠ 数据正确。huff0 块内没有任何完整性校验解压器只保证按给定表把比特流翻译成字节。如果压缩过程或传输过程中数据被篡改解压可能顺利产出错误内容而不会报错。因此依赖解压错误来判断数据合法性是不可靠的需要保证数据完整性时必须由调用方另行计算并校验 checksum。压缩内核从直方图到比特流把 README 的接口描述落到源码一次Compress1X调用内部依次经历见 compress.goprepare校验块大小、TableLog范围重置输出切片直方图统计countSimple扫描输入统计 256 个符号的出现次数同时判断旧表是否仍可复用可压缩性判定maxCount len(in)说明输入是单一重复字节 →ErrUseRLEmaxCount 1 || maxCount len(in)7→ErrIncompressible构建编码表buildCTableoptimalTableLog计算最优表对数 →huffSort按出现次数降序排序 → 经典的两最小节点合并构建 Huffman 树 →setMaxHeight把树高约束到tableLogMax内序列化表cTable.write把权重转成 FSE 可压缩的形式优先 FSE 压缩省空间否则退回 4-bit 逐权重裸存超过 127 个符号的裸表直接视为不可压缩比特流编码compress1xDo用位写入器bitWriter按 4 符号/组批量编码tableLog 8时一次编码 4 个符号否则分两次各编码 2 个符号见 compress.go。整个过程中nodeElt被压成一个 64 位整数count/parent/symbol/nbBits 四个字段打包使得编译器可以整字加载、存储节点减少内存访问次数见 compress.go——这是典型的高性能压缩库微观优化。在 Loki 中的位置间接但关键的依赖huff0 是第三方 vendored 依赖位于vendor/github.com/klauspost/compress/huff0/Loki 本身并不直接 import 它但它位于 Loki 数据路径的最深处go.mod 声明github.com/klauspost/compress v1.19.2vendor 目录随之携带了 zstd、fse、huff0 等子包Loki 的块级压缩通过 pkg/compression/pool.go 中的ZstdPool基于klauspost/compress/zstd提供Zstd编码而 zstd 对每个块的字面量流使用 huff0 做熵编码zstd/dict.go 中以huff0.Scratch、huff0.ReadTable、huff0.Compress1X管理字典字面量编码器Loki 的日志索引文件同样依赖 zstd如 pkg/logline/internal/v3/index_file.go、pkg/logline/internal/v3/postings.go、pkg/logline/internal/v3/term_dictionary.go 均直接 importklauspost/compress/zstd。因此可以这样理解链路Loki 压缩块 → zstd → huff0。huff0 的单字节值重复返回ErrUseRLE、不可压缩返回ErrIncompressible等语义由 zstd 层消化后以 RLE/raw 块形式落入最终的 zstd 帧中最终呈现在 Loki 的存储与查询性能上。小结huff0 是一个小而锐利的库接口极简两个压缩函数、两个解压方法、一个Scratch却把快做到了指令级OoO 友好的批量位编码、amd64/arm64 汇编主循环。使用它的正确姿势可以概括为三条铁律永远处理ErrIncompressible/ErrUseRLE等正常错误它们是压缩流程的一部分而非异常复用一个Scratch前把Out置 nil并妥善记录reUsed标志以驱动对端ReadTable不要信任解压结果的正确性完整性交给调用方自己校验。需要继续深挖的读者可以从 huff0.go 与 compress.go、decompress.go 三个文件入手它们完整覆盖了常量定义、压缩主循环与解码表构建的全部实现。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki 背后的熵编码利器：klauspost/compress huff0 包原理与实战指南
Loki 背后的熵编码利器klauspost/compress huff0 包原理与实战指南【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本篇技术指南深入剖析当前仓库 vendor/github.com/klauspost/compress/huff0 子包它是 zstd 压缩器内部用于字面量literal熵编码的 Huffman 编解码器被 Loki 的块压缩链路间接依赖。读完本文你将掌握 huff0 的块模型、Compress1X/Compress4X压缩接口、错误语义、Scratch复用与表复用策略、ReadTableDecompress1X/4X解压流程以及无状态Decoder的并发解压用法。huff0 是什么为现代 CPU 设计的 Huffman 熵编码器huff0 是一个纯 Go 实现的 Huffman 编解码器其核心设计目标与 zstd 官方参考实现一致面向现代 CPU 的乱序执行Out-of-OrderOoO能力让多条算术逻辑单元ALU流水线并行处理比特流从而获得极快的压缩与解压速度。它的适用场景非常明确对存在大量相似取值的输入压缩到尽可能少的字节数。huff0 不做 LZ 类算法那样的多字节字典编码dictionary coding因此它不能替代 Snappy 等 LZ 压缩器但可以作为二级熵编码步骤叠加在 Snappy 这类只做 LZ 匹配、不做熵编码的压缩器之后进一步榨干冗余。在 huff0.go 的包注释中明确写道本包提供 zstd 所使用的 huff0 编码与解码。这意味着你几乎不需要直接调用它——但它正是 zstd 压缩链中最内层、最高频执行的熵编码模块。块模型一次压缩一个独立块huff0 对外提供的是低层low-level接口只负责压缩单个独立块每个块之间完全独立块与块之间没有任何内置的完整性校验调用方必须自己记录每个块的长度并在需要时自行计算校验和checksum单块未压缩输入的最大尺寸为BlockSizeMax 118 - 1即128 KiB 减去 1 字节见 huff0.go。这一点与 Loki 的生产场景高度契合Loki 在 pkg/compression/pool.go 中通过ZstdPool等池化接口使用github.com/klauspost/compress/zstd对应 go.mod 中的github.com/klauspost/compress v1.19.2而 zstd 内部正是用 huff0 对每个块的字面量流做熵编码。底层块格式自带长度边界与帧结构恰好弥补了 huff0 自身无完整性校验的缺口。压缩Compress1X 与 Compress4X压缩入口是两个包级函数见 compress.gofunc Compress1X(in []byte, s *Scratch) (out []byte, reUsed bool, err error) func Compress4X(in []byte, s *Scratch) (out []byte, reUsed bool, err error)Compress1X将整个输入作为单一比特流编码输出可被Decompress1X解码Compress4X把输入切成 4 个独立段每段各自按Compress1X的方式编码。输出格式为6 字节跳转表前 3 段的长度各 2 字节小端序 4 段压缩数据可被Decompress4X解码。对超过 12 字节的输入compress4X会把不足 65535 字节的段长写入跳转表见 compress.go。两者的返回值out为压缩结果reUsed指示本次是否复用了上一块的表err为可能的错误。调用时必须传入一个Scratch对象它承载了表复用所需的全部内部状态。错误语义即使正常操作也会返回的错误这是 huff0 与普通压缩库最大的不同下面这些错误在完全正常的运行过程中也会出现绝不能简单视为压缩失败调用方必须显式处理错误说明nil一切正常返回压缩输出ErrIncompressible输入被判定为太难压缩如每个符号最多出现一次或分布过于均匀见 compress.go 的maxCount 1 || maxCount len(in)7判定ErrUseRLE输入是单个字节值重复构成压缩器提示应改用 RLE 表示ErrTooBig输入块超过最大允许尺寸128 KiB(error)发生了内部错误从源码看此外还有一个 README 未列出的错误ErrMaxDecodedSizeExceeded输出超过MaxDecodedSize上限时由解码器返回以及ReusePolicyMust下无法复用表时也会返回ErrIncompressible见 huff0.go、compress.go。zstd 内部正是依赖这套语义在 zstd/dict.go 中遇到ErrIncompressible与ErrUseRLE时会分别走原样存储和RLE 块的降级路径而不是报错终止。一次典型压缩调用s : huff0.Scratch{TableLog: 11} // tableLog 合法范围是 5 ~ 11 out, reUsed, err : huff0.Compress1X(data, s) switch { case errors.Is(err, huff0.ErrIncompressible): // 存储原始数据或换其他编码 case errors.Is(err, huff0.ErrUseRLE): // 记录 RLE 标记与单字节值 case err ! nil: // 真正处理内部错误 default: // out 可用reUsed 决定接收端是否应调用 ReadTable }注意压缩器内部还会通过WantLogLess设定至少达到 log2 级别的体积缩减否则视为不可压缩的门槛默认0表示只要有任何改善即可见 huff0.go。Scratch 复用消除分配的关键每次压缩/解压都重新构造编解码表代价高昂。huff0 允许你把一个 Scratch 对象反复传入压缩与解压共用同一个对象即可。必须牢记的坑复用Scratch时其内部的Out输出缓冲区也会被复用。如果你在处理完输出之前就发起下一次压缩/解压一定要先把Scratch.Out字段置为nil否则上一次的输出会被下一次的结果覆盖。压缩和解压使用的是同一个输出缓冲。Scratch会在内部保留状态prevTable、prevTableLog等从而允许在后续调用中复用上一块的编码/解码表。此外它还提供MaxDecodedSize解压输出上限未设置时自动取BlockSizeMax超限返回ErrMaxDecodedSizeExceededMaxSymbolValue/TableLog覆盖下一块的最大符号值与表对数TableLog必须落在 5~11 之间否则prepare直接报错见 huff0.goTransferCTable(src)把另一个Scratch的压缩表拷贝过来实现跨对象传递表状态见 huff0.go。表复用策略ReusePolicy 的四种模式Huff0 允许复用上一块的编码表以节省空间但前提是这能带来更好/更快的结果。Scratch.Reuse字段ReusePolicy枚举控制该行为可在每个块之间随时切换四种模式定义在 huff0.go策略行为ReusePolicyAllow默认允许复用但只有当复用旧表产生的输出更小时才复用否则生成新表ReusePolicyPrefer激进复用。不比较新旧表体积除非旧表不可用或压缩结果比输入还大ReusePolicyNone完全禁用表复用速度略快但输出可能更大ReusePolicyMust必须复用且必须产出更小的输出否则返回ErrIncompressible复用决策的底层逻辑在compress()主流程中compress.go先做直方图统计countSimple用canUseTable判断旧表对新分布是否仍然有效旧表中对应符号的nBits必须非 0再按策略走复用旧表编码或构建新表两条路径。两个必须由调用方承担的责任表信息不会写进输出块。Compress1X/4X返回的reUsed布尔值告诉接收端这一块是否沿用了上一块的表调用方必须自己记录这个标记并据此决定接收端是否要调用ReadTable如果你想把表与数据分开存储可以直接使用Scratch.OutTable表数据与OutData压缩数据两个字段——它们是返回数据的切片视图见 huff0.go。另外EstimateSizes 可以在不实际编码的情况下估算新表体积 / 新表数据体积 / 复用旧表体积三种尺寸供上层在压缩前预判策略。解压流程先 ReadTable再 Decompress解压的第一步永远是通过ReadTable初始化解码表func ReadTable(in []byte, s *Scratch) (s2 *Scratch, remain []byte, err error)ReadTable接收完整的压缩块表 数据解析出表定义并返回remain——即紧随表之后的数据部分再把remain交给解压器。表头有两种形态见 decompress.go首字节 128未压缩的权重表每个权重占 4 bit 打包存储首字节 128FSE 压缩的权重表需先用包内的 FSE 解码器还原权重。随后调用func (s *Scratch) Decompress1X(in []byte) (out []byte, err error) func (s *Scratch) Decompress4X(in []byte, dstSize int) (out []byte, err error)Decompress4X需要显式传入期望的解压后总长度dstSize。必须把压缩阶段得到的输出原封不动、尺寸精确地交给解压器——哪怕只差一个字节都会导致解压失败或输出错位此时如果收到错误你的输入极可能已损坏。并发解压无状态 Decoder对于固定表 大量并发解压的场景可以从已初始化的Scratch获取一个无状态statelessDecoderd : huff0.Decoder{...} // 由 ReadTable 后的 Scratch 初始化 out, err : d.Decompress1X(dst, src) out, err : d.Decompress4X(dst, src)Decoder只要底层的Scratch不被改动就始终保持正确可安全地分发给多个 goroutine 并发使用其中dst切片的容量即期望的解压输出大小。在 amd64/arm64 平台上Decompress4X/Decompress1X的 8-bit 表主循环会自动切换到汇编实现见 decompress_asm.go对应 decompress_amd64.s 与 decompress_arm64.s当输出小于 800 字节fallback8BitSize时Go 版本反而更快会自动回退——这正是面向现代 CPU 的 OoO 设计落到指令级的一个缩影。完整性警告重要解压成功 ≠ 数据正确。huff0 块内没有任何完整性校验解压器只保证按给定表把比特流翻译成字节。如果压缩过程或传输过程中数据被篡改解压可能顺利产出错误内容而不会报错。因此依赖解压错误来判断数据合法性是不可靠的需要保证数据完整性时必须由调用方另行计算并校验 checksum。压缩内核从直方图到比特流把 README 的接口描述落到源码一次Compress1X调用内部依次经历见 compress.goprepare校验块大小、TableLog范围重置输出切片直方图统计countSimple扫描输入统计 256 个符号的出现次数同时判断旧表是否仍可复用可压缩性判定maxCount len(in)说明输入是单一重复字节 →ErrUseRLEmaxCount 1 || maxCount len(in)7→ErrIncompressible构建编码表buildCTableoptimalTableLog计算最优表对数 →huffSort按出现次数降序排序 → 经典的两最小节点合并构建 Huffman 树 →setMaxHeight把树高约束到tableLogMax内序列化表cTable.write把权重转成 FSE 可压缩的形式优先 FSE 压缩省空间否则退回 4-bit 逐权重裸存超过 127 个符号的裸表直接视为不可压缩比特流编码compress1xDo用位写入器bitWriter按 4 符号/组批量编码tableLog 8时一次编码 4 个符号否则分两次各编码 2 个符号见 compress.go。整个过程中nodeElt被压成一个 64 位整数count/parent/symbol/nbBits 四个字段打包使得编译器可以整字加载、存储节点减少内存访问次数见 compress.go——这是典型的高性能压缩库微观优化。在 Loki 中的位置间接但关键的依赖huff0 是第三方 vendored 依赖位于vendor/github.com/klauspost/compress/huff0/Loki 本身并不直接 import 它但它位于 Loki 数据路径的最深处go.mod 声明github.com/klauspost/compress v1.19.2vendor 目录随之携带了 zstd、fse、huff0 等子包Loki 的块级压缩通过 pkg/compression/pool.go 中的ZstdPool基于klauspost/compress/zstd提供Zstd编码而 zstd 对每个块的字面量流使用 huff0 做熵编码zstd/dict.go 中以huff0.Scratch、huff0.ReadTable、huff0.Compress1X管理字典字面量编码器Loki 的日志索引文件同样依赖 zstd如 pkg/logline/internal/v3/index_file.go、pkg/logline/internal/v3/postings.go、pkg/logline/internal/v3/term_dictionary.go 均直接 importklauspost/compress/zstd。因此可以这样理解链路Loki 压缩块 → zstd → huff0。huff0 的单字节值重复返回ErrUseRLE、不可压缩返回ErrIncompressible等语义由 zstd 层消化后以 RLE/raw 块形式落入最终的 zstd 帧中最终呈现在 Loki 的存储与查询性能上。小结huff0 是一个小而锐利的库接口极简两个压缩函数、两个解压方法、一个Scratch却把快做到了指令级OoO 友好的批量位编码、amd64/arm64 汇编主循环。使用它的正确姿势可以概括为三条铁律永远处理ErrIncompressible/ErrUseRLE等正常错误它们是压缩流程的一部分而非异常复用一个Scratch前把Out置 nil并妥善记录reUsed标志以驱动对端ReadTable不要信任解压结果的正确性完整性交给调用方自己校验。需要继续深挖的读者可以从 huff0.go 与 compress.go、decompress.go 三个文件入手它们完整覆盖了常量定义、压缩主循环与解码表构建的全部实现。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考