关于云数据库ClickHouse
ClickHouse是一款开源的列式分析型数据库，自从2016年开源以来在全世界开源社区内的受欢迎程序逐渐上升，GitHub上Star数目已经超过了Presto、Impala、Greenplum等开源时间更久的老牌经典项目。在国内，ClickHouse也越来越火，诸多互联网大厂都纷纷在内部业务中跟进使用并且普遍反馈性能优异。另外云厂商也推出了对应的云上托管服务，阿里云就已经推出了云数据库ClickHouse。
云数据库ClickHouse不仅面向公共云客户售卖，同时也在阿里巴巴集团内部承担着重要业务。2020年双十一，云数据库ClickHouse承载了阿里巴巴集团OLAP平台全量查询日志的存储分析，单日400亿级别增量数据导入，全量千亿级别数据聚合分析毫秒返回，平均10倍存储压缩率；提供的超低成本、超高性能的日志查询分析解决方案，助力监控告警、错误排查、查询Pattern分析、OLAP全景大屏、重点实例保障等业务场景稳定运行。下文将深入分析云数据库ClickHouse的核心技术。
云数据库ClickHouse核心技术解析
稳定高效的管控能力
开源ClickHouse的特色是性能十分优异，但是在运维上却相对比较复杂。自建ClickHouse往往面临着安全管理、扩缩容、配置管理、SQL查询分析、Failover高可用等多方面的挑战。云数据库ClickHouse基于开源ClickHouse内核，为之配备了稳定、高效、全方位的管控能力。
• 安全增强
在管控操作方面，借助于阿里云RAM身份鉴权服务，云数据库ClickHouse控制台提供了多用户登陆、子账号授权、跨账号授权等多种能力，方便企业客户按照自身需要合理切分权限体系，既保证权限可用，又不至于过度授权。搭配数据管理服务DMS，提供数据工单审批机制，进一步限制查询、导出、修改等权限的使用范围。
在网络链路方面，默认情况下只提供VPC endpoint，只能在内网联通，降低数据泄露风险；同时也保留了开通公网endpoint的能力，让客户自由选择。白名单机制配合ECS安全组策略，确保了只有指定IP Range能够访问数据库服务，进一步增强链路安全。
• 集群配置管理
ClickHouse是松散的share-nothing架构，一个集群往往有多个server共同构成。一般情况下，要修改配置需要逐台登陆机器进行修改，非常耗时费力而且容易出错。如何保持多台server上的配置一致性，也是个难题。
云数据库ClickHouse从2个方面增强了配置管理功能。首先，对于用户配置，修改数据库内核提供了新语法 set global on cluster default key = value，一行SQL即可修改所有server的用户配置，并且自动持久化。其次，对于系统参数，通过控制台页面提供可视化的修改功能，不仅能自动校验参数合法性，而且根据内核原理判断是否需要重启才能生效。最后，通过后台任务检查，确保所有server参数一致。
• 扩缩容&升降配
水平扩缩容、垂直升降配是数据库必备的能力，确保数据库集群能够动态满足业务需求。但是扩缩容无法自动rebalance数据、无法自动迁移库表结构等，是社区版本ClickHouse的一大痛点。
云数据库ClickHouse内在的实现了扩缩容场景下数据自动rebalance的能力，确保集群成员变更后能够不同server之间负载均衡。基于管控和内核的共同优化，自动rebalance数据的速度可以高达单机100MB/S~200MB/S，而且支持迁移本地表、分布式表、外部表、物化视图、词典、集群配置、安全白名单等多种数据库对象。
云数据库ClickHouse也提供了垂直升降配的能力，在不改变集群节点个数的情况下，完全动态的调整CPU、Memory、Disk的规格，在高峰期升配满足业务需求，在低峰期降配节省成本。
• 监控告警及SQL分析
云数据库ClickHouse提供开箱即用的监控界面，包括了丰富的性能及集群状态指标，如CPU利用率、内存利用率、磁盘空间及使用率、查询QPS、写入TPS、ZooKeeper延时等。搭配阿里云云监控产品CMS， 实现了强大的告警能力，支持客户按照业务特点灵活的自定义告警规则，比如可以通过页面拖拽的方式实现磁盘使用率超过80%时自动短信、电话、邮件告警等。
在监控告警的基础上，云数据库ClickHouse进一步提供了SQL分析的功能，帮助客户定位引起系统异常的原因。SQL分析功能能够自动识别系统中的慢SQL，并且展示这些慢SQL的执行统计信息，如耗时、执行状态、扫描数据量等。
流畅通达的数据链路
分析业务往往需要从不同数据源头汇聚数据，并最终基于多方数据给出分析结果。数据导入导出是否有相应的通道支持、速度是否满足性能要求，直接决定着分析业务的开发效率和产出质量。
云数据库ClickHouse提供了完善的云上数据生态。当前支持的数据源包括：
1）RDS MySQL及自建MySQL：配合阿里云数据传输服务DTS，云数据库ClickHouse实现了从RDS MySQL实时增量导入数据到ClickHouse。通过batch化写入，既保证了增量导入的性能，又提供了可控的同步延时。通过将delete/update转化为insert，避开了ClickHouse对于delete/update的限制，消除了常见的too many parts报错。另外，云数据库ClickHouse还支持批量自动迁移MySQL库表结构到ClickHouse，智能的根据MySQL库表特点、ClickHouse集群特点，从ClickHouse十几种表引擎中选择最合适的表引擎，并设置合理的引擎参数。
2）日志服务SLS：日志是分析数据的一大来源，云数据库ClickHouse打通了与日志服务SLS的数据迁移通道。能够自动识别SLS的数据schema，实时增量同步数据。同时，也提供了丰富的日志传输监控功能，包括导入速度、错误率、当前CPU/MEM消耗等。
3）MaxCompute（原ODPS）：离线数仓中往往存储着海量历史数据，但是在业务越来越趋近实时化的大背景下，离线计算的性能已经无法满足要求。因此将热数据导入到ClickHouse中进行计算加速，是常见的业务架构。云数据库ClickHouse支持以外表方式直接导入MaxCompute数据，借助于精心实现的导入架构，云数据库ClicckHouse支持集群内多机并行、单机内多线程并行导入，能够实现单机80MB/S~100MB/S的导入速度，而且伴随着集群机器台数的增长，完全可线性拓展。
4）对象存储服务OSS及分布式文件系统HDFS：在OSS/HDFS中往往存储着大量Parquet、ORC、CSV等格式的对象文件，云数据库ClickHouse同样支持以外表方式直接导入各种格式的原始数据。
除了以上数据源，云数据库ClickHouse还支持Spark、Flink、Kafka等多种数据源的导入功能。
极致优化的内核技术
基于开源ClickHouse，云数据库ClickHouse实现了大量的内核优化及新功能开发。
• 维度表
开源ClickHouse提供了词典功能来模拟维度表，该方法存在以下问题：1）需要从外部数据源如MySQL中加载，对于词典数据的管理需要在其他系统中进行，业务上实现逻辑相对复杂且无法在ClickHouse中实时感知词典变化；2）词典数据需要一直保存在内存中，当词典数据较大且个数较多时，内存耗用大；3）使用时，需要通过dictGet等函数进行读取，不符合常规SQL使用习惯。
云数据库ClickHouse原生实现了维度表功能，解决了以上问题。首先，写入数据会自动同步到每台server上确保一致性；其次，数据落盘确保数据不丢且不会占用过多内存，结合cache机制也保证了热数据的IO性能；最后，维度表完全在云数据库ClickHouse内部管理，无需耦合其他系统，极大的简化了业务上的使用和维护代价。
• 资源队列
在分析型业务中，workload通常灵活多变，带来了稳定性上的诸多挑战。系统中既有对于响应速度要求高的简单查询，也有需要长时间run的复杂查询，如何避免高并发的复杂查询耗尽系统资源导致server OOM？又如何避免复杂查询一直占据系统资源不释放从而影响了简单查询的响应时间？
为了解决以上问题，云数据库ClickHouse开发了资源队列功能，使得用户可以指定某个资源队列的CPU、内存使用量。一来确保了特定资源队列中的查询，不会使用超过该队列限定的资源量，确保系统不会因为复杂查询并发太大而OOM；二来也确保了不同资源队列之间不会相互干扰，从而确保不同业务的相互独立。
此外，简单的资源队列硬隔离方案，会造成资源浪费，比如队列A不使用的内存也无法被队列B利用。云数据库ClickHouse在资源队列基础上，还实现了动态的资源共享与抢占。当一个队列资源空闲时，可以共享给其他队列使用；当查询下发到队列中后，会动态的将被占用资源抢占回来。
• 冷热数据分层存储
海量数据的存储成本往往是业务系统技术选型的关键考虑因素之一。在分析业务中，通常有着明显的冷热数据特征，比如经常查询最近一个月的数据且对性能要求较高，其他数据查询频率极低且可以容忍更高的响应时间。结合这个业务特点，将冷热数据分别存储于不同介质上，可以大幅度降低存储成本。
云数据库ClickHouse基于OSS，设计并实现了分层存储：热数据被存放在本地盘中，确保查询性能；冷数据按照过期时间或指定存储策略被转移到OSS上。考虑到OSS有如下系统特点，也即单次访问latency相对较高、对于metadata 的操作有QPS限制、按照object key前缀有序保存数据会引起访问热点。为了最大化分层存储的性能，云数据库ClickHouse全新设计了存储方案：将实际数据文件改名为随机文件名，并且存储到OSS bucket中；将数据文件对应的metadata仍旧保存在本地盘中，并在metadata中保存指向OSS实际文件的指针。这样对于metadata的访问延时很小且不会超出OSS QPS限制，而数据文件也因为随机文件命名而被分散到了OSS的不同分片上，从而具有最大的IO吞吐能力。
未来展望
云数据库ClickHouse未来会继续夯实弹性管控、数据链路等基础能力，同时从内核上不断增强ClickHouse现有性能优势，开发二级稠密索引、存储计算分离等核心功能，并且逐步优化分布式计算能力。云数据库ClickHouse将在产品体验和性价比上持续投入，做最快最便宜的列式数据库！
