微信作为国内活跃用户最多的社交软件，其数据平台建设经历了从 Hadoop 到 ClickHouse 亚秒级实时数仓的阶段，但仍旧面临着数据体验割裂、存储冗余的问题。通过 StarRocks 的湖仓一体方案，以及和社区密切配合开发的实时增量物化视图，微信解决了“实时、极速”背后的“统一”诉求。在直播业务场景中，通过湖上建仓的方案改造，使得数据开发同学需要运维的任务数减半，同时存储成本降低65%以上，离线任务产出时间缩短两小时。

当前，基于 StarRocks 的湖仓一体方案已经在微信的多个业务场景中上线使用，包括视频号直播、微信键盘、微信读书和公众号等，集群规模达到数百台机器，数据接入量近千亿，向理想化的湖仓一体形态不断演进。

2024年之前，DBA维护的StarRocks集群存在在用低版本多、稳定性受组件bug影响大的问题，给日常运维带来很一定压力，版本升级迫在眉睫。于是，我们在今年年初安排了针对2.5以下版本升级2.5.13的专项，在此做一个实践分享。

风控实时特征场景是典型的大数据实时业务场景，风控团队也采用了业界典型的Lambda架构，和Kappa架构，但这两种架构仍存在明显的痛点问题。为解决其痛点，我们开始了基于StarRocks实现实时数仓解决风控实时特征痛点问题的探索和实践。

高并发精准去重的最佳实践，文中含详细构建过程。

对账是企业为了核实财务交易准确性、管理库存和了解业务绩效而进行的核对和调解过程。

在科技高速发展的当下，ARM 架构由于其开源性和功耗上的优异表现正在受到越来越多的关注，大数据相关的各种组件也纷纷推出了基于 ARM 架构的版本用于更好的支持用户体验。

微盟引入StarRocks后，对制表的规范做出总结以及整体监控体系的介绍。

StarRocks加持的快速灵活指标平台，让取数更加灵活快捷。

货品活动运营在圈选所需货品清单时，需要操作自助取数、智能运营系统、数据报表等多个系统工具才能完成。需要一个以供给侧盘货为核心需求的盘货工具，实现运营各场景盘货及货品分析诉求，提升运营效率。

StarRocks（以下简称SR）是新一代极速全场景 MPP 数据库，可以满足多种分析需求，包括 OLAP 多维分析、定制报表、实时数据分析；伴随公司 WOS 升级战略，BI 在 WOS 系统中的选型 SR 作为数据分析层数据库；SR 应用实践过程中随迁移 WOS 的商户越来越来多，SR 内数据随之增大，逐渐暴露出来一些内存不足问题，主要为以下问题造成：

1. 主键模型表常驻内存持续增大，最高占用可用内存的16%。
2. tablet过多，270张表160W+个tablets，小于100M的约占90%。

未来希望 StarRocks 优化提升主键模型内存占用，支持更灵活的部分列更新方式，持续优化提升 Bitmap 查询性能，同时优化多租户资源隔离。

汽车之家广告主题离线数仓从2015年开始建设至今，一直能够满足车智投、DSP等广告业务的日常分析及报表支持。

本文主要介绍搜狐智能媒体，在微服务体系架构下，使用zipkin进行服务链路追踪（Tracing）的埋点采集，将采集的Trace信息存储到starrocks中，通过starrocks强大的SQL计算能力，对Tracing信息进行多维度的统计、分析等操作，提升微服务监控能力，从简单统计的Monitoring上升到更多维度探索分析的Observability。

作为DBA团队，我们负责运维到家MySQL，Redis，Es相关数据库，去年下半年新业务希望数据库支撑复杂的OLAP需求，进行千亿量级的数据分析，满足秒级多维度和条件的组合查询，实时聚合，改造成本要求尽量低。

多点DMALL通过引入StarRocks，逐步替代了 Impala、Impala on Kudu、Apache Kylin 等存储引擎，简化了实时数据处理链路，同时也能保障较高的查询并发以及较低的响应延迟要求。

在汽车之家内部，实时数据的来源主要是三部分：

• 手机端户行为的日志；
• 应用程序的服务端的日志；
• MySQL、SQLServer数据。

实时数据分析场景，目前面临的一些痛点包括：

• 使用 Flink 做指标聚合，Flink 聚合不灵活，面对需求的时候开发成本比较高的，面对多变的需求，经常需要重复开发；
• Kylin 支持指标预计算，并发支持较好，但是不能够支持高效的明细数据查询。在一些需要下钻或者获取明细数据的场景支撑的不够好；
• TiDB 不支持预聚合模型，某些数据量大的场景，聚合指标需要在线计算。在线计算会导致服务器压力瞬间增大，而且查询性能不稳定，取决于参与计算的数据量和当时服务器的负载情况。