共计 2981 个字符，预计需要花费 8 分钟才能阅读完成。
作者：许天云
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
一. 纲要
本篇分享下集体在实时数仓方向的一些应用教训，次要蕴含了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 一套包掉。
