致ClickHouse用户的一封信

您的数据分析工作并非一帆风顺。有几个ClickHouse目前没有解决的问题，可能正在困扰着您。

亲爱的ClickHouse用户：

您好！

感谢您在百忙之中抽出时间来阅读此信。虽然未曾谋面，但我们关注您已经有很长一段时间了。

您的企业非常重视数据分析工作，想通过数据分析来提升运营效率，发现生产经营中遇到的问题。您和您的同事每天都会查看相关的业务报表，并且愿意在报表建设上投入时间和资源。您对高效工作有极致的追求，所以您十分看重数据分析的速度。您关注大数据新技术，对新事物保持了一份可贵的好奇心。我们非常尊敬ClickHouse的工作，也非常尊敬您之前所做的工作。

但是，您的数据分析工作并非一帆风顺。有几个ClickHouse目前没有解决的问题，可能正在困扰着您。

首先，ClickHouse过度依赖大宽表。对于任何数据分析的场景，都需要您把相关数据放在一起，提前做成大宽表。先不说提前做大宽表带来的工作量，无法支持好星型模型和雪花模型，将极大限制了您分析业务数据的能力。想一想您为了构建和维护大宽表所耗费的精力，再想一想把维度表数据和海量事实表关联后产生的数据冗余，您确实为了高查询性能付出了很多额外的成本。如果您的业务还需要对某些维度列进行经常性的更新，那可能真的是一个大麻烦。对了，您还得提醒业务分析人员注意他们的SQL写法，标准SQL有时候根本跑不动。

其次，ClickHouse难以支持高并发的业务场景。您的数据分析系统只能同时提供给少数人使用。如果需要支持的业务分析人员比较多，您只能不断地搭建新的集群。当老板奇怪地问您：“为什么一个业务线需要搭建那么多ClickHouse集群？”时，想必您一定感到十分尴尬。我们理解您的难处，忍受多集群的运维管理复杂度，忍受数据多备份的空间浪费，忍受多集群的数据一致性风险，只是为了能同时让更多的人使用您的数据分析系统。

ClickHouse集群的运维复杂度也一定曾让您感到过头疼。需要依赖第三方系统来运行副本机制；需要在配置文件中维护所有服务器的信息；扩缩容时需要创建新表重新导数据；如果数据量增大，数据表数增多，Zookeeper就会形成性能的瓶颈，甚至会出现元数据不一致的问题。

最后，您一定遇到过出现线上问题，但是找不到及时和靠谱技术支持的窘境。作为支撑公司业务发展的数据分析系统，无法提供服务就意味着管理层的决策和业务人员的工作都陷入了盲目的状态，这很有可能会影响到公司的业务发展，也可能会影响您的职业发展。

ClickHouse确实是一个非常优秀的产品。但为了获得查询时的高性能，大家确实得承担一些风险、忍受一些不便。今天，我们将为您提供一个新的选择。您不用承担这些风险、忍受这些不便，也能享受到极致的查询性能！

您可能会感到不可思议，但我们确实做到了。全新一代的极速MPP分析型数据库DorisDB，能够满足您多场景的数据分析需求。它既支持大宽表的分析模式，也支持星型模型和雪花模型分析模式；各种分布式Join查询对它来说毫无压力，你不需要再为大宽表而增加额外的工作；它既支持极速的现场查询，也支持预聚合查询；它支持标准的SQL语法，兼容MySQL协议，可以直接对接各类常用的数据库管理工具和BI工具；它不存在系统单点，不依赖任何外部系统，只要一条命令就可以自动进行扩容缩容。单集群规模可以支持到千台服务器，10PB级数据量。

DorisDB的单表性能和ClickHouse不相上下，有的查询甚至比ClickHouse更加快！以下是DorisDB在SSB（Star Schema Benchmark）标准测试集上跑出来的结果。该测试环境由3台16核，64G内存的阿里云主机搭建。从结果看，单表测试的13个查询中，有9个查询DorisDB跑得比Clickhouse要快，并且平均要快50%左右。由于ClickHouse对多表分布式Join的支持有限，所以在多表测试结果中并没有ClickHouse的结果。