为什么越来越多的用户不再热衷于使用ClickHouse了？

当今在大数据分析领域，真可谓百花齐放。尤其是来自俄罗斯的ClickHouse在2019、2020年火遍神州大地（有点奇怪，欧美用户好像对它不是特别感冒），一时风光无两。打开各种技术类网站、知识分享专区，铺天盖地的赞美之词，什么“彪悍”、“神器”。确实，在当时的市场中，像ClickHouse这样在单表性能上让人眼前一亮的产品确实没有，而且打开其官网，看到它与其他数据库在SSB上的性能对比，也着实有点“惨不忍睹”。

经过一段时间的研究，ClickHouse的确内功深厚，比如其在向量化执行引擎、函数丰富度、性能评估测试体系构建等方面，做的还是很优秀的，但也绝非无懈可击。闲暇之余，跟业内几家互联网大厂的大数据开发者聊天，他们普遍认为，随着公司对数据资源建设、实时数据分析需求越来越重视，之前粗放式的开发使用ClickHouse已经面临极大的挑战。总结来看，主要有以下几点：

其一，数据模型单一化，尽管速度快，但极大的损失了数据分析灵活性。大家可能都知道ClickHouse单表快、多表挫，所以尽量把数据都打成宽表来进行分析。有很多业务线的用户对此感知并不强，就像那句话：哪有什么岁月静好，不过是有人替你负重前行。而负重前行的正是那些大数据开发工程师，为了让业务用户享受到便捷的服务，他们可真是操碎了心、磨破了嘴、身板差点没累毁。这不是一个可持续的发展状态，这么下去负重只会越来越重。所以说，数据模型要多样化、具备灵活性，比如支持星型模型、雪花模型同时不损失性能，才能让数据分析既轻松又畅快。换句话说，就是宽表、多表都得快，才是真的快。

其二，实时更新支持的不好。尤其是在现在大量电商、物流、金融等需要有数据平台变更的场景下，ClickHouse的不支持真正的删除/更新的缺点就被放大了，让人挺头疼的。所以很多用户只能把ClickHouse用于离线数据分析场景。

其三，很多用户把ClickHouse作为主要数据分析引擎之一，然后搭配Presto、Druid、Kylin、Elasticsearch等等，形成OLAP全家桶，一个组件解决不了所有查询场景，那就齐心合力。可问题是，绝大多数企业没有那么大的“肚子”，吃不下啊。最后的结果是数据各自为政，数据烟囱换成了数据孤岛。

那到底有没有能解决上述问题的产品呢？身边正好有京东、小红书、携程、贝壳、顺丰、这些公司的朋友，他们都在将原有ClickHouse的业务向StarRocks做迁移，不仅如此，连Druid、Presto等组件的业务场景也都逐步进行了替换。

那StarRocks究竟有什么魅力，让这些互联网大厂做出了这样的选择呢？又是经过一段时间的了解（甚至比研究ClickHouse的时间还稍微长一些），发现了以下几个共同的特点：

其一，对SQL的兼容性比较好，业务上的查询基本不用做过多修改，就可以直接迁移过来，而且各种模型可以根据需要灵活选择，想聚合的用聚合模型、想更新的用更新模型、想保留明细的用明细模型，有点不亦乐乎。写的SQL也比ClickHouse标准，与上层的BI工具对接也简单。

其二，一个组件同时能干好几件事，能支持高并发查询（对比Druid），能支持联邦查询（对比Presto），单表查询不逊色（对比ClickHouse），多表查询更是甩其他组件好几条街（看了代码、听了老司机说，CBO做的相当出色）。

其三，在“能者多劳”的基础上，也让开发运维的成本大大降低。记得DolphinScheduler有句话说的好：调度选得好,下班回家早; 调度用得对,半夜安心睡。听完身边朋友使用StarRocks后的反馈后，感觉也有点：OLAP组件选的好，业务上线快的不得了；OLAP组件用得对，开发不用到处跪。

说了这么多，百闻不如一见，是不是好产品，用了才知道。如果大家用的多了，也都写写文章宣传宣传、参与参与StarRocks社区建设，尤其中国也是历史悠久的“战斗民族”，也有“彪悍”的一面。

最后

以上就是专注招牌为你收集整理的为什么越来越多的用户不再热衷于使用ClickHouse了？的全部内容，希望文章能够帮你解决为什么越来越多的用户不再热衷于使用ClickHouse了？所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。