基于 StarRocks 现代数据栈的典型应用-- 迪族网

基于 StarRocks 现代数据栈的典型应用

来源：DataFunTalk 　2022-12-13 22:41:26

导读： 本次分享的主题是基于 StarRocks 现代数据栈的典型应用，主要围绕以下内容展开：

(资料图片仅供参考)

MPP 架构演进过程行业典型应用介绍 StarRocks 应用场景和核心特性性能测试报告 StarRocks 应用场景一——实时数仓 StarRocks 应用场景二——CDP StarRocks 应用场景三——Lakehouse Analytics 短期规划

最近我们接触了不少的用户，我们发现虽然他们的需求五花八门，但都是想要将海量的数据存进来，然后按照自己关注的角度快速高效地拿到有价值的信息。今天分享的主题是现代数据栈，但核心是数据，目标是提升数据的管理程度、大大降低数据的使用难度，让用户更加去关注数据本身、轻松玩转这些数据。这恰好吻合了 MPP 数据库演进历程，所以首先我们来简单看下 MPP 数据库的发展情况。

分享嘉宾｜谢寅 StarRocks社区技术布道师

编辑整理｜王鹏滴滴出行

出品社区｜DataFun

MPP 数据库概览

1. MPP 架构演进过程

上图展示了 MPP 架构的演进阶段，演进的过程是与我们对数据的重视程度相关的。

早期搞一些有图有数据的离线报表向上汇报就够了，数据量可能也只是 GB 级，早期的一些数据库就能满足这样的需求场景。随着数据越来越多，早期这样的实现方式瓶颈也越来越明显，像 Hadoop 等大数据技术慢慢成熟起来，包括 Teradata、Greenplum 等老一代的 MPP 数据库也发展起来，人们开始注重数仓建设和数仓建模。结构化的数据被更有条理地分层构建，高价值的报表通过 BI 或数据应用呈现出来。后来有了更成熟的离线报表构建方法论，因为用户不满足 T+1 或者小时级的离线报表，不再满足于固化的受限制维度的数据分析，就演进到了新一代的分析型数据库，在通用的服务器上对 TB 或 PB 级数据进行灵活的交互式探索分析，数据端到端的延迟也可以从天压缩到小时甚至秒级。

实时数据分析被更多的公司认可，报表越早提供出来，对公司的价值就越大。比如一个风控系统，原来可能受技术的限制只能实现小时级的，但是 1 小时过去后可能已经造成了不少的经济损失。如果可以把时效性提高到秒级，则意义重大。

到这一阶段我们可以灵活地分析结构化的数据和半结构化的数据，对于海量的非结构化数据，我们就选择数据湖。这意味着我们需要同时维护数据仓库和数据湖两套系统，但这两套系统在存储上是割裂的，我们就期望使用新一代的技术同时去加速数仓和数据湖，能够有效衔接湖和仓，实现湖仓一体联邦的分析。

这就是整个 MPP 架构演进的过程，正如上图中所示，随着 MPP 用数需求的深入，从固定分析演变到自助分析，从离线数据变化到实时数据，从专用设备变为通用设备，从数据仓库演进为湖仓一体，从存算一体逐渐演进为存算分离。

2. 行业典型应用介绍

下图展示了一些典型行业的创新型应用：

3. StarRocks 应用场景和核心特性

基于上述行业中的典型应用，我们整理出 StarRocks 的 4 个比较典型的应用场景和 3 个核心特性。

4 个典型应用场景分别为：

即席分析：基于 StarRocks 的向量化查询、CBO 优化器技术可以对复杂查询生成一个最优的查询计划，适应用户拖拉拽产出的 SQL。另外也可以对湖或仓进行联邦的分析。实时分析： StarRocks 可以秒级从消息系统摄入数据，并和 Apache Flink 整合做一些数仓的实践。用户画像：可以利用 StarRocks 做一些用户画像系统的落地。固定报表：这是 StarRocks 的看家本领，主要是固定报表场景下的 OLAP 分析。

下图展示了 StarRocks 的 3 个核心特性——极速查询、灵活建模以及实时摄入和查询数据的能力：

4. 性能测试报告

在单表查询上面，StarRocks 的查询性能优于 ClickHouse 的性能：

在多表关联查询上面，StarRocks 的查询性能也很卓越：

StarRocks 应用场景一——实时数仓

在使用 Apache Flink+Apache Kafka/Pulsar 将数据实时处理完后，怎么保证端到端的低延迟服务，也就是数据摄入和查询的时效性。针对这个问题，基于 StarRocks 有三种构建实时数仓的方法论：

方案 1：微批调度

Apache Flink 清洗导入 Apache Kafka 的日志或者用 Apache Flink- CDC-StarRocks 读取 MySQL Binlog 导入 StarRocks，ETL 过程中埋入批次处理时间，采用外围调度系统（比如 DolphinScheduler），基于批次处理时间筛选数据，做分钟级微批调度，向上构建实时数据。

方案 2：增量构建、聚合

这种方案的主要算力在 Apache Flink 和 Apache Kafka 里面，StarRocks 不参与建层的过程。实时消息流通过 Apache Kafka 接⼊，采用 Apache Flink 进⾏流式 ETL、多流 Join、增量聚合等，在 Apache Kafka 中完成分层构建，然后将相应的数据，层对层的通过 Apache Flink-Connector 或 StarRocks 内置的 Routine Load 导入任务写出到 StarRocks 对应表内,各层按需面向下游提供 OLAP 查询能力。

方案 3：StarRocks 视图

有些场景会涉及到数据的 Upsert/Delete 操作，比如使用 Apache Flink 做 Group By 可能会产出回撤流，将之前聚合的结果回撤回来，将新增的聚合结果产出出来。对于这种操作，要求 OLAP 场景支持 Upsert/Delete 操作，保证业务库的高度还原。以上两种方案就不太适合。因此采用 StarRocks 视图方案构建实时数仓。

这种方案首先使用 Apache Flink 清洗导入 Apache Kafka 的日志或者用 Apache Flink-CDC-StarRocks 工具读取 MySQL Binlog 导入 StarRocks，然后根据需要选用明细、聚合、更新、主键各种模型，只物理落地 ODS 和 DIM 层，向上采用 View 视图，最后利用 StarRocks 向量化极速查询和 CBO 优化器满足多表关联、嵌套子查询等复杂 SQL，查询时现场计算指标结果，保证指标上卷和下钻高度同源一致。

实时数仓未来演进：

直面分析，按需加速，或是未来实时数仓的新范式。当前我们使用 ETL 的思路来构建实时数仓，在未来我们可能会转成 ELT 的形式。结合 StarRocks 多表物化视图、部分列更新的能力，结合 Apache Flink 来做实时的更新，提供高并发、低延迟的服务。

StarRocks 应用场景二——CDP（客户数据平台）

CDP 系统的核心是如何高效地去做客群的圈选。

1. CDP 系统

传统方案使用 ES 或 HBase 存储用户标签的行为、属性，然后进行标签的圈选，链路非常复杂，还要维护多个组件，也不能做多表的关联，聚合的能力也有限。

基于 StarRocks 的方案，可以使用 RoaringBitmap 数据结构按位计算求交集、并集、差集等，方便去做圈选，也可以实时摄入 Kafka 里的数据来做实时的行为分析。

2. ID-Mapping

基于 StarRocks 的 CDP 方案的一个关键点就是 ID-Mapping，即把不同来源的身份标识通过数据手段识别为一个用户主体，同一个用户在登录和未登录的行为数据之间需要打通，用 Apache Hive 做 ETL，完成 UID 和 Cookieid 的映射关系。

3. 全局字典

RoaringBitmap 必须使用 Int 类型的数据作为去重标识，StarRocks 提供了全局字典功能将 String 转成 Int。

下图描述了在明细表中找出有添加进购物车和查看收藏页行为的用户列表的 Demo：

4. 用户行为分析

最近我们也做了一些行为分析方面的功能，比如留存函数、漏斗函数，配合 CDP 系统来做更好、更完善的服务。

StarRocks 应用场景三——Lakehouse Analytics

下图展示了 StarRocks 支持湖仓一体能力的概况，StarRocks 现在已经支持 Apache Hive、Apache Hudi、Apache Iceberg 的外表查询能力，可以做湖仓一体的联邦的分析。可以利用透明加速功能，将热的数据自动的拉到本地 SSD，将老的数据走现在的外表的形式，对于客户来说是无感知的，查数据就像查本地数仓一样，这样就大大降低数据迁移和使用的成本。

成果案例

下图展示了某公司架构变化前后的对比，可以看到早期架构比较多地依赖于 Presto、Spark 等，做很多宽表，指标重复构建，导致了很高的成本。因此构建了一个统一的指标平台，通过数据治理，统一纳管所有维度和指标，并且埋入了一些手段来诊断构建每个指标占用的存储和网络带宽，消耗了多少人力成本和资源，从而帮助审计基础设施的开销和成本。

短期规划

最后介绍一下我们的短期规划。

Resource Group： StarRocks 2.3 已经支持了 Resource Group，能够实现大小查询的资源隔离，未来会做更精细的资源隔离功能，让资源隔离功能更可靠。 Partial Update：使用 Partial Update 的能力，可以让建设实时数仓时不用大量地去建宽表，类似 Apache Flink 多流 Join 的操作可以更多地下沉到 OLAP 数据库来做。 MTMV：多表物化视图。StarRocks 2.4 会发布一个初版的离线多表物化视图，很大程度会简化数仓模型。明年 Q1 的时候会提供增量的物化视图，来应对实时的场景。 SaaS：我们会提供一个 SaaS 版本，方便客户快速以 BYOC 的模式部署 StarRocks 集群。

问答环节

Q1：StarRocks 是否已经支持了 Apache Iceberg 的 v2 版本？查询数据湖外表性能与导入到 StarRocks 内部查询性能差距大吗？

A1：v1 已经支持，v2 已经开发完了很快会发布。性能上，导入到 StarRocks 内部查询性能需要跨引擎拉数据，有一定的网络消耗。StarRocks 查询 Apache Iceberg 外表性能比直接查询 Apache Iceberg 性能会提升 3 倍左右。

Q2：StarRocks 有像 Oracle 那样的存储过程吗？

A2：当前还不支持存储过程。

今天的分享就到这里，谢谢大家。

｜分享嘉宾｜

谢寅

StarRocks社区技术布道师

曾供职于 CBS Interactive、PerfectWorld、ChinaCache 及车联网企业，具有多年大数据开发经验，致力于持续迭代完善基于实时数仓、自助式分析、用户画像、湖仓一体联邦分析等场景的联合解决方案。

｜DataFun新媒体矩阵｜

｜关于DataFun｜