阿里云数据库 ClickHouse 云原生版产品解析

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
简介: 本文简要概述了开源 ClickHouse 应用行业场景及性能优势,以及业界对于ClickHouse的关注度趋势和使用情况。 详细说明阿里云数据库ClickHouse 云原生版架构和功能特性,分析自建ClickHouse 用户使用过程中遇到的问题,以及如何通过云原生版本解决自建的部分难点问题。最后介绍云原生版本试用申请流程。


点击 申请云原生版试用资格

ClickHouse 介绍

ClickHouse 是一款当前非常流行的开源在线分析型数据库。ClickHouse 主要应用于实时数仓构建、大数据加速分析、宽表日志分析等通用场景,服务于流量漏斗分析,用户行为分析,人群圈选,用户画像,广告投放人群评估、ABTest 、大促分析,CDP/DMP 等业务场景,在电商平台,新零售、游戏、广告、社交应用,在线旅游,本地生活,交通物流等行业都有广泛典型的应用案例,国内大厂阿里,字节,腾讯,快手,携程,京东,小红书等都有大规模的业务使用。

ClickHouse 开源关注度增长非常迅速,在 DBEngine 网站公布的2021年RDBMS 产品类目产品关注度排行榜上,ClickHouse 年度关注度排名提升30名,整体排名28位。 以下是当前在线分析数据库/实时数仓领域的几款高热度产品的流行关注度趋势,ClickHouse 和 Greenplum 为开源产品,其他几款为闭源商业产品。


1.png

ClickHouse 之所以得到这么高的关注度,个人认为两个核心的因素决定:

  • 一是市场驱动。当前企业客户整体业务数量规模增大,而业务实时分析决策的需求明显,触发了对在线分析型数据库/实时数仓的需求增强;
  • 二是产品选型,流量和用户的竞争激烈的大环境下,促使业务行为和决策更有时效性,从而提高留存率和转化,因此对数据分析引擎的性能响应要求越来越高。同时业务分析维度增多,分析数据来源多,分析数据规模膨胀,对成本控制的需求也非常明显。ClickHouse 基于列式存储,向量化执行引擎和SIMD(单指令多数据流),稀疏索引,分布式计算,多核并行等核心技术以及优秀的工程实现,实现了高压缩比数据存储,高效的数据写入吞吐和亿级记录95%查询秒级返回的优异性能。

社区官网公布的性能测试结果显示。ClickHouse 相比 MySQL 在分析性能上有500倍以上的提升,相较于 Greenplum 等分析引擎在聚合分析场景也有 20倍以上的性能提升。(PS:想了解更多 ClickHouse 的原理和架构以及开发实践,可以看往期我们在阿里云开发者社区陆续发布的ClickHouse 内核解析系列文章。ClickHouse 内核解析和开发实践文档系列。)

自建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节点。水平扩展会遇到两个问题:

  1. 如果遇到某个shard 节点的磁盘打满或者计算资源不足的时候,需要通过增加计算节点,分担数据存储和计算负载。基于开源版本架构设计,需要单独进行计算扩容或者存储扩容时,因为存储和计算的耦合,那么必须计算资源和磁盘存储一起扩容,而这样就会造成一定程度资源浪费,资源利用率降低。
  2. 另外一个问题是,进行水平扩容后,由于增加了shard 节点,为了保持资源查询负载的均衡,那么需要将原有的shard节点的数据按在扩容后在所有的shard 节点上进行 Rebalance 。 Rebalance的过程需要进行历史数据进行迁移和重新写入,数据量大的情况下迁移周期长,影响正常业务数据写入,业务侵入性太高。

以上三方面的问题会导致不具备大规模运维系统构建和内核修复能力的企业来说,使用自建 ClickHouse的ROI 将会非常低。


云数据库ClickHouse 社区兼容版架构图



1646290592903-fc74589b-97bb-48ae-9f59-f033439d3550.png

阿里云数据库ClickHouse 云原生版本

