Navigation menu
同时 ClickHouse 基于列存，还提供了很高的压缩比。压缩算法 lz4 可以到 1:4 ，zstd 可以到 1:10 。本文主要是介绍我们在 ClickHouse 上面的实践，对于 ClickHouse 本身的特性及相关介绍就不在这里赘述了。
ClickHouse 创建表时是支持表级数据 TTL 策略的，TTL 策略可以支持数据过期自动合并(Compaction)后删除，当然也支持自动合并后移动到其他Disk或Volumn。日志平台的多级存储就是利用了存储策略，但由于踩了TTL的一个坑，我们最终放弃表级TTL设置，改成搬迁表part的任务调度实现TTL策略，后面会说到。
创建表级 TTL ，要想使用分级冷热存储，必须要指定存储策略，才能使用到 Disk ，为什么要指定存储策略，我的理解是TTL可以指定到 Disk 和 Volumn 级，但是 Volumn 级别只能定义在存储策略里。
PARTITION BY--分区键，表级可选的参数。在大多数情况下，其实不需要分区键，同时即便使用了分区键，不太建议使用比月更细粒度的分区键，分区不会加速查询（与 ORDER BY 表达式相反）。你永远不应该使用太细化的分区。不要按客户端标识符或名称对数据进行分区，而是将客户端标识符或名称作为 ORDER BY 表达式中的第一列(官方文档这句话还是要好好牢记，一般我们只建议时间字段做分区)。
以上是官方文档的原话，但是实际中我们需要根据具体情况是可以创建甚至到小时级别粒度的分区，还是那句话，看需求，用不好会有副作用，后面会提到。
业务背景中除了提到需要很高的写入能力，很高的压缩比，实际需求调研中，基础架构同学还提出各个业务域都有自己的日志时间查询范围需求(ES作为存储时，研发甚至需要能够提供天级的日志保留时间)，比如7天，30天，90天，甚至更长等不同范围，因为冷数据查询频次较低，可以使用更低廉的存储介质，另外有一些数据保留一段时间之后不会被查但需要满足合规要求，再长的日志就可以删除。基础架构希望DBA能够帮忙在ClickHouse的存储上对数据保留时间提供一些建议，尽最大可能降低存储成本。
最初我们期望使用分区策略，用应用名称+环境+按天分区的组合分区策略来满足要求，即PARTITION BY (application,environment,toYYYYMMDD(log_time))。这样每个应用每个环境有独立的分区，业务研发还可以很灵活的随意修改天级的日志保留时间，这样每个分区可以根据保留策略独立的移动到不同的磁盘。理想很丰满，现实很骨感。虽然这个方案可以很好的满足需求，但是真正写入的时候，我们遇到了问题，由于线上应用在较多，且还在呈上升趋势，每个应用还可能有多个环境，即便每个应用每天只写入到一个天分区，实际测试过程中，我们发现写入性能严重不足，写入很慢，同时碰到多个参数值不够报错的问题。
意思是一次插入的数据块涉及到的分区数量。由于日志是消费的kafka一个某个topic，一个topic可能有几百个应用，每个应用还有多个环境，即便写入天级分区，分区是物理上隔离成不同的目录，一次写入也会被ClickHouse拆分成几千个不同partition中的part，一次insert涉及到的partition数爆炸，提示插入数据的part数量超过该参数值(too many partitions for single insert blocks)，远超参数设置，100根本不够，调整到1w还是报错。写入量不是很大的情况下，是可以适当调整该参数，但测试环境日志产生的实在太碎，上调该参数很快就有too many parts的报错，too many parts的出现就是ClickHouse合并跟不上写入，直接拒绝写入数据，这就是下面的参数max_parts_in_total值不够。
测试环境中由于有一些应用数据较少，导致攒批数据比较难，加上若代码在批次写入数据的地方处理不好，很容易出现频繁写入较少数据行的part，加上应用数，环境较多，导致写入的数据较碎，一个表内active的part数据非常容易超过10w(可以查看system.parts表中状态为active的数据个数)，多次报错too many parts in total的错误。这里可以适当提高background_pool_size的值提升合并速度，但是对于大量较碎的part也是杯水车薪，不能解决根本问题。最终我们放弃方案1，选择方案2。
方案1的问题最主要还是分区字段设置的问题，我们决定在满足写入能力的前提下提供一定能力的日志保留时间。最终将分区字段去掉应用名称application字段(为了保证查询速度，我们将application字段放入到order by的第一个字段。
由于三级保留策略，最开始想到用多个表即我们定义日志保留时间范围的固定选项(7d,30d,90d,180d)，日志保留时间需要研发做一些妥协，不能随意修改保留时间，根据这几个选项创建对应的表，这样能发挥写入的最佳性能。但是会有一个问题，就是当研发提工单修改应用的保留时间后，时间调整会导致日志落入不同的表，这样代码中查询语句不变的情况下会出现变更保留时间后查不到历史数据的问题，虽然可以代码做一定的路由规则，但很繁琐，不够友好，放弃该方案。
如何解决？经过我们讨论，我们想到一个方法，表中添加两个字段log_save_time，oss_save_time，这两个字段是int类型，将分区字段调整为PARTITION BY (toDate(log_time), log_save_time, oss_save_time)。log_save_time为每条日志在hot盘中保留的时间，超出会被任务移动到cold盘；oss_save_time为每条日志在cold盘中保留的时间，超出会被移动到arch盘(这里的移动任务会在下面介绍到)。任务每天会查询system.parts表，查看分区字段中三个字段对比，即toDate(log_time)和当前日期比较，差值大于分区中log_save_time的值，则移动该分区到cold盘，差值大于oss_save_time则移动到arch盘。这样如果应用日志保留策略的元数据信息修改，新产生的日志数据这两个字段也会写入新的保留策略值，新数据会落到不同的分区中。那么如何实现？进入问题2。
优点是利用ClickHouse自身的能力做数据的搬迁，实现过期数据迁移到冷存储介质。
但会有一个问题，就是会导致前面提到的会根据多个可选时间范围创建多个对应的表。
另外还有一个坑就是，表级TTL一旦要修改TTL的保留时间，ClickHouse会reload表的所有part目录，导致IO Util打满，集群无法响应，这个很坑，目前还没有好的办法解决，所以放弃该方案。
结合问题1，最终我们选择这样创建表结构(只作为 Demo 参考，并非业务真实情况)，如下：
日志平台会起一个调度任务，同时维护应用和(log_save_time,oss_save_time)的对应关系。每天根据该表的信息做应用对应日志分区的搬迁动作。
但这里也有一个小问题就是当研发需要修改日志保留时间时，比如保留时间调大，则新的数据会落到新的分区里，这样之前的分区会因为匹配规则原因被提前删除，比如 7 天调整到 30 天，那么由于之前保留时间在分区中还是7这个值，到了第7天，之前的分区已经满足删除策略会被删除。虽然改成 30 天保留策略，依然会出现有7天日志查不到的情况，当然时间往后推移7天后还是能查到完整的 30 天日志。反之保留时间调小，比如从 30 调整到 7 ，会出现最长有 23 天的日志被持续保留，空间没有及时释放。时间推移 23 天后空间释放。这些问题不要紧，可以容忍，对比多个表的方案，该方案利大于弊，最终选择该方案。
解决了过期策略，表结构的设计后，前面提到的arch磁盘来存储基本不查的数据，使用低存储成本介质来降低成本，我们首先想到的就是能不能使用OSS？答案是可以，同时我们查看过费用，同等容量的 OSS 成本仅是 ESSD PL0 的三分之一，这无疑可以大幅降低存储费用。但怎么用最优，需要调研+测试。
JuiceFS主要功能就是将 S3 转成文件系统挂载使用，且在多家知名互联网公司都有上线案例( 某海外电商平台的公开技术分享文章就提到了基于 JuiceFS 实现的 ClickHouse 冷热分离存储)，因此我们基于这些信息开始调研这个方案的可行性。
JuiceFS 是一款面向云原生设计的高性能共享文件系统，在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性，可将几乎所有对象存储接入本地作为海量本地磁盘使用，亦可同时在跨平台、跨地区的不同主机上挂载读写。
JuiceFS 采用「数据」与「元数据」分离存储的架构，从而实现文件系统的分布式设计。使用 JuiceFS 存储数据，数据本身会被持久化在对象存储（例如，Amazon S3），相对应的元数据可以按需持久化在 Redis、MySQL、TiKV、SQLite 等多种数据库中。
当时考虑 JuiceFS 的另外一个原因是它的读缓存机制，当访问 JuiceFS 中的文件时，会有多级缓存给经常访问的数据提供更好的性能，读请求会依次尝试内核分页缓存、JuiceFS 进程的预读缓冲区、本地磁盘缓存，当缓存中没找到对应数据时才会从对象存储读取，并且会异步写入各级缓存保证下一次访问的性能。
可见 JuiceFS 支持将对象存储挂载到 ECS 上，通过文件系统做本地盘访问，同时支持读缓存来加速文件读取，我们也做了测试，确实读写性能还不错。
Ubuntu 24.04 进入开发阶段，代号 Noble Numbat
推特年度工程总结，数据感人，什么代码减少 60 万行、节省 1 亿美元
AlmaLinux 9.3 Beta 发布，CentOS 最佳替代方案之一
SunnyUI V3.5.2 发布啦，C# WinForm 开源控件库
wmproxy 0.1.2 发布，支持反向代理/正向代理/内网穿透等功能
Gitee 推荐 基于 React 技术栈的工作流高阶组件 Antd-bpmn
新一代国产 ORM 框架，sqltoy-orm 5.2.74 发版，GaussDB 完成全面生产验证！
云数据库是杀猪盘么，去掉中间商赚差价，aws数据库性能提升 10 倍！价格便宜十倍。
聚焦企业开放OpenAPI痛难点，华为云API Explorer助力构建API门户
CVE-2023-36874：Windows 错误报告服务权限提升漏洞通告
探索平台工程实践，vivo 与您相约上海 KubeCon & CloudNativeCon
Unity中国、Cocos为OpenHarmony游戏生态插上腾飞的翅膀
OpenSSL 3.0.0 设计（二）｜Core 和 Provider 设计
openEuler 亮相华为全联接 2023 使能全场景创新，夯实算力底座
EasyNVR接入EasyNVS，出现“Login error, i/o deadline reached”的解决方法
JetBrains 中国招新：Support Engineer/Customer Success Engineer
云场景难以挑选底座操作系统？NestOS双模式版本云场景全覆盖正式发布！
3步体验在DAYU200开发板上完成OpenHarmony对接华为云IoT
科学家首次为地球“全面体检”；国产光刻机或系误传；推特或将按月收费丨RTE开发者日报 Vol.52
社区供稿 微调百川Baichuan-13B保姆式教程，手把手教你训练百亿大模型
在可重复读（Repeatable read）事务隔离机制下，下面那种情况不会发生？
Hugging News #0710: 体验 MusicGen、Diffusers 库发布一周年、我们的内容政策更新
天谋科技时序数据库 IoTDB 与 openEuler 操作系统完成兼容性互认证
TiDB 7.1.0 LTS 特性解读 浅析 TiSpark v3.x 新变化
使用 AutoGPTQ 和 transformers 让大语言模型更轻量化
Python从0到1丨详解图像锐化的Sobel、Laplacian算子
使用 UCS(On-Premises) 管理您的GPU资源池，释放AI大模型算力潜能
推出 RustRover – JetBrains 出品的独立 Rust IDE
猜来猜去，直接去看雷军的公众号不就清楚了，“它基于深度进化的Android以及自研的Vela系统融合，彻底重写底层架构，为未来百亿设备、百亿连接做好了万物互联的公有底座。”
国外企业抱团定标准，国内企业分裂各自为政。IOT自己的标准，快充自己的标准，操作系统没做强也就先搞分裂
常规升级，CPU提升30%，GPU25%。 去年8Gen2 牙膏挤爆了，GPU直接提升50%多好像，干翻了A16
要不是一直有在跟新闻大致了解每行文字的实际细节和后果, 我会以为Mask是个神