当前的日志平台的成本主要由下面几个方面构成：

• 采集agent消耗的CPU和内存
• 日志Kafka集群成本
• Flink集群消费的计算资源
• ElasticSearch的存储成本
• OSS的存储成本

其中ElasticSearch的存储成本是主要部分，如何优化ES的存储成本呢？当前使用的冷热存储架构，第一天的数据存储在高配的热节点中，磁盘ESSD，之后的数据存在在低配的普通云盘中。

ElasticSearch存储成本优化点：

• 推动业务减少不必要的日志输出
• 持续聚焦缩短存储时间
• 持续聚焦提高ElasticSearch的资源使用率
• 使用低成本ClickHouse的存储替换ElasticSearch

小结：尽管使用ElasticSearch冷热存储架构来存储日志，成本依旧高昂，而ElasticSearch的存储成本占用70%以上，寻找新的低成本存储方案也就成了主要解决方式。

根据测评ClickHouse存储成本可以降低到ElasticSearch的三分之一以上，下面梳理下ClickHouse特性与知识点。

众多的设计和优化成就了ClickHouse的高性能，下面找一些比较突出的点梳理下：

备注：在寄存器层面实现数据并行执行，SIMD大量用于文本转换、数据过滤、数据解压以及JSON转换等场景。

1、多主架构

• ClickHouse采用多主架构，而不是主从架构

• 意味着不像ElasticSearch有Master、Data、Coordinating等角色的区分

• 访问中集群中的任何节点均可获得相同的结果

2、数据副本

• Clickhouse的副本其他组件并无差异，多一分相同的冗余数据
• 副本是表级别的，创建表时需要使用ReplicatedMergeTree系列引擎
• 基于多主架构通过zookeeper将执行语句分发到副本本地执行

3、数据分片

• ClickHouse集群中每个节点称为分片

• 可通过集群借助于ZooKeeper执行分布式DDL语句

  CREATE/DROP TABLE ON CLUSTER my_cluster
  

• 数据通过本地表（可以使用_local后缀命名）存储，使用Distributed以外的引擎

• 分布式表不存储数据，为本地表的代理，类似于分库分表组件，需使用Distributed引擎

• 分片规则需要声明分片键，否则分布式表中只包含一个分片，失去分片的意义

选择什么样的表引擎意味着选择了不同的数据存储组织方式，ClickHouse中有合并树、外部存储、内存、文件、接口与其他六个系列引擎，其中MergeTree合并树系列为其核心引擎。

小结：基于MergeTree衍生引擎提供删除重复数据、汇总聚合、删除与修改的能力，然而他们只适合特定的场景，都在分区合并的执行，不支持跨分区。