ClickHouse 介绍
ClickHouse 是一款当前非常流行的开源在线分析型数据库。ClickHouse 主要应用于实时数仓构建、大数据加速分析、宽表日志分析等通用场景，服务于流量漏斗分析，用户行为分析，人群圈选，用户画像，广告投放人群评估、ABTest 、大促分析，CDP/DMP 等业务场景，在电商平台，新零售、游戏、广告、社交应用，在线旅游，本地生活，交通物流等行业都有广泛典型的应用案例，国内大厂阿里，字节，腾讯，快手，携程，京东，小红书等都有大规模的业务使用。
ClickHouse 开源关注度增长非常迅速，在 DBEngine 网站公布的2022 年RDBMS 产品类目产品关注度排行榜上，ClickHouse 年度关注度排名提升30名，整体排名28位。 以下是当前在线分析数据库/实时数仓领域的几款高热度产品的流行关注度趋势，ClickHouse 和 Greenplum 为开源产品，其他几款为闭源商业产品。
ClickHouse 之所以得到这么高的关注度，主要由两个核心的因素决定:
一是市场驱动。当前企业客户整体业务数量规模增大，而业务实时分析决策的需求明显，触发了对在线分析型数据库/实时数仓的需求增强；
二是产品选型，流量和用户的竞争激烈的大环境下，促使业务行为和决策更有时效性，从而提高留存率和转化，因此对数据分析引擎的性能响应要求越来越高。同时业务分析维度增多，分析数据来源多，分析数据规模膨胀，对成本控制的需求也非常明显。ClickHouse 基于列式存储，向量化执行引擎和SIMD（单指令多数据流），稀疏索引，分布式计算，多核并行等核心技术以及优秀的工程实现，实现了高压缩比数据存储，高效的数据写入吞吐和亿级记录95%查询秒级返回的优异性能。
社区官网公布的性能测试结果显示。ClickHouse 相比 MySQL 在分析性能上有500倍以上的提升，相较于 Greenplum 等分析引擎在聚合分析场景也有 20倍以上的性能提升。
自建ClickHouse 使用问题
我们可以看到 ClickHouse 凭借其卓越优异的性得到广大开发者关注，并在头部的互联网企业得到了比较多的应用。但实际上从我们调研了解到，企业自建ClickHouse 在非超大型企业里生产环境普遍没有大规模使用，觉得大多数情况是在小规模创新型业务场景验证，或者还在调研测试阶段。这种情况归结起来主要是以下三类主要原因造成。
内核稳定性问题多
ClickHouse 社区迭代的非常快，版本迭代可以保持每个月一个二级版本发布，多个版本同时迭代，新版本的发布除了新feature的发布以外，通常包含大量的 bugfix ，同时这两类的功能更新也会带来大量新的bug ，导致生产环境高频的遇到功能性的bug ，而社区版本bug修复的时间又不可预期， 存在稳定性隐患，因此用户在生产环境不会轻易进行大规模的应用。
缺乏实践经验
ClickHouse 提供了非常丰富的表引擎类型。支持数据链路类的引擎如： Kafka 引擎，HDFS 外表擎。也有不同的主键聚合逻辑的引擎，支持不同的业务场景如支持主键替换的 ReplacingMergeTree，支持基于主键字段求和的 SummingMergeTree，支持自定义函数聚合的 AggregatingMergeTree 等等。 这些引擎功能丰富的同时，也增加了使用的复杂度，需要根据业务需求来选型引擎。同时ClickHose 具有一些隐含的异步操作，在数据实时性和一致性有要求时需要通过特定的强制合并逻辑和定时处理来实现实时性和一致性的要求。这些经验在社区沉淀的较少，高水平的专家实践指导优化资料比较少，那么导致缺失实践经验，自建开发成本高和业务落地周期长。
自运维成本高
ClickHouse 开源版运维支撑比较弱。遇到稳定性的问题，需要有专业的团队进行内核bug 的修复， 其次ClickHouse 作为数仓类产品需要和上下游的各个数据链路进行打通，开源版只提供基础的数据链路对接能力，链路稳定性维护的成本也随之增加，而组建独立ClickHouse 开发运维团队成本非常高。
特别要提到的是 ClickHouse 扩容问题。ClickHouse 分布式模式是基于shard 分片，如下图所示，单个shard节点包含计算资源和存储资源，计算资源和存储资源耦合绑定在同一个shard节点。水平扩展会遇到两个问题：
如果遇到某个shard 节点的磁盘打满或者计算资源不足的时候，需要通过增加计算节点，分担数据存储和计算负载。基于开源版本架构设计，需要单独进行计算扩容或者存储扩容时，因为存储和计算的耦合，那么必须计算资源和磁盘存储一起扩容，而这样就会造成一定程度资源浪费，资源利用率降低。
另外一个问题是，进行水平扩容后，由于增加了shard 节点，为了保持资源查询负载的均衡，那么需要将原有的shard节点的数据按在扩容后在所有的shard 节点上进行 Rebalance 。 Rebalance的过程需要进行历史数据进行迁移和重新写入，数据量大的情况下迁移周期长，影响正常业务数据写入，业务侵入性太高。
以上三方面的问题会导致不具备大规模运维系统构建和内核修复能力的企业来说，使用自建 ClickHouse的ROI 将会非常低。
云数据库ClickHouse 社区兼容版架构图
阿里云数据库ClickHouse 云原生版本
阿里云数据库 ClickHouse 云原生版是在开源内核版本基础上，基于云的基础设施进行架构和能力升级。集成云企业级运维能力，增强易用性，降低运维成本；并进行资源解耦，提供更细粒度的资源使用控制，并提高资源的利用率和弹性效率，实现实时企业分析场景的降本增效，提高决策效率和业务收益。
云原生版运维能力
云原生版提供全面运维能力，满足企业客户 ClickHouse 运维需求，部分能力如下：
PAAS级服务，免部署轻运维，开箱即用。
企业级数据链路对接。包含离线的 OSS，ODPS ，HDFS ，HIVE ,MaxCompute 以及实时的MySQL，Kafka ，Flink 数据源对接。生产级MaterializedMySQL ，增强支持表级实时数据同步，增强容错处理和数据一致性保证。支持 DataWorks ，Spark ，SeaTunnel ,DataX 等企业级和开源数据集成和调度平台。
数据安全性全面提升，支持存储加密，HTTS/SSL 存储加密，数据备份恢复。
监控告警体系支持，提供资源层和数据库引擎层的监控告警和慢SQL的监控处理
企业级资源管理能力，支持实时升降配和扩容，支持Terraform 等。
内核稳定性支持，bug 发现后及时修复，保证稳定性。
专家服务支持，给予稳定性保障和最佳实践的支持
云原生版优势特性
云原生版本进一步实现资源解耦，实现存储计算资源解耦，提高性价比和弹性效率。具体特性如下
【存算分离】云原生版本采用存储计算解耦架构，可以根据生产需求独立进行计算或者存储计算的扩缩容，资源管控粒度更细，整体成本更加可控。
【缓存加速+共享存储】
计算层加入ESSD缓存层，缓存层加速写入和查询，根据业务负载需求可弹性扩展缓存层，保证实时查询效率。
持久化数据存储使用更低成本的存储介质，按照30%的缓存和持久化存储配比，整体存储成本下降60%。
【存储使用】持久化存储使用低成本存储介质，按小时统计实际使用量，无需容量规划，存储资源使用率达到100%，更具性价比。
【计算资源池化】云原生版本计算资源采用计算组资源服务化模式，直接根据需求选择计算组规格，无需关心计算组内部节点规格和节点数量，依据业务需要进行资源扩缩容，更简单。
【高效弹性】云原生版本采用 ShareDisk 模式，计算资源扩容无持久化数据迁移过程，扩容稳定性提升，扩容效率提升10倍以上。
云原生版的实例购买和使用方式
第一步：选择计算资源，含内存和CPU资源。云原生版对计算资源进行的封装，用户无需选择节点规格和节点数量，只需选择整体依赖的计算资源即可。
第二步：选择缓存资源。缓存加速写入和查询，根据写入量和查询性能表现选择，实例创建后可以根据性能调节缓存大小。
第三步：进行数据写入和访问。存储资源无需提前购买，按需使用，根据实际数据写入量动态计量。
云原生版实例购买模式示例
云原生版本的几个疑问
问题1 ：云原生版本缓存和社区兼容版冷热分层的热数据层有什么区别？
答： 云原生版本和社区兼容版冷热数据分层都有数据分层逻辑。区别在于云原生版本的持久化层数据为全量数据， 缓存为部分数据，按照实际查询结果自动选择缓存数据。而冷热分层及多盘是预设存储分层，根据用户根据业务规则预先将数据划分为冷数据和热数据，冷热数据都是非全量数据，业务定义为冷数据的存储在冷数据层，不会根据查询热度自动转变为热数据，冷热数据转换需要修改数据定义规则或者手工搬运分区数据。
问题2：ClickHouse 使用大数据量的低成本的存储 ，能做到实时分析吗？
答：云原生版本增加了缓存层，使用ESSD盘作缓存。 数据写入过程先写入到缓存层，保证写入效率，而后写入到全量的数据持久层存储。查询依赖数据也会缓存到缓存层，提高查询速度。缓存层根据特定的算法进行数据有效性控制和淘汰的机制。缓存层资源可以基于资源使用率监控和查询效率进行手动的扩缩容操作，整体保证查询效率。
云原生版本未来的演进计划
阿里云数据库ClickHouse 云原生的版本后续的产品将朝着提高资源利用率，提高性能，智能运维三个指标方向进行迭代。
一是全面 Serverless ，实现无需进行计算资源的预设 ，根据负载实时进行动态资源的调整，充分提高资源利用率。
二是进一步资源解耦，精细化资源使用粒度，资源配比的动态调整，实现不同业务场景对不同计算资源维度的差异化需求。
三是自动化智能运维，逐步从人工定位问题到自动巡检，人工优化到自动报告建议，部分实现智自动诊断和自优化，提高智能诊断优化的问题拦截率和满意度。
