本文发表于： &{ new Date(1631721600000).toLocaleDateString() }

酷家乐是群核科技旗下知名业务品牌，专注云设计系统及三维内容制作的技术研发和应用，面向家居、房产、公装等全空间领域，为企业级客户提供设计渲染、营销展示、生产施工、几何建模等场景的解决方案和服务。酷家乐大数据技术团队负责酷家乐大数据体系框架的建设，支撑日常BI运营分析、商业化数据产品、在线大小数据业务、人群画像等场景。生产环境上使用StarRocks集群（10 x 物理机）替换了原有阿里云ADB集群和 EMR Presto集群，在使用部分集群资源前提下，查询性能即可与ADB持平，Presto P95的查询从秒级提升到500ms级别。在完成同等分析任务情况下，StarRocks性价比是同类产品的两倍以上。StarRocks一套集群统一了实时和离线的分析场景，替换了多套系统带来的系统复杂性，简化了数据ETL流程，同时大幅提升Adhoc场景查询效率。本文主要侧重于酷家乐大数据团队基于新一代极速MPP分析型数据库StarRocks，在数据服务体系和数据应用场景中的实践和探索。

数据引擎现状

随着业务规模越来越大，数据规模和体量也急剧膨胀。企业的原始数据通常来源于日志埋点文件、业务数据库、三方接口等。企业通常基于CDH/Apache Hadoop®等大数据分布式计算框架和数据集成工具，构建离线的数据仓库，并对数据进行适当的分层、建模、加工和管理。

 但上层数据应用对查询的数据存储、时效性要求高，数据最终会通过数据同步工具回流到MySQL、ElasticSearch、Presto、Apache HBase®等关系型数据库/MPP数据库中。

酷家乐大数据体系沉淀了诸多主题数据，例如：C端用户行为流量数据，B端用户账号等使用数据，行业报告相关的数据等。
 

由于数据膨胀，尤其是酷家乐设计工具使用场景下产生的模型/方案/渲染使用明细数据，离线实时计算任务需要对TB级别的数据进行调度、聚合、计算，在数仓里沉淀出大量明细表、聚合表和最终的数据报表。

数据服务层的愿景是开放数仓能力，建立统一的数据服务出口，针对不同的查数场景（数据规模、QPS、UDF支持、运维成本等），在底层引擎上的选型：

• 大数据量、低QPS：使用Apache Hive™ + Presto等基于Apache Hadoop®生态的离线批任务计算框架和MPP数据库来解决。
• 小数据量、高QPS：使用MySQL、ElasticSearch、Apache HBase®、MongoDB等关系型/非关系型TP数据库来解决。

在目前的数据架构下，我们遇到如下问题和挑战：

• 离线/实时ETL任务过多，处理逻辑大部分为简单聚合/去重，导致聚合表数量庞大，导致运营和运维上的成本增加；
• 针对中等数据量、中等QPS的查询场景，如何能兼顾数据规模的同时，有较友好的查询的耗时响应，耗时小于200ms；
• 大数据量下插入、更新的实时数据场景的支持，例如：用户画像、实时DMP、用户路径、监控数据大盘等。

新引擎的引入

针对如上的问题和挑战，我们的目标是寻求尽可能少的ROLAP引擎，利用在明细表上现场计算来解决ETL任务、数仓表过多问题，同时需要兼顾在数据规模、查询QPS、响应耗时、查询场景方面的权衡。

目前市面上ROLAP引擎百花齐放，诸如Apache Impala®、Apache Druid®、ClickHouse、StarRocks。经过一番调研，我们最终选择了StarRocks。StarRocks是基于MPP架构的分析型数据库，自带数据存储，整合了大数据框架的优势，支持主键更新、支持现代化物化视图、支持高并发和高吞吐的即席查询等诸多优点，天然能解决我们上述的问题。

应用实践

StarRocks上生产环境主要作为离线/实时数据的ROLAP数据库使用。离线数据主要存储于ODPS，通过DataX任务批量同步数据，实时数据主要存储于Kafka中，基于Kafka的流式处理任务写入。DataX任务和Apache Flink®任务统一写Doris Proxy服务，由代理控制器通过HTTP Stream Load的方式控制数据写入周期和批次大小。基于StarRocks重构原有分析平台对数仓内现有存在痛点数据业务进行梳理：

• 每日的数据增量在上亿规模的超大明细表，需要统计日、周、月、季、年等统计数据；
• 商家账号使用、模型使用、方案渲染在任意日期区间的聚合值、累计值、去重值。

这些需求在前端查询，都需要保证低延迟。在没有引入StarRocks之前，我们使用的底层引擎是MySQL或者Presto on HDFS存储存明细表/聚合表进行查询。MySQL处理上亿规模的数据，无论使用分库分表、分区表、集群化部署的PolarDB方案，都会存在慢查询、数据库扛不住、运维困难的窘境；Presto on HDFS的方案更偏向于分析型数据业务，虽然能存储海量的数据，计算能力不错，唯一致命的在于无法满足在线业务的高吞吐QPS，查询比较难做到毫秒级。引入StarRocks带来的业务效果如下：

• 支撑了在线数据查询+数据分析业务，服务于对内运营+对外商业化数据产品，在线业务查询P95耗时在毫秒级别，分析型业务查询P95耗时在秒级别；
• 支持10亿规模的明细表查询，月、季、年度统计数据现场算聚合统计、去重，查询耗时能控制在500ms；
• 千万级别的多表的join和union查询，经过Colocate Join特性优化，查询响应在秒级。

实时链路的探索

在探索实时数据链路方案时候，我们主要考虑到了StarRocks的如下优势：

• 实时写入性能：目前StarRocks支持HTTP Stream Load自定义的分钟级别微批写入和Apache Kafka® To StarRocks的秒级延迟，完全能满足T+m实时数据业务；
• 统一离线和实时分析：实时数据和离线数据更好的在StarRocks中进行融合，灵活支撑应用，数据存储策略通过StarRocks动态分区的功能进行清理；
• SQL Online Serving：高效的SQL即席查询能力，能够兼容业界流行的SQL规范，支撑业务灵活复杂的访问，提高取数开发的效率。

总结和规划

酷家乐大数据团队引入StarRocks生产集群，解决了数据服务层单表亿级别规模、高QPS数据场景下引擎的空白，直接开放明细表准实时查询的能力，给上层数据业务和BI系统提供了更多的选择和自由度，同时将大大减少数仓中大量ETL任务、聚合表、报表，降低了数仓ETL的运维压力和维护成本。未来的我们在StarRocks的应用和实践上还有不少规划：

• 除了unique和duplicate数据模型，未来会将符合的数据场景迁移至aggregation模型和物化视图表，进一步降低数仓开发维护成本，降低查询延迟；
• StarRocks on ES的功能值得我们深挖和探索，解决了原生ES集群无法支持跨索引join的能力；
• 更多数据应用层的场景接入StarRocks，例如人群更新、用户画像服务、用户行为路径分析等，将进一步拓展StarRocks在实时数据写入、批量数据更新场景中的应用；
• 和酷家乐数据集成平台、数仓平台深度打通，完善监控体，作为大数据团队的基础设施去保障稳定性和服务；
• 考虑使用多云架构，自主可控的数仓架构可以灵活的在多云间切换迁移，降低单一来云厂商的依赖，控制成本提高可用性。