酷家乐 x StarRocks (家居SaaS独角兽如何实现数据分析全面升级,大幅降低平台成本)

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

“ 作者:弋舟,
大数据技术专家,酷家乐大数据团队负责人,坐标杭州 ”
数据引擎现状
【酷家乐 x StarRocks (家居SaaS独角兽如何实现数据分析全面升级,大幅降低平台成本)】随着业务规模越来越大,数据规模和体量也急剧膨胀。企业的原始数据通常来源于日志埋点文件、业务数据库、三方接口等。企业通常基于CDH/Hadoop等大数据分布式计算框架和数据集成工具,构建离线的数据仓库,并对数据进行适当的分层、建模、加工和管理。
但上层数据应用对查询的数据存储、时效性要求高,数据最终会通过数据同步工具回流到MySQL、ElasticSearch、Presto、HBase等关系型数据库/MPP数据库中。
酷家乐 x StarRocks (家居SaaS独角兽如何实现数据分析全面升级,大幅降低平台成本)
文章图片

酷家乐大数据体系沉淀了诸多主题数据,例如:C端用户行为流量数据,B端用户账号等使用数据,行业报告相关的数据等。
由于数据膨胀,尤其是酷家乐设计工具使用场景下产生的模型/方案/渲染使用明细数据,离线实时计算任务需要对TB级别的数据进行调度、聚合、计算,在数仓里沉淀出大量明细表、聚合表和最终的数据报表。
数据服务层的愿景是开放数仓能力,建立统一的数据服务出口,针对不同的查数场景(数据规模、QPS、UDF支持、运维成本等),在底层引擎上的选型:
  • 大数据量、低QPS:使用Hive + Presto等基于Hadoop生态的离线批任务计算框架和MPP数据库来解决。
  • 小数据量、高QPS:使用MySQL、ElasticSearch、HBase、MongoDB等关系型/非关系型TP数据库来解决。
在目前的数据架构下,我们遇到如下问题和挑战:
  • 离线/实时ETL任务过多,处理逻辑大部分为简单聚合/去重,导致聚合表数量庞大,导致运营和运维上的成本增加;
  • 针对中等数据量、中等QPS的查询场景,如何能兼顾数据规模的同时,有较友好的查询的耗时响应,耗时小于200ms;
  • 大数据量下插入、更新的实时数据场景的支持,例如:用户画像、实时DMP、用户路径、监控数据大盘等。
新引擎的引入
针对如上的问题和挑战,我们的目标是寻求尽可能少的ROLAP引擎,利用在明细表上现场计算来解决ETL任务、数仓表过多问题,同时需要兼顾在数据规模、查询QPS、响应耗时、查询场景方面的权衡。
目前市面上ROLAP引擎百花齐放,诸如Impala、Druid、ClickHouse、StarRocks。经过一番调研,我们最终选择了StarRocks。StarRocks是基于MPP架构的分析型数据库,自带数据存储,整合了大数据框架的优势,支持主键更新、支持现代化物化视图、支持高并发和高吞吐的即席查询等诸多优点,天然能解决我们上述的问题。
酷家乐 x StarRocks (家居SaaS独角兽如何实现数据分析全面升级,大幅降低平台成本)
文章图片

应用实践
StarRocks上生产环境主要作为离线/实时数据的ROLAP数据库使用。离线数据主要存储于ODPS,通过DataX任务批量同步数据,实时数据主要存储于Kafka中,基于Kafka的流式处理任务写入。DataX任务和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自定义的分钟级别微批写入和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在实时数据写入、批量数据更新场景中的应用;
  • 和酷家乐数据集成平台、数仓平台深度打通,完善监控体,作为大数据团队的基础设施去保障稳定性和服务;
  • 考虑使用多云架构,自主可控的数仓架构可以灵活的在多云间切换迁移,降低单一来云厂商的依赖,控制成本提高可用性。
  • ......
最后的最后,感谢StarRocks技术团队给予的热情、靠谱的答疑解惑和技术支持!!!

    推荐阅读