StarRocks在360的应用实践——StarRocks 在360主要的应用场景

目前我们使用 StarRocks 主要分为两部分一部分是使用 StarRocks 本身的 OLAP 表,另一部分是使用 StarRocks 支持的外部表。对于 OLAP 表来说,StarRocks支持不同的导入方式。对于实时数据来说,我们可以通过 Flink 的 flink-connector- starrocks  转化为 streaming 导入到 StarRocks中。同时还可以写实时任务,通过 Kafka 来进行导入。对于存储在 HDFS 的单表数据量比较大的离线数据,可以通过 spark load 导入到数据库中。对于小批量的数据,可以直接通过 broker load 导入到 StarRocks 中。同时对于本地的一些数据文件,可以直接通过 stream load 进行导入。StarRocks 在 360 内部使用的外部表主要包括 MySQL 外部表、 iceberg外部表以及 Hive 外部表。通过 StarRocks 可以直接去查询这些外部表,而不需要进行数据的导入。最后通过 StarRocks 这一个查询分析引擎可以服务于多个业务平台,主要业务平台包括但不限于用户画像平台, Adhoc 分析统计报表监控平台等。

下面举三个例子,来介绍当前 StarRocks在 360 落地的数据产品首先介绍的是数据分析平台。数据分析平台是 360 内部面向企业内部人员进行数据分析的,是一个日常监控和运维的平台。在没有选择 StarRocks 之前,数据分析平台主要是通过 MySQL 来提供服务。首先介绍一下它之前的历史架构。这个架构主要是将 SDK 打点数据通过 SCRIBE 进行采集。之后分为两条流,一条流是实时流,一条流是离线流,实时流主要是通过 Kafka 、Flink 缓存到 Rides 中。离线数据,数据是存储在 HDFS 上。对一些明细数据直接通过 MapReduce 任务,转存到 MySQL 中。对于一些需要汇总的数据,则通过 Spark 或者 Hive 等进行分析,最终离线数据和实时数据流汇总到 MySQL,由 MySQL 来提供服务。随着业务数据的积累,逐渐出现了下面几点问题第一点是业务数据有一些高基维的存在,各业务有数10亿的汇总数据,由MySQL 负载起来压力比较大。我们只能按照业务线或者指标做一些分库分表的处理,这些分库分表的处理会给运维增加成本。另一个问题就是那些高流量的业务线,即使做了分库分表处理,数据量仍然是千万级别的,最终响应时间可能仍无法达到我们的预期。在通过 StarRocks 进行改进之后,实时流通过 Flink、StarRocks 来进行导入,离线流通过 Spark load 和 broker load 进行导入,完美解决了之前的痛点,StarRocks可以每秒处理高达 100 亿行的数据量,替代了分库分表的 MySQL ,降低了运维成本,简化了数据链路。同时我们使用了一些分桶分区来进行处理,存储数据,保证响应时间可以在两秒以内,提高了响应的速度,解决了用户需求。

第二个进行落地的产品是用户画像平台。用户画像平台的历史架构主要是通过 Druid 和 Hive on Spark 来进行数据查询和数据分析。新的架构通过 broker load 导入到 StarRocks 中,由 StarRocks 来进行平台数据的提供。历史架构的主要痛点是Druid对于集合类型的数据是无法进行处理的。因此除了通过Druid的来提供服务外,还增加了一条流,通过 Hive on Spark 来进行这一部分,来共同完成用户画像平台的一个需求。从架构上来看,历史架构包含两条流,对于运维来说会增添成本。使用 StarRocks 之后,考虑到人群画像平台会有用户标签表,我们针对用户标签表采用了明细模型,在将数据导入到 StarRocks 中的时候,利用 StarRocks 的 to_bitmap 将 user_id 映射为 bitmap 类型,后续通过 bitmap 运算支持存留分析等需求。Druid还有一个缺点是它不支持高效的精准去重,而 StarRocks 的 count(distinct) 是支持的,在这一方面StarRocks也补充满足了用户的一些需求,同时它还拥有一些复合的数据类型分析函数。在原来的架构替换为现在的 StarRocks 之后,查询性能和用户体验两方面都得到了很好的提升。

第三个进行落地的产品是搜索广告数据。之前搜索广告数据的历史架构主要是通过 Hive 和TiDB 来为用户提供服务,生成报表。新的架构主要是通过 StarRocks。之前的大概流程是将广告产生的点击、展现、搜索日志等,通过一些逻辑的处理之后存储在TiDB 或 Hive 中,再由它们来进行报表的生成,供广告主进行查询。由于 TiDB 无法进行提前聚合,所以查询性能相对较慢。再加上广告数据本身是涉及到多份数据的,对于一些多表 join 操作,Hive 和 TiDB 效率不高,切换为新的架构之后,我们利用 StarRocks 具有的聚合模型,提前对数据进行预聚合,同时还可以根据广告主的业务需求,进行物化视图的创建,通过物化视图来提高查询效率,同时它还支持 Hive 外表。我们利用 StarRocks 的这些特性很好地满足了用户的需求,同时也提升了整体的查询性能。

以上就是 StarRocks 在 360 的主要应用场景,以及目前已经落地的三个数据产品。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