lz4压缩算法

㈠ clickhouse数据压缩对比

Clickhouse 数据压缩主要使用两个方案LZ4和ZSTD
LZ4解压缩速度上会更快，但压缩率较低，
ZSTD解压缩较慢。但是压缩比例较高。
clickhouse不同压缩算法测试对比，LZ4最优。
https://www.percona.com/blog/2016/04/13/evaluating-database-compression-methods-update
以下测试主要验证业内测试的结论，测试的zstd数据会多一点，测试不是十分严谨，仅供参考。

开发(dev) 机器数量：3 cpu：40core 内存：256G disk：2.0T*10

kafka TOPIC: cdn-log-analysis-realtime。可消费数据总量363255827。数据消费4次到ck。

cdn_log_analysis_realtime lz4压缩
cdn_log_realtime zstd压缩

在/etc/metrika.xml
<compression incl="clickhouse_compression"> --指定incl
<case>
<min_part_size>10000000000</min_part_size> --数据部分的最小大小
<min_part_size_ratio>0.01</min_part_size_ratio> --数据部分大小与表大小的比率
<method>zstd</method> --压缩算法，zstd和lz4
</case>
</compression>

执行sql ：SELECT table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))*100, 0) AS 压缩率 FROM system.parts WHERE (database IN ('default') AND (table = 'cdn_log_analysis_realtime') ) GROUP BY table

分别查看不同机器的压缩比例

平均 4.85亿 数据，原始数据 105G 压缩后数据 27G ，平均压缩率 27% 。

执行sql : select toDateTime(intDiv(toUInt32(its),60)*60) as t, count() as t_c, avg(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_analysis_realtime_all where day=񟭔-12-17' group by t order by t_v desc

冷数据（第一次查询）

热数据（第二次查询）

执行sql ：
SELECT table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))*100, 0) AS 压缩率 FROM system.parts WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table

分别查看不同机器的压缩比例

