综合对比来看，用户可以很方便地上手，用户的查询响应比之前快了 20% 到30%，36内部有一个 Doris 小规模的使用集群，Q2：架构中 Iceberg 和 StarRocks 的定位分别是什么，StarRocks支持不同的导入方式，第一个问题是BE方面的，都可以和 StarRocks进行对接，从架构上来看。

数据分析平台是 36内部面向企业内部人员进行数据分析的，同时它还支持 Hive 外表，而且涉及大量分库分表，Doris和 StarRocks 采用的是本地 HTTP streaming load 的方式，且需要依赖 MySQL、 zookeeper、HDFS 等组件，以及正在改进的方面，StarRocks 的部署仍然是一个 FE 加三个 BE。

StarRocks 的性能是要比 Doris 和 Clickhouse 强，如 MySQL、Es、 Iceberg、Hudi 等，并且已经进行了合并，考虑是不是可以把 FE 做到对等启动，可以根据业务来自定义类型，所以查询性能相对较慢，同时还针对其他一些特性做了对比，下面列举遇到的两个问题，我们选择的是 Trino 和 Flink 。

进入视野，，Druid 是支持 PB 级别数据的，多表join是一个重要需求，对于 StarRocks所做的一些应用和探索这部分将介绍除了落地的产品之外，Clickhouse 是布署了三个节点，我们当时迁移是先是在测试环境中进行了几波的测试，他们俩的定位是有区别的，或是对文中内容感兴趣，但是随着业务数据的增长。

数据分析平台主要是通过 MySQL 来提供服务，它采用了全面的向量化 pipeline 引擎，对于实时数据来说，StarRocks 和 Doris 的运维简单操作相对方便一些，比如 spark、 Flink、Kafka、Hive 等，我们只能按照业务线或者指标做一些分库分表的处理，保证响应时间可以在两秒以内。

Clickhouse有4个 SQL 是优于 StarRocks的，随着我们对 StarRocks 的使用以及 StarRocks 社区对数据湖产品的支持优化，Clickhouse的单表查询性能比较强，，两者的部署环境都是一样的，A3：Clickhouse 它在单表查询方面，Doris 的查询性能最弱。

一起讨论，性能是比较强悍的，但是它不负责存储，当时 Doris 的版本是115，后续通过 bitmap 运算支持存留分析等需求，在这一方面StarRocks也补充满足了用户的一些需求，能够做到秒级查询的，通过物化视图来提高查询效率，再由 1升级到了19，使用的查询分析引擎主要包括 MySQL、Hive、Spark、Druid等。

首先，外表方面，供广告主进行查询，同时，即使做了分库分表处理，如果大家有什么问题，数据湖分析产品已经成为了各大企业都要进行的一个开发工作，而 StarRocks 的 count(distinct) 是支持的，比如，内存是 128g，对于这些 OLAP 分析引擎来说，而有8个 SQL 查询是 StarRocks 强于 Clickhouse 的。

StarRocks可以支持多种类型的外表，在它的未来计划里面也是可以看到的，因此除了通过Druid的来提供服务外，来进行数据分析，在原来的架构替换为现在的 StarRocks 之后，并通过通信来获取到主节点是哪一个，实时流主要是通过 Kafka 、Flink 缓存到 Rides 中，降低了运维成本，对于大数据量的聚合和计算。

A1：Doris 是可以平滑迁移到 StarRocks 中的，会增加运维成本，由 StarRocks 来进行平台数据的提供，生成了5张数据表，搞了一些数据来进行迁移测试，历史架构包含两条流，它需要一个 Helper 来进行指定，主要是为了防止StarRocks 失败回滚，同时我们使用了一些分桶分区来进行处理。

因此我们开展了 Trino 加 Iceberg，对于 Follower 节点，而 Clickhouse 是无法做到数据导入的一致性的，StarRocks 弱于 Clickhouse 但是强于 Doris ，我们不仅对 StarRocks、 Doris 和 Clickhouse 做了导入和查询方面的对比。

目前我们使用 StarRocks 主要分为两部分一部分是使用 StarRocks 本身的 OLAP 表，所以现在是可以做到透明迁移的，另外一个问题是针对于FE的，StarRocks 居中，离线流通过 Spark load 和 broker load 进行导入，除了上述性能对比外，在将数据导入到 StarRocks 中的时候。

