作者：许天云
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
一. 大纲
本篇分享下个人在实时数仓方向的一些使用经验，主要包含了ClickHouse 和 StarRocks 这两款目前比较流行的实时数仓，文章仅代表个人拙见，有问题欢迎指出，Thanks♪(･ω･)ﾉ
关于实时数仓，是目前在互联网上比较火的概念，不同于传统的 T+1 的离线数仓（Hadoop 之类），实时数仓更加追求于数据的实时分析能力，也更加符合现阶段各类分析场景对于数据及时性的诉求，例如：ClickHouse 、StarRocks 等都是这一方案的典型代表。
先简单介绍下本篇讨论的两款实时数仓产品：
ClickHouse：由 Yandex(俄罗斯最大的搜索引擎)开源的一个用于实时数据分析的基于列存储的数据库。StarRocks：新一代的国产MPP数据库，由 Apache Doris 数据库演进而来，并且进行了商业化支持。
二. 调研过程简述
2.1. 调研诉求
项目上由于 MySQL 中的数据量极速增长后，MySQL 自身无法承担一些实时的olap查询，所以需要调研一款实时数仓来解决。
我这的业务诉求比较简单，大致有以下几点：
- 实时数仓需要兼容 MySQL 协议与 SQL 语法，开发不需要额外的学习成本，可以快速上手。
日志类数据(只会追加)需要支撑亿级别实时分析，而业务类数据(不断更新)需要支撑千万级别实时分析并且对于 JOIN 性能要比较好，因为存在很多 JOIN 查询。- 整体架构要比较简单，因为很多项目硬件资源相对紧张，并且同步延迟保持在30秒内。
- 数据同步过程中并不需要清洗转换，只需要将 MySQL 中的数据镜像复制到 MPP 中即可。
基本架构如下图所示：
2.2. ClickHouse 调研
带着上述的调研诉求，我们首先调研的是 ClickHouse ，因为这是一款以单机性能强悍著称的 OLAP 数据库，而且当时在IT圈里也非常流行。
经过我们的调研测试后，发现 ClickHouse 只适合于日志类流数据的分析，而日志流数据最大的特点就是数据只会追加而不会变更删除，即所谓的append流。我们用一台单机的 ClickHouse 就可以支撑上亿的日志聚合分析，效果比较满意，部分查询场景还可以配合物化视图达到更极速的分析。
针对于另外一种业务类数据的分析场景，因为数据会不断的更新，即所谓的change流，和日志流数据不太相同，因此我们尝试了用ReplacingMergeTree引擎的自动合并去重能力，再加上查询时显示指定final关键字去达到精确查询的效果，但是性能方面不尽如人意，特别是 JOIN 场景。
对于 ClickHouse 的集群模式，因为需要引用 zookeeper 实现分布式协调，并且还需要创建分布式表，个人觉得比较复杂，而且测试下来，对于更新场景效果还是不好，其他精确查询的方式也不太便捷，因此暂时放弃使用ClickHouse实现业务数据的即时分析，更推荐ClickHous去处理日志流数据。
兼容性方面，ClickHouse 兼容 MySQL 协议，SQL 语法方面和 MySQL 类似，但是部分基本函数名称变了，而且列名大小写敏感，除这2点比较恶心外，其他基本无问题，后续我们也主要用 ClickHouse 去处理项目上的日志分析，效果还可以。
2.3. StarRocks 调研
因为 ClickHouse 无法有效的支撑业务类数据的分析场景，所以我们继续调研了 StarRocks ，主要是看重了 StarRocks 里存在非常适合实时更新场景的主键模型(Primary key)，和其比较优越的JOIN性能。
经过测试对比，StarRocks 中使用主键模型可以很好的支撑业务数据分析，因为主键模型采用了Delete+Insert 的策略，保证同一个主键下仅存在一条记录，虽然牺牲了一些写入性能，但是极大的提升了查询效率。同时 JOIN 性能也相较于 ClickHouse 提升了很多。
StarRocks 集群方面不依赖于 ZK ，通过 BE 和 FE 模块了组成了存算分离的架构模型，相比于 ClickHouse 的集群实现简单很多，因此我们可以很便捷的完成 StarRocks 集群部署及后期的水平扩展。
最后就是 StarRocks 的兼容性，相比于 ClickHouse ，StarRocks 的 MySQL 兼容性更加优秀，基本完全兼容 MySQL 协议与 SQL 语法，开发也可以无缝切换到 StarRocks 进行开发，比较省事。
后期我们主要通过部署 StarRocks 来解决项目上业务数据的实时分析，不过相较于 ClickHouse 的单机部署，StarRocks 则通常是多节点部署才能发挥更好的查询性能，因此 StarRocks 对于硬件的需求会比 ClickHouse 更加高些。
三. 实时同步
下面我们来谈下如何实现 MySQL to MPP 的实时同步。
3.1. ClickHouse同步
MySQL to ClickHouse 的同步我们使用了 GitHub 上开源的一款 CDC 产品，名字叫做Bifrost，流程图如下所示，Bifrost 通过解析 MySQL Binlog 然后拼接成 insert 语句，最后批量写入 ClickHouse 中完成实时同步。
因为 Bifrost 会自动将 CDC 数据拼接成 SQL ，攒成一批数据后批量写入 ClickHouse ，所以并不需要 Kafka 等消息队列做缓冲，因此架构上非常简单。
因为同步走的是 SQL 语句，所以 MySQL 端加列等常见 DDL 也可以同步到 ClickHouse 中，同步效率上可以支撑每秒上千条数据，延迟在10秒之内，符合我们之前的诉求。
3.2. StarRocks 同步
MySQL to StarRocks 是我们基于 Bifrost 做了一些改动后实现，还是利用 Bifrost 自身的 CDC 功能，先将增量数据写入 Kafka 中，然后在 StarRocks 端通过自身的Routine Load导入功能自主消费 kafka 数据实现同步。另外额外开发了一个 Econvert 的Go程序，用于批量生成 MySQL to StarRocks 的全量同步脚本，原理是走的 StarRocks 提供的 MySQL 外表同步数据。
相较于 ClickHouse 的同步，StarRocks 的同步稍微复杂点，因为 Bifrost 本身不支持直接同步到 StarRocks 中，所以只能先将数据放于 Kafka 中（Bifrost 支持输出到 kafka 中，但是要注意数据格式），再供 StarRocks 消费。
因为 StarRocks 中不支持识别 DDL 的 kafka 数据，所以无法实现自动同步 DDL ，针对 MySQL 中的加列操作需要手动在 StarRocks 修改，同步效率上会比走 SQL 同步的 ClickHouse 更高，延迟也基本可以保持在10秒内，符合我们之前的诉求。
四. 总结
总结一下，如果是需要分析日志流数据，更加推荐 ClickHouse ，因为 ClickHouse 单机强悍，可以支撑亿级别数据量，架构简单，相比于 StarRocks 也更加稳定，相比集群，更推荐单机 ClickHouse 。
如果是分析业务流数据，更加推荐 StarRocks ，因为 StarRocks 对于更新场景性能更加，而且 JOIN 性能更好，而且更加推荐部署 StarRocks 集群，可以充分发挥 StarRocks 的性能。
如果是混合场景，既有日志分析，也存在业务分析，那么也可以用 StarRocks 一套包掉。