执行sql :select toDateTime(intDiv(toUInt32(its),60)*60) as t, count() as t_c, avg(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_realtime where day=񟭔-12-25' group by t order by t_v desc

冷数据（第一次查询）

热数据（第二次查询）

执行sql：SELECT 'ZSTD' as 压缩方式 , table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 压缩率 FROM cluster(ctyun31, system, parts) WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table union all SELECT 'LZ4' as 压缩方式 , table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 压缩率 FROM cluster(ctyun31, system, parts) WHERE (database IN ('default') AND (table = 'cdn_log_analysis_realtime') ) GROUP BY table

测试不是十分严谨，ZSTD的ck表的数据多一点，但是不影响测试结果，仅做参考。
压缩能力上，ZSTD的压缩比例为 22% ，LZ4的压缩比例为 27% ，ZSTD的压缩性能更好。但是效果不是很明显。
查询能力上，冷数据查询，两者相差不大。热数据方面，ZSTD为 3.884s ，而LZ4为 1.150s 。ZSTD查询时间在 3.37倍 以上，LZ4的查询能力更强。
综上所述，建议使用LZ4。

集群数据量后期预估，按当前使用lz4压缩方案，3分片1副本，计算3 5.5 10*0.8(按磁盘最多使用80%算) 的硬盘能存储大概多少数据。

一天数据100亿
一天磁盘消耗 (10000000000/1453023308.0 84.98)/1024.0=0.57TB
能存储天数 3 5.5 10 0.8/0.57=231.57 day。

一天数据1000亿
231.57/10=23.1day。

㈡ mysqlbinlog的问题求助

1. 开启压缩功能后，通过 ZSTD 算法对每个事务进行压缩，写入二进制日志。

2. 新版本更改了 libbinlogevents，新增 Transaction_payload_event 作为压缩后的事务表示形式。

class Transaction_payload_event : public Binary_log_event { protected: const char *m_payload; uint64_t m_payload_size; transaction::compression::type m_compression_type; uint64_t m_uncompressed_size;

3. 新增 Transaction_payload_event 编码器/解码器，用于实现对压缩事务的编码和解码。

• namespace binary_log {

• namespace transaction {

• namespace compression {

• enum type {

• /* No compression. */

• NONE = 0,

• /* ZSTD compression. */

• ZSTD = 1,

• };

4. 在 mysqlbinlog 中设计和实现每个事务的解压缩和解码，读取出来的日志与未经压缩的原日志相同，并打印输出所用的压缩算法，事务形式，压缩大小和未压缩大小，作为注释。

• #200505 16:24:24 server id 1166555110 end_log_pos 2123 CRC32 0x6add0216 Transaction_Payload payload_size=863 compression_type=ZSTD uncompressed_size=2184# Start of compressed events!




5. 从库（或 MGR-member）在接收已压缩的 binlog 时识别 Transaction_payload_event，不进行二次压缩或解码。以原本的压缩状态写入中继日志；保持压缩状态。回放日志的解码和解压缩过程由 SQL 线程负责。

总结日志压缩过程为：

1）单位事务需要提交并记录 binlog。

2）压缩编码器在缓存中通过 ZSTD 算法压缩以及编码该事务。

3）将缓存中压缩好的事务写入日志中，落盘。

日志读取过程为：

客户端工具（mysqlbinlog、sql 线程）对压缩日志进行解压缩、解码。解压出原本未压缩的日志进行读取或回放。

注意事项

1. 压缩功能以事务为单位进行压缩，不支持非事务引擎。

2. 仅支持对 ROW 模式的 binlog 进行压缩。

3. 目前仅支持 ZSTD 压缩算法，但是，底层设计是开放式的，因此后续官方可能会根据需要添加其他压缩算法（例如 zlib 或 lz4）。

4. 压缩动作是并行进行的，并且发生在 binlog 落盘之前的缓存步骤中。

5. 压缩过程占用本机 CPU 及内存资源。在主从延迟的场景中，如果性能瓶颈时，网络带宽、压缩功能可以有效缓解主从延迟；但是如果性能瓶颈是本机自身处理能力，那么压缩功能反而可能加大主从延迟。

㈢ 二进制压缩算法有哪些

二进制数据压缩算法二进制是计算技术中广泛采用的一种数制。二进制数据是用0和1两个数码来表示的数。它的基数为2，进位规则是“逢二进一”，借位规则是“借一当二”，由18世纪德国数理哲学大师莱布尼兹发现。当前的计算机系统使用的基本上是二进制系统，数据在计算机中主要是以补码的形式存储的。计算机中的二进制则是一个非常微小的开关，用“开”来表示1，“关”来表示0。

20世纪被称作第三次科技革命的重要标志之一的计算机的发明与应用，因为数字计算机只能识别和处理由‘0’。‘1’符号串组成的代码。其运算模式正是二进制。19世纪爱尔兰逻辑学家乔治布尔对逻辑命题的思考过程转化为对符号“0‘’。‘’1‘’的某种代数演算，二进制是逢2进位的进位制。0、1是基本算符。因为它只使用0、1两个数字符号，非常简单方便，易于用电子方式实现。

二进制压缩 - 算法

二进制压缩

在编程时遇到每个数据只有两种状态，且 dfs 或者 bfs 时遍历时间复杂度高时，可以采用二进制压缩数据，尤其是二维数组。LZFSE

1，zlib和gzip都对deflate进行了封装，比deflate多了数据头和尾

1，苹果开源了新的无损压缩算法 LZFSE ，该算法是去年在iOS 9和OS X 10.10中 引入 的。按照苹果公司的说法，LZFE的压缩增益和ZLib level 5相同，但速度要快2~3倍，能源效率也更高。

LZFSE基于Lempel-Ziv，并使用了 有限状态熵编码，后者基于Jarek Duda在

非对称数字系统（ANS）方面所做的熵编码工作。简单地讲，ANS旨在“终结速度和比率的平衡”，既可以用于精确编码，又可以用于快速编码，并且具有数据加密功能。使用ANS代替更为传统的

Huffman和 算术编码方法的压缩库 越来越多，LZFSE就位列其中。

显然，LZFSE的目标不是成为最好或最快的算法。事实上，苹果公司指出，

LZ4的压缩速度比LZFSE快，而 LZMA提供了更高的压缩率，但代价是比Apple

SDK提供的其他选项要慢一个数量级。当压缩率和速度几乎同等重要，而你又希望降低能源效率时，LZFSE是苹果推荐的选项。

GitHub上提供了LZFSE的参考实现。在MacOS上构建和运行一样简单：

$ xcodebuild install DSTROOT=/tmp/lzfse.dst

如果希望针对当前的iOS设备构建LZFSE，可以执行：

xcodebuild -configuration “Release” -arch armv7 install DSTROOT=/tmp/lzfse.dst

除了 API文档之外，苹果去年还提供了一个 示例项目，展示如何使用LZFSE 进行块和流压缩，这是一个实用的LZFSE入门资源。

LZFSE是在谷歌 brotli之后发布的，后者在去年开源。与LZFSE相比，brotli 似乎是针对一个不同的应用场景进行了优化，比如压缩静态Web资产和Android APK，在这些情况下，压缩率是最重要的。

㈣ ClickHouse数据压缩

ClickHouse支持多种方式的数据压缩：LZ4和ZSTD。
关于压缩算法的测试，见 这篇文章 。简而言之，LZ4在速度上会更快，但是压缩率较低，ZSTD正好相反。尽管ZSTD比LZ4慢，但是相比传统的压缩方式Zlib，无论是在压缩效率还是速度上，都可以作为Zlib的替代品。
下面我们对比一下这两种压缩方式。压缩测试所用的表（lineorder）结构和数据来自 这里 。未压缩的数据集是680GB。
把上述数据加载到ClickHouse后，默认的LZ4压缩算法下，数据容量是184G（压缩到27%），而ZSTD达到了135GB（压缩到20%）。
如果想要使用ZSTD压缩方式，修改为如下配置即可：

压缩比率对比

压缩后的查询性能如何，我们来跑如下查询看看：

为了保持客观，查询测试会跑两次，第一次是冷数据请求，这次的数据没有被操作系统缓存，第二次是热数据情求，这次的数据已经被操作系统的内存缓存了。
LZ4的性能如下：

ZSTD性能如下：

冷数据查询情况下，两者区别不大，因为消耗在IO方面的时间，远大于消耗在数据解压缩上面的时间。
热数据请求下，LZ4会更快，此时IO代价小，数据解压缩成为性能瓶颈。
综上所述，默认的LZ4压缩方式，会给我们提供更快的执行效率，但是同时需要占用较多的磁盘容量。
ClickHouse抛开高效的SQL执行效率，数据压缩比率也是一个非常喜人的地方。使用Hadoop Node低配置服务器，再加上ClickHouse优秀的压缩性能，单机容量轻松可达几十T，推荐直接使用默认的LZ4压缩方式，用可以接受的少量空间来换查询执行效率的提升。

㈤ Kafka:如何高效运维之主题篇

作为一个 Kafka 初学者，需要快速成长，承担维护公司 Kafka 的重任，对 Kafka 的学习，我按照三步走策略：

本文属于学习的第二阶段：[ 从运维实战的角度学习 Kafka ]，重点学习 Kafka 的主题，通过运维命令创建、更新主题，从 Topic 的 可运维属性，了解 Topic 在 Kafka 内部的运作机制 。

Kafka 提供了 kafka-topics 脚步用来创建、修改、删除、查询 topic，位于${kafka_home}/bin/kafka-topics.sh，其中 kafka_home 表示 Kafka 的安装目录。

一些不那么直观的选项进行单独介绍。

收到指定副本数量和分区信息，该参数不能和--partitions、--replication-factor 同时使用。

其格式为：每一个逗号表示一个分区的配置，每一个分区分布的 broker 用冒号隔开。

--replication-factor0:1,1:2,0:2 表示的含义是什么呢？

分区数量为 3 个，其中分区 0(p0)分布在 broker 0 和 1 上，分区 1(p1)分布在 broker 1,2 上，分区 2(p2)分布在 broker 0 与 2 上。从而推出分区数量为 3，副本因子为 2，每一个分区的第一个 broker 为 Leader，其演示效果如下：

通过 kafka-topics 脚本在创建 topic 时可通过--config 选项来定制化 topic 的属性，接下来试图从这些属性来探究 Kafka 背后的运作机制。

数据文件清除机制，支持 Broker 全局配置，Topic 定制化制定，可选策略：delete、compact，默认值为 delete。Kafka 提供了数据段压缩的功能，按照相同 Key 只保留最新 Key 的策略，减少数据段大小，系统主题__consumer_offsets(用于存储消息进度的主题)其清除策略就是 compact。

压缩类型，Kafka 目前支持的压缩算法：gzip,snappy,lz4,zstd，还支持如下两个配置：

不开启压缩

由发送方指定压缩算法，客户端的可选值为 gzip,snappy,lz4,zstd。

数据进行压缩，能节省网络带宽与存储空间，但会增加 CPU 的性能，故 最佳实践 ：Broker 服务端不配置压缩算法， 由发送方指定，在发送方进行压缩，服务端原封不动进行存储，并且在消费端解压缩 。

如果 cleanup.policy 策略为 compact 时，针对消息体为 null 的消息，Kafka 会认为对其进行压缩没有意义，立马删除也太草率，故 Kafka 引入了该参数，用来设置这些 body 为 null 的消息，在一次压缩执行后，多久后可被删除，默认值为 24h。

文件在删除时延迟时间，默认为 60s，Kafka 中可以支持按 topic 删除日志文件(数据文件)，执行删除之前，首先会将该 topic 下的分区文件重名为*.deleted，等待 file.delete.delay.ms 才从文件系统中删除。

按消息条数设置刷盘频率，如果设置为 1 表示每写一条消息就触发一次刷盘，默认值为 Long.MaxValue，在大部分场景 官方不建议设置该值，直接利用操作系统的刷盘机制即可，Kafka 希望通过副本机制能保证数据的持久可靠存储 。

按时间间隔设置刷盘频率，默认为 Long.MaxValue，Kafka 希望借助操作系统的刷盘机制，数据可靠性通过副本机制来保证。( 副本机制其实无法保证同机房断电带来的数据丢失 )

索引文件的密度，Kafka 并不会为每一条消息(消息偏移量)建立索引，而是每隔一定间隔，建立一条索引。该参数就是设置其间隔，默认为 4096 个字节。

一次消息发送(Batch)允许的最大字节数量，默认为 1000000，约等于 1M。

是否开启消息格式的自动转化，如果设置为 false，Broker 不会执行消息格式转化，将不兼容老的客户端消费消息。

可以指定该主题按特定版本的 API 版本所对应的存储格式进行存储。

设置消息中存储的时间戳的获取方式，可选值：

消息在客户端的创建时间

Broker 服务端接收到的时间，默认为 CreateTime。

当 message.timestamp.type 设置为 CreateTime 时，允许 Broker 端时间与消息创建时间戳最大的差值，如果超过该参数设置的阔值，Broker 会拒绝存储该消息， 默认为：Long.MaxValue，表示不开启开机制 。

控制可压缩的脏数据比例，默认为 0.5d，如果一个文件中"脏数据"(未被压缩的数据)低于该阔值，将不继续对该文件进行压缩，该方法生效的条件为 cleanup.policy 设置为 compact 。

设置一条消息进入到 Broker 后多久之内不能被 compact，默认为 0，表示不启用该特性，该方法生效的条件为 cleanup.policy 设置为 compact 。

如果客户端在消息发送时将 ack 设置为 all，该参数指定必须至少多少个副本写入成功，才能向客户端返回成功，默认为 1，这个是一个兜底配置，all 的含义表示在 ISR 中的副本必须全部写入成功。

是否开启预热文件(提前创建文件)，默认为 false。

一个日志分区保留的最大字节数，默认为-1，表示不限制。

一个日志分区允许保留的最大时长，默认保留 7d。

一个日志段的大小，默认为 1G。

一个日志段索引文件的大小，默认为 10M。

段滚动的最大随机差。

Kafka 强制滚动一个段的间隔时间，及时该段并未全部填满消息，默认值为 7d

是否允许不在 ISR 中副本在没有 ISR 副本选择之后竞争成为 Leader，这样做有可能丢数据，默认为 false。

本文从运维命令开始学习，从使用运维层面全面了解 Topic，从而窥探其 Kafka 内部一些重要特性，为后续从源码角度研究其实现打下坚实基础。

本文的最后给出一个分区数量为 3，副本因子为 3 的 topic 分区图来结束本文的讲解。

㈥ 打ab包时如何打需要更新的内容

AB分配策略：
确定如何将项目的资产划分为AssetBundles并不容易。关键决策是如何将对象分组到AssetBundles中。以下是unity手册提供的主要策略是：

1. 逻辑实体分组（Logical Entity Grouping）
例子

捆绑用户界面屏幕的所有纹理和布局数据
捆绑一个角色/一组角色的所有模型和动画
捆绑跨多个级别共享的场景片段的纹理和模型
最常用的策略：按功能出现需要的资源，将需要的资源捆绑到一个ab里，这样，加载该功能界面的时候，只要加载该ab就可以，如果功能比较复杂，可以视情况拆分粒度 逻辑实体分组是可下载内容（DLC）的理想选择，因为通过这种方式将所有内容分开，您可以更改单个实体，而无需下载其他不变的资产。
使用前提：开发人员必须精确地了解项目将在何时何地使用每种资产。
2. 类型分组（Type Grouping）
预制
音频
热更脚本
类型分组是构建供多个平台使用的AssetBundle的较好策略之一。
3. 并发内容分组（Concurrent Content Grouping）
每个关卡都包含完全独特的角色，纹理，音乐等
基于场景的包，每个场景束应包含大部分或所有场景依赖关系。
这些资产将同时加载和使用。
最后，无论您采用哪种策略，以下都是一些可以全面记住的其他提示：
将经常更新的对象与很少更改的对象分离
把需要同时加载的Asset尽量打包到同一个AB里。例如模型，其纹理和动画。
如果一次经常加载少于50％的捆绑包，请考虑将其拆分
如果您发现多个AssetBundle中的多个对象都依赖于完全不同的AssetBundle中的单个资产，请将依赖关系移至单独的AssetBundle。
根据依赖树进行的最优打包策略，公共资源单独打ab，独立资源打到一起。
如果不太可能同时加载两组对象（例如标准和高清资产），请确保它们位于自己的AssetBundle中。
考虑合并较小（少于5到10个资产）但经常同时加载其内容的AssetBundle
如果一组对象只是同一对象的不同版本，请考虑使用AssetBundle Variants
通常情况下，1M左右的AssetBundle包加载性能最好，冗余也可以接受，但是在Unity 5.3版本之后，对于AB文件的文件大小其实不必再限定于1MB之内。使用LZ4压缩，基于其Chunk的加载特点，AB加载很快，且内存占用要比之前小很多。所以LZ4的AB其实可以考虑更加粗粒度一些。
shader字体等其他细碎并且需要常驻内存的资源打包到一起，启动游戏的时候常驻内存。
根据项目实际需求将需要经常热更新的资源进行单独打包。
————————————————
版权声明：本文为CSDN博主原创
原文链接：https://blog.csdn.net/qq_39329287/article/details/122109028