阿里云数据库 ClickHouse 云原生版是在开源内核版本基础上,基于云的基础设施进行架构和能力升级。集成云企业级运维能力,增强易用性,降低运维成本;并进行资源解耦,提供更细粒度的资源使用控制,并提高资源的利用率和弹性效率,实现实时企业分析场景的降本增效,提高决策效率和业务收益。

云原生版运维能力

云原生版提供全面运维能力,满足企业客户 ClickHouse 运维需求,部分能力如下:

  • PAAS级服务,免部署轻运维,开箱即用。
  • 企业级数据链路对接。包含离线的 OSS,ODPS ,HDFS ,HIVE ,MaxCompute 以及实时的MySQL,Kafka ,Flink 数据源对接。生产级MaterializedMySQL ,增强支持表级实时数据同步,增强容错处理和数据一致性保证。支持 DataWorks ,Spark ,SeaTunnel ,DataX 等企业级和开源数据集成和调度平台。
  • 数据安全性全面提升,支持存储加密,HTTS/SSL 存储加密,数据备份恢复。
  • 监控告警体系支持,提供资源层和数据库引擎层的监控告警和慢SQL的监控处理
  • 企业级资源管理能力,支持实时升降配和扩容,支持Terraform 等。
  • 内核稳定性支持,bug 发现后及时修复,保证稳定性。
  • 专家服务支持,给予稳定性保障和最佳实践的支持

云原生版优势特性

云原生版本进一步实现资源解耦,实现存储计算资源解耦,提高性价比和弹性效率。具体特性如下

  • 【存算分离】云原生版本采用存储计算解耦架构,可以根据生产需求独立进行计算或者存储计算的扩缩容,资源管控粒度更细,整体成本更加可控。1646290640958-00b2caf7-c347-45e3-bc65-b3ebddd368e8.png
  • 【缓存加速+共享存储】
  • 计算层加入ESSD缓存层,缓存层加速写入和查询,根据业务负载需求可弹性扩展缓存层,保证实时查询效率。
  • 持久化数据存储使用更低成本的存储介质,按照30%的缓存和持久化存储配比,整体缓存+持久化存储成本下降60%。
  • 【存储使用】持久化存储使用低成本存储介质,按小时统计实际使用量,无需容量规划,存储资源使用率达到100%,更具性价比。
  • 【计算资源池化】云原生版本计算资源采用计算组资源服务化模式,直接根据需求选择计算组规格,无需关心计算组内部节点规格和节点数量,依据业务需要进行资源扩缩容,更简单。
  • 【高效弹性】云原生版本采用 ShareDisk 模式,计算资源扩容无持久化数据迁移过程,扩容稳定性提升,扩容效率提升10倍以上。

f64b259454c94e2498d158e46fb2585e.png



云原生版的实例购买和使用方式

  • 第一步:选择计算资源,含内存和CPU资源。云原生版对计算资源进行的封装,用户无需选择节点规格和节点数量,只需选择整体依赖的计算资源即可。
  • 第二步:选择缓存资源。缓存加速写入和查询,根据写入量和查询性能表现选择,实例创建后可以根据性能调节缓存大小。
  • 第三步:进行数据写入和访问。存储资源无需提前购买,按需使用,根据实际数据写入量动态计量。

云原生版实例购买模式示例

1646809581714-d0b95e90-11e4-498a-90bd-5c5a23f04884.png

云原生版本的几个疑问

在云原生推出的过程中,收集到几个客户关心的问题,分享给大家。

问题1 :云原生版本缓存和社区兼容版冷热分层的热数据层有什么区别?

答: 云原生版本和社区兼容版冷热数据分层都有数据分层逻辑。区别在于云原生版本的持久化层数据为全量数据, 缓存为部分数据,按照实际查询结果自动选择缓存数据。而冷热分层及多盘是预设存储分层,根据用户根据业务规则预先将数据划分为冷数据和热数据,冷热数据都是非全量数据,业务定义为冷数据的存储在冷数据层,不会根据查询热度自动转变为热数据,冷热数据转换需要修改数据定义规则或者手工搬运分区数据。

问题2:ClickHouse 使用大数据量的低成本的存储 ,能做到实时分析吗?

答:云原生版本增加了缓存层,使用ESSD盘作缓存。 数据写入过程先写入到缓存层,保证写入效率,而后写入到全量的数据持久层存储。查询依赖数据也会缓存到缓存层,提高查询速度。缓存层根据特定的算法进行数据有效性控制和淘汰的机制。缓存层资源可以基于资源使用率监控和查询效率进行手动的扩缩容操作,整体保证查询效率。


云原生版本未来的演进计划

阿里云数据库ClickHouse 云原生的版本后续的产品将朝着提高资源利用率,提高性能,智能运维三个指标方向进行迭代。

一是全面 Serverless ,实现无需进行计算资源的预设 ,根据负载实时进行动态资源的调整,充分提高资源利用率。

二是进一步资源解耦,精细化资源使用粒度,资源配比的动态调整,实现不同业务场景对不同计算资源维度的差异化需求。

三是自动化智能运维,逐步从人工定位问题到自动巡检,人工优化到自动报告建议,部分实现智自动诊断和自优化,提高智能诊断优化的问题拦截率和满意度。


邀测申请方式

阿里云数据库ClickHouse 云原生已经发布上线,并开启试用申请,欢迎您申请体验。

  1. 点击 或扫描二维码填写公测表单

1646814422886-f9680f33-5bb6-4787-9312-2c561595ade9.png

  1. 等待测试资格审核;
  2. 收到测试资格审核通过通知后,发放测试代金券,
  3. 创建实例并测试 试用支持区域:华北2(北京),华东2(上海),华东1(杭州),华南1(深圳)。
目录
相关文章
|
14天前
|
存储 人工智能 数据管理
|
3天前
|
运维 关系型数据库 MySQL
体验领礼啦!体验自建数据库迁移到阿里云数据库RDS,领取桌面置物架!
「技术解决方案【Cloud Up 挑战赛】」上线!本方案介绍如何将自建数据库平滑迁移至云数据库RDS,解决业务增长带来的运维难题。通过使用RDS MySQL,您可获得稳定、可靠和安全的企业级数据库服务,专注于核心业务发展。完成任务即可领取桌面置物架,每个工作日限量50个,先到先得。
|
7天前
|
存储 人工智能 数据管理
媒体声音|专访阿里云数据库周文超博士:AI就绪的智能数据平台设计思路
在生成式AI的浪潮中,数据的重要性日益凸显。大模型在实际业务场景的落地过程中,必须有海量数据的支撑:经过训练、推理和分析等一系列复杂的数据处理过程,才能最终产生业务价值。事实上,大模型本身就是数据处理后的产物,以数据驱动的决策与创新需要通过更智能的平台解决数据多模处理、实时分析等问题,这正是以阿里云为代表的企业推动 “Data+AI”融合战略的核心动因。
|
SQL Cloud Native 关系型数据库
ADBPG(AnalyticDB for PostgreSQL)是阿里云提供的一种云原生的大数据分析型数据库
ADBPG(AnalyticDB for PostgreSQL)是阿里云提供的一种云原生的大数据分析型数据库
1326 1
|
数据可视化 关系型数据库 MySQL
将 PostgreSQL 迁移到 MySQL 数据库
将 PostgreSQL 迁移到 MySQL 数据库
1797 2
|
SQL 关系型数据库 Linux
【PostgreSQL】基于CentOS系统安装PostgreSQL数据库
【PostgreSQL】基于CentOS系统安装PostgreSQL数据库
1043 0
|
SQL 存储 自然语言处理
玩转阿里云RDS PostgreSQL数据库通过pg_jieba插件进行分词
在当今社交媒体的时代,人们通过各种平台分享自己的生活、观点和情感。然而,对于平台管理员和品牌经营者来说,了解用户的情感和意见变得至关重要。为了帮助他们更好地了解用户的情感倾向,我们可以使用PostgreSQL中的pg_jieba插件对这些发帖进行分词和情感分析,来构建一个社交媒体情感分析系统,系统将根据用户的发帖内容,自动判断其情感倾向是积极、消极还是中性,并将结果存储在数据库中。
玩转阿里云RDS PostgreSQL数据库通过pg_jieba插件进行分词
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
876 4
下一篇
开通oss服务