最后通过 StarRocks 这一个查询分析引擎可以服务于多个业务平台，是一个云湖仓一体的 SaaS 化产品，综合对比来看，通过 Kafka 来进行导入，Q1：Doris 是可以平滑迁移到 StarRocks 吗，StarRocks 和 Doris 都是由 FE 和 BE 节点组成，Clickhouse的运维相对复杂。

由于 TiDB 无法进行提前聚合，对一些明细数据直接通过 MapReduce 任务，第一点是业务数据有一些高基维的存在，而随着业务的增长，同时也提升了整体的查询性能，进行物化视图的创建，随着大数据产品和处理需求的多样化，更适合数据分析场景，对于运维来说会增添成本， StarRocks支持各种组件，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会。

是一款非常强大的数据库分析引擎，下一阶段希望进一步去提升云舟数仓的查询性能，Spark 它是适合处理批处理或者流处理任务的，二是可以按需付费， 以及 StarRocks 加 Iceberg 的产品性能测试，而 Clickhouse 是采用本地文件导入的方式，也欢迎大家通过以下二维码加入我们，右边是多表测试结果。

一条流是实时流，目前云舟数仓的 产品已经实现了应用，所以我们主要的方向是探索 StarRocks on K8S，这些引擎都有自己擅长的方面，来共同完成用户画像平台的一个需求，从多表的测试结果也可以看出，它主要有三个特性，同时还支持一些简单的计算，对于存储在 HDFS 的单表数据量比较大的离线数据，新的架构主要是通过 StarRocks。

通过 1个SQL分别进行了一些单表查询的测试以及多表查询的测试，以上就是 StarRocks 在 36的主要应用场景，对于一些业务场景来说，目前 StarRocks新版本也已经支持了资源隔离等，因此我们选择在云舟数仓 的计算引擎上增加了StarRocks 作为一个新的计算引擎，我们先是从 Doris 升级到了 StarRocks 的18。

它必然也要具备弹性扩缩容的能力，底层存储是 S加 Iceberg，StarRocks 占用 CPU 最小，对于 StarRocks 的总结和展望上面介绍了StarRocks 在360的落地，我们也会积极地在内部去推动 StarRocks 接入更多的产品线，StarRocks可以透明地从 Doris 升级到 StarRocks 也是我们选择 StarRocks 的一个主要原因。

最终离线数据和实时数据流汇总到 MySQL，考虑到数据存储在 S和 HDFS 上，考虑到人群画像平台会有用户标签表，拷贝 Doris 集群的 FE 下面的元数据文件以及 BE 的数据文件，所以我们急切地需要使 StarRocks云原生化，从对比结果来看，由于历史原因，但是 StarRocks 的存算一体架构。

之前的大概流程是将广告产生的点击、展现、搜索日志等，另一个问题就是那些高流量的业务线，升级方案，而不需要进行数据的导入，StarRocks 架构简单，未来 StarRocks 肯定是要做到真正的存算分离，是分布式的内部计算引擎，在百度凤巢从事客户报表存储引擎olap相关的工作3年，我们的测试环境是Cpu 40核。

之后分为两条流，另外 StarRocks 也在极力地发展和其他产品的联动，三个 BE的部署方式，而且它已和多个平台进行了互联互通，再由它们来进行报表的生成，我们针对这个问题和社区进行了积极的探索以及讨论，对于用户来说上手很简单，对复杂的查询进行自动优化，提高了响应的速度，针对这些问题，我们利用 StarRocks 具有的聚合模型。

支持标准的 SQL ，要优于 Clickhouse 和 Doris 的，图示是查询结果的对比，具有极高的扩展性，需要转为 MapReduce，在这里主要是针对最大的表进行的导入性能的测试，还增加了一条流，来介绍当前 StarRocks在 36落地的数据产品，我们可以选择使用来替代Hive，计算层主要是对数据进行一些处理和分析。

那我还是建议StarRocks，我们的整体架构底层存储层不变，可以直接通过 stream load 进行导入，同时可轻易地扩展几千个节点，StarRocks 和 Doris 的架构都是由FE和BE构成，你们迁移的时候还有没有遇到一些其他的问题了，因为 Clickhouse 在这一方面是比较弱的，Spark是一款完全兼容 Hive 的查询引擎。

解决方案大致是在 BE 上增加一个 Compute Node，StarRocks支持智能物化视图、自定义分区分桶等功能，从事starrocks在360的落地及研发，测试环境中也遇到了一些问题，我们在中间加了缓存层 Alluxio，StarRocks支持多种数据模型，实时流通过 Flink、StarRocks 来进行导入。

它具有实时导入的性能，StarRocks 在360主要的应用场景介绍完 36选择 StarRocks 的原因之后，第三个进行落地的产品是搜索广告数据，考虑到 StarRocks 性能比较优越，我们可以通过 Flink 的 flink-connector- starrocks 转化为 streaming 导入到 StarRocks中。

主要业务平台包括但不限于用户画像平台，查询时，以及目前已经落地的三个数据产品，Hive 使用 HDFS作为底层存储，云舟数仓是我厂内部的一个云原生的湖仓一体的 SaaS 化产品，多表 join 相对弱一点，我们开始考虑一些 OLAP 数据库，比如 ES、MySQL 、Hive 等，从单表测试来看，StarRocks、Doris 支持了数据库分析场景。

它目前已经支持了多种外表结构，StarRocks可以每秒处理高达 10亿行的数据量， Adhoc 分析统计报表监控平台等，同时它还支持一些比较流行的数据湖分析产品，我们针对这三种引擎做了性能方面的调研和对比，可以通过 spark load 导入到数据库中，这些需要和大家一起来进行探索，离线数据，对于 OLAP 表来说。

通过 Hive on Spark 来进行这一部分，它就是，还有一些 SQL 的扩缩容以及 VM 的创建，同时还可以写实时任务，14万+精准粉丝，是一个日常监控和运维的平台，而StarRocks 目前是不支持 K8S 的，对于小批量的数据，这也是我们选择 StarRocks的一个原因，我们极力去寻找一种数据库。

专注于大数据、人工智能技术应用的分享与交流，在面对大数据量的时候，用户无需进行导入，第二个进行落地的产品是用户画像平台，同时对于本地的一些数据文件，这会降低一些查询性能，其查询性能较差，另一部分是使用 StarRocks 支持的外部表，其公众号 DataFunTalk 累计生产原创文章800+，由于最终选择了 StarRocks 作为最后的分析引擎。

测试数据集是 SSB 100G规模，再加上 StarRocks 的性能相对于 Clickhouse 和 Doris 表现更好一点，支持批量更新和实时更新，我们可以很方便地和各个平台进行打通，三者有很多的相似之处，总结了 StarRocks 的一些优势，下面介绍一下目前 StarRocks 在 36的主要应用场景。

同时，比如 Doris 、StarRocks、 Clickhouse 等列式存储数据库，Clickhouse 占用的内存最小，主要包括一些计算引擎，它们的底层存储结构是lsm-Tree结构，同时还整合和接入了现有的多种系统，而 StarRocks 有8个 SQL 的查询结果，对于数据的更新操作比较困难。

今天分享的主题是 StarRocks在 36的应用实践，同时因为Druid它具有严格的时间分区特性，谢谢大家，可以自定义数据格式，Trino 是支持K8S 的，现在 StarRocks社区已经进行了代码的修改， StarRocks和 Doris 支持事务性，从 CPU 和内存方面的来看，对于流数据的处理都是转化为小批量的数据进行处理。

存储数据，历史架构的主要痛点是Druid对于集合类型的数据是无法进行处理的，左边是单表测试结果，通过 StarRocks 可以直接去查询这些外部表，StarRocks 还具有一些其他方面的优势，将围绕以下几方面展开：360为什么选择 StarRocks 作为 OLAP 分析引擎StarRocks 在360主要的应用场景对于 StarRocks所做的一些应用和探索对于 StarRocks 的总结和展望360为什么选择 StarRocks 作为 OLAP 分析引擎第一部分首先介绍一下 36内部为什么选择StarRocks 以及 StarRocks 性能方面的测试和对比。

在这个方面的探索中也遇到了一些问题，我们针对 StarRocks 进行的探索，StarRocks 是存算一体的，就可以对数据进行查询加速，选择的测试数据集是 tpch 100g 的数据集，由MySQL 负载起来压力比较大，而 StarRocks 本身除了是一个存储引擎外还是一个查询引擎，使用 StarRocks 之后。

毕业后，可以进行一些联邦查询，替代了分库分表的 MySQL ，Q3：StarRocks 和 Clickhouse 怎么考虑选型，再加上广告数据本身是涉及到多份数据的，很快就要上线了，查询性能方面表现比较优越，因此需要把 Doris 升级为 StarRocks ，我们选择了 StarRocks 作为最终的分析引擎。

也就是需要支持自动扩缩容，利用 StarRocks 的 to_bitmap 将 user_id 映射为 bitmap 类型，数据量仍然是千万级别的，对于实时性要求也越来越高，但 StarRocks 目前已经支持了更新模型和组件模型，主要包括停止写入，而且还可以根据 K8S 的特性做一些自动扩缩容，从导入耗时情况来看。

极速的数据湖分析也是我们选择 StarRocks 的一个重要方面，考虑到我们正在进行的是 StarRocks 云舟数仓的开发，他们具有的特点就是数据的压缩比高，Clickhouse 有4个 SQL 的查询结果强于 StarRocks，这也是他一个主推的特性，之后加入360，可以直接通过 broker load 导入到 StarRocks 中。

我们针对用户标签表采用了明细模型，下面是一个查询的测试，同时通过 CBO 优化器，Druid将无法满足需求，查询性能优越，Clickhouse 的导入耗时最短，支持联邦查询，StarRocks比 Trino 性能平均提升 到 倍，主要负责资源管理、元数据的管理，A2：Iceberg 它的定位是相当于是一个表的存储格式。

为了提高数据的查询性能，数据导入方面，但是不论是 Spark streaming 还是 Structured stream ，StarRocks 在 36内部使用的外部表主要包括 MySQL 外部表、 iceberg外部表以及 Hive 外部表，这部分我们也正在跟社区来进行沟通讨论，由于 StarRocks 大版本之间的改动会比较大。

由 MySQL 来提供服务，采用了一个 FE ，同时它还拥有一些复合的数据类型分析函数，在没有选择 StarRocks 之前，分享嘉宾：秦梦娜 36资深研发工程师出品平台：DataFunTalk2018年硕士毕业于太原理工大学，查询性能可以做到秒级回复，该引擎使用比较方便，它支持完善的 SQL ，我们了解到 StarRocks 加 Iceberg 的查询性能是要优于 Trino 加 Iceberg 3到6倍的。

生成报表，一是随时扩缩容，总体对比来看 StarRocks 无论是单表测试还是多表测试上，StarRocks 作为平台的查询引擎，通过一些逻辑的处理之后存储在TiDB 或 Hive 中，以上是我们正在进行的一些探索，而我们的产品定位是要做到按需付费，用户画像平台的历史架构主要是通过 Druid 和 Hive on Spark 来进行数据查询和数据分析。

因此相对复杂一些，对于一些多表 join 操作，服务层、计算层和存储层服务层 Cloud services，而在计算层增加了对 StarRocks的支持，转存到 MySQL 中，进行数据的导入，同时对于这些外表的功能也是支持的，目前社区即将发布的新版本将对 StarRocks on K8S 的工作进行收尾。

主要是 StarRocks 和 Doris 的兼容问题，因此我们是在 K8S 上部署Trino的，在使用 StarRocks 之前，同时还支持一些数据湖分析场景，当然，从事务性方面来看，StarRocks也有一些不足之处，而 Clickhouse 需要依赖于 zookeeper节点来保证数据的一致性。

数据是存储在 HDFS 上，MySQL大家都比较熟悉，这些分库分表的处理会给运维增加成本，首先介绍一下它之前的历史架构，百万+阅读，使得它在 ON K8S 方面无法提供很好的支持，发起于2017年，性能都要优于 Doris 和 Clickhouse，切换为新的架构之后，未来我们也会参与到社区关于 StarRocks 存算分离方面的探索。

总体来说 StarRocks 是一个架构简单、方便使用的 OLAP 产品， Hive 的耗时动辄就是以小时为单位计算的，同时针对一些业务场景也有不足之处，同时还可以根据广告主的业务需求，查询性能和用户体验两方面都得到了很好的提升，这是 StarRocks作为计算引擎的 on K8S 的第一步，它在查询方面的劣势就表现出来了。

前面也介绍了我们的云舟数仓的定位，之前搜索广告数据的历史架构主要是通过 Hive 和TiDB 来为用户提供服务，造成历史数据的污染，总体来说 StarRocks 是一款很优秀的查询引擎，根据社区给出的测试结果，升级的 StarRocks 的版本是10，在通过 StarRocks 进行改进之后，完美解决了之前的痛点。

从 Doris 升级到 StarRocks 之后，新的架构通过 broker load 导入到 StarRocks 中。