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