云ClickHouse 如何支持客户降本增效？

摘要

当降本增效成为企业运营和技术投入的核心诉求时，能否有效帮助企业客户实现资源降本同时提高业务收益成为产品能否获得市场和客户认可的重要衡量指标。阿里云 ClickHouse 从提高企业实时分析业务收益和降低数仓资源成本投入角度思考，通过大存储规格及云原生等产品形态，帮助客户降本增效。

降本增效成为主流需求

截至今年6月份，我国网民规模达10.51亿，互联网普及率 74.4%， 企业客户都面临增长停滞缓慢和成本高企的困境，因此企业应通过进一步挖掘现有的用户价值、提高技术含量、降低营销和经营成本，提升企业效益和持续增长能力， 一言以蔽之就是需要降本增效 ,从过去一年经营相关产品的统计口径来看，大约 70%以上存量客户都表现出突出的降本增效诉求。而在接下来的新一年，个人判断“降本增效“ ”仍将持续成为企业在新一年的主流诉求。

 实时数仓降本增效逻辑

实时数仓是支撑企业数字化运营支撑的核心产品，通过发挥自身“大数据实时分析能力”来支撑业务精细化运营。当前实时数仓的降本增效逻辑从以下两个方面来考虑：

• 一方面从数据分析效率思考，数据分析效率决定了运营决策，策略制定及效果评估的效率。运营决策和执行的时效性越高，就越能在运营过程更快的匹配到目标客户，更实时的将运营策略应用到目标客户，从而达到更好的转化率，留存率等业务转化效果，达到业务“增效”的预期。因此实时数仓产品的分析性能是衡量一个数仓产品成功与否最重要参考指标之一， 分析性能和业务“增效”效果在很大程度上是正比例关系。
• 另外一方面是从资源使用成本考虑。 实时数仓通常需要对大规模业务数据实时处理，因此就需要消耗大量的存储介质来存储数据，同时也要消耗对应的计算资源参与实时计算。所以如果能总体实现存储和计算成本资源的最小化就能起到帮助客户“降本”的效果。

阿里云 ClickHouse 如何落地降本增效

ClickHouse  是一款开源的 OLAP 场景的列式数据库技术，从全球最大的俄语搜索引擎公司 Yandex 内部孵化而来，在 Yandex 内部支撑了核心商业化广告投放相关业务的数据分析场景。 20 万亿行的数据规模下，90%的查询分析能够在 2 秒内返回。

阿里云 ClickHouse 是阿里云基于开源技术提供的全托管实时分析型列式数据库服务。具有高性能、开箱即用、企业特性支持。广泛应用于流量分析、广告营销分析、行为分析、人群划分、客户画像、敏捷BI、数据集市、网络监控、分布式服务和链路监控等业务场景。 阿里云 ClickHouse 作为实时分析型数据库/实时数仓服务，基于实时数仓的降本增效逻辑，进行了一系列的产品改进和优化，来帮助客户实现低成本上云，达到降本增效效果。

阿里云承袭开源 ClickHouse  优异性能

数仓的分析性能决定了构建在其上业务系统的实时性，进而直接影响到用户业务“增效”结果。而 ClickHouse  凭借其“暴力”的查询性能获得了广大开发者和企业用户的青睐。DB-Engine 的流行度排名上，产品的关注度快速增长，在同类产品的流行排名上也处于领先位置。

ClickBench 是当前业界通用的针对分析型数据库性能对比提供的基准性能测试方法之一，此基准测试展现了点击流和流量分析、web分析、机器生成的数据、结构化日志和事件数据场景下典型工作负载:，并且涵盖了 ad-hoc 及实时仪表场景下的典型查询。测试数据集来自世界上最大的网络分析平台之一的实际流量记录，数据本身已进行脱敏，同时保留所有重要的数据分布，且查询集是临时设置的，能够反映实际的工作负载。

在 ClickBench 基准性能测试场景中，ClickHouse 长期处于基准测试排行榜的头部。详情点击 ClickBench 测试报告

阿里云 ClickHouse 大存储规格持续降本

大规模业务场景下，数仓的数据存储成本是企业用户在数仓资源投入的最大成本组成部分。在典型的大规模点击事件流类及用户行为日志数据分析或离线大数据在线加速分析场景，需要分析的数据规模从几十上百 TB 到 PB 级，存储资源成本的比例可达 ~70%以上 。大幅降低存储成本，就可以最大化的帮助用户实现资源降本。

阿里云 ClickHouse 大存储规格最大化实现资源降本。大存储规格基于阿里云特定的机型进行部署，整体成本可以降低 80%左右。 

大存储规格使用本地磁盘替代云盘进行存储，本地盘没有云盘的副本冗余，因此成本可以大幅缩减。同时，大存储规格计算和存储在同一台物理机上，数据传输没有网络延迟，因此整体 IO 吞吐能力也有明显的提升。通过大存储规格可以最大化的降低存储资源成本，提供最具性价比的规格类型，满足用户“降本”的诉求。

当然，大存储规格虽然提供了非常大的成本优势 ，但也不是适用于所有的业务使用场景。大存储规格在弹性和可靠性等方面有一定的取舍，需要根据自己的业务场景来选择，可以参考以下三个维度来考虑选型。

• 弹性维度。大存储规格的存储和计算资源的配比是固定的，没有单节点的灵活的“弹性”能力。单台 Server 节点如果有超出配额的计算资源需求，或者更多存储资源需求时，无法通过调整单台的存算资源配比来满足，只能通过水平扩容的方式，增加服务节点来满足需求，同时也会带来新节点额外的耦合资源浪费。所以本地盘规格更加适合“资源规划型”业务，能够提前做好存储计算的比例测算和分配，没有非常强的资源弹性需求的业务场景。
• 基础数据规模。大存储规格的初始存储资源规格较大，面向初始业务数据就具有大数据量存储，达到 50TB 以上的数据规模需求。 如果数据分析规模在 10TB 以内，且长期看数据增长和数据淘汰的比例相当，那么建议选择标准规格类型，避免成额外的存储资源浪费，降低初期的业务成本。如果初始的数据规模就比较大，就更加适合大存储规格。
• 数据可靠性。大存储规格的存储介质选用本地盘， 本地盘来自单台物理机，数据可靠性取决于物理机的可靠性，存在单点故障风险，因此数据可靠性会显著降低。如果业务对数据可靠性要求高，那么需要考虑默认使用标准规格云盘版本，或者使用云 ClickHouse 引擎层的双副本版本。

 阿里云 ClickHouse 云原生版降本增效

阿里云 ClickHouse 大存储规格解决了资源规划型业务场景资源降本的诉求。 那么对于业务资源有实时弹性诉求的场景，通过云原生版本支持客户降本增效。

对于实时弹性有强诉求的业务主要主要表现在几个层面。

•  第一，业务对于资源的需求不可预期，资源变配的需求频率高。这种业务场景下，初始规划的资源配置，通常随着业务的发展，会出现资源浪费或者资源短缺，需要通过变更资源配置来调整资源使用量。并且在业务高峰突然到来时，需要能够快速的进行资源的扩容，因此对资源扩容的效率要求会更高。
•  第二，业务对于存储资源和计算资源需求比例不固定，每一层资源的需求都更加灵活。客户业务在同等数据规模下，业务对于时效性响应的要求不同，对于并发性支撑能力要求不同，对于计算资源的需求量就不同。比如大促活动期间，业务决策效率要求更高，就需要更多的计算资源来支持实时分析。并且在相同的计算资源需求下，如果业务的数据规模增长更快，对于存储资源的需求更高时，就需要实时的扩充存储资源，满足存储需求。

 阿里云 ClickHouse 云原生版本通过以下几个产品能力来解决强实时弹性的业务诉求。

• 存算分离。开源社区版本的 ClickHouse 是存算一体化的架构，每一个 Server 主机既要负责数据存储也要负责数据计算，当单节点的存储或计算资源达到单机的上限时，就需要进行水平扩容。而计算和存储耦合的水平扩容方式，面对单一的存储或计算资源扩容需求时，就会带来额外计算或存储资源的“扩容浪费”。云原生版本通过 share storage 架构，支持产品层面将计算资源和存储资源解耦，实现存算分离。用户可以按照需求购买计算资源，按需按量使用存储资源。存储和计算之间没有固定的配比，业务可以根据需求灵活的选择资源配置，最大化资源利用率，降低资源耦合浪费，实现“降本”。
• 实时弹性。开源社区版本 ClickHouse  采用 share nothing 的架构， 存算耦合模式。每个 ClickHouse Server 或者 Shard 节点负责本身节点存储数据和分析。水平扩容时需要对原有节点的数据进行 reshard/rebalance ,保证扩容前后集群各个节点的负载均衡，而 rebalance 需要进行大量的数据迁移，且扩容效率随着数据规模的增长而衰减。在百 TB 数据规模下，全量扩容迁移需要天级别来完成，对业务的可用性造成严重的影响。阿里云 ClickHouse 云原生版本，通过存算分离的架构和独立的 Meta 层管理，将 shard 计算和 shard  数据存储的映射关系进行独立管理。计算水平扩容时，仅仅需要在独立 Meta 层进行映射关系数据的的修改，存储层 shard 数量和存储内容不变，不需要数据迁移或者少量计算层缓存数据迁移，就可以完成计算的扩容。整体扩容效率从小时/天级别缩短到秒/分钟级别。帮助客户实现“增效”的目的，满足业务高频实时弹性的需求。

总结

分析业务的分析时效性决定了业务效果，而分析引擎的分析性能决定了对分析业务时效性的支撑。阿里云 ClickHouse 基于开源社区内核提供了的高效实时分析能力，满足了客户“提效”的诉求。同时，通过大存储规格，从数仓使用成本层面，大大降低了成本投入，满足了资源规划型业务“数仓降本”的普遍诉求。而对于实时弹性具有强依赖的场景，通过云原生存算分离版本提高了扩容效率和资源使用率，同样可以帮助达到了“降本增效”的目的。

未来，阿里云 ClickHouse 会进一步加强在云原生 Serverless 层面产品演进，支持多计算组共享存储架构，实现业务隔离，读写分离及用户隔离；支持自动进行计算层的负载判断，实现 AutoScaling ，进一步帮助客户降本增效。