作者 | 达达快送大数据运维数据库工程师 刘明
达达快送是达达集团旗下中国领先的本地即时配送平台，与传统物流相比，即时配送具有速度快、效率高、服务范围广等优势。为了提高数据分析的效率，达达先后在 OLAP 层引进了 Apache Kylin、Elasticsearch、Apache Druid、ClickHouse 和 Apache Doris 等组件。在综合考量查询性能、系统稳定性以及社区活跃度等因素后，达达最终选择了 StarRocks 作为统一的 OLAP 引擎。这一决策不仅使物理机器成本降低了 30%，还大幅提高了数据开发效率，在某些场景下查询性能提升了 10 倍以上。在应用方面，达达基于 StarRocks 构建实时数仓和流批一体的计算，通过离线和实时数据处理链路整合订单数据、库存数据、配送时间、配送路线、配送员信息、客户数据等，并且将业务分析响应时间时间从原本的分钟级降低至秒级。接下来，达达也计划将解锁 StarRocks 存算分离架构以持续降本增效，并利用 StarRocks 的湖仓分离能力一同构建湖仓分离新范式完成数据分析的再进化！
达达集团是中国领先的本地即时零售与配送平台（纳斯达克股票代码：DADA）。以“万千好物，即时可得”为愿景，引领中国零售业步入新时代。旗下有达达快送和京东到家两大核心业务平台。
达达快送是达达集团旗下中国领先的本地即时配送平台，以众包为核心运力模式，搭建起由即时配、落地配、个人配构成的全场景服务体系，服务于各行业知名企业、中小企业与个人用户，经过长期的模式创新和技术迭代，达达快送可为商家提供全渠道订单一体化履约服务。
京东到家是达达集团旗下中国领先的本地即时零售平台，依托达达快送和零售合作伙伴，为消费者提供超市便利、生鲜果蔬、医药健康、3C 家电、鲜花绿植、蛋糕美食、服饰运动、家居时尚、个护美妆等海量商品约1小时配送到家的即时消费服务体验。目前，达达快送业务累计覆盖全国 2700 多个县区市，京东到家业务累计覆盖全国超 2000 个县区市。
一、OLAP 分析从“复杂多弱”走向“极速统一”
随着国内大数据架构技术的不断演进，达达快速构建了以 Apache Hive 和 Apache Spark 为核心的离线数据仓库，以及以 Apache Flink 和 Apache Kafka 为核心的实时数据处理链路。在业务发展和整体架构的不断迭代过程中，我们尝试了不同时期出现的优秀 OLAP 产品来解决我们在数据分析中对查询加速的需求。
在解决多维分析和 BI 报表场景时，我们尝试了 Apache Kylin。然而，Kylin 过于依赖 Cube 预计算 ，导致在数据源变化时需要重新计算，无法自动同步更新。当统计维度发生变化时，必须耗费大量计算资源和人力成本来重建历史数据。这种提前定义和预计算数据方案限制了灵活的数据建模能力，尤其在维度较多的情况下，数据膨胀问题严重。
为了弥补 Kylin 的不足，我们采用 Elasticsearch 作为维度数据存储引擎，同时使用 Apache Druid 作为存储和查询大量事实数据的混合解决方案。然而，随着数据量和业务需求的增加，查询响应速度变慢的问题变得更加明显。在这过程中，我们引入了 Clickhouse，它具备出色的数据压缩能力、列式存储和向量化引擎，在单机宽表的查询性能很强悍，可惜多表 Join 的能力和分布式集群模式下的在线扩展能力表现差强人意。
图片
随着引入的组件逐渐增多，技术栈变得复杂，大数据整体架构变得庞大，导致运维成本居高不下，难以确保服务质量。开发人员还需要根据不同的场景选择不同的组件，而 SQL 支持的差异性也增加了开发的难度。数据分散多份，无法有效的贯彻数仓 OneData 的建设要求。
虽然许多组件都有各自的优势，但基本上都存在开发灵活性不足、查询性能较低、查询并发能力弱、服务不稳定、实时性不足等问题。在当前迫切需要降本增效的形势下，StarRocks 的及时出现让这些问题迎刃而解，也为后续的架构优化确定了方向。
最开始我们使用的是 Apache Doris 0.14 版本，从整体查询性能、系统稳定性、社区优秀的服务支持角度考虑，最终我们转向使用 StarRocks。在进行整体集群迁移前，我们对 Apache Doris 0.14、StarRocks 2.4.1 在同等集群规模下，进行了一些基准测试验证（ SSB、SSB-FLAT、SSB-低基数 Query、TPC-H 100G 的标准测试集）：
图片
图片
StarRocks 在标准 SQL 支持、MySQL 协议兼容性、离线/实时导入、聚合查询、明细查询、Adhoc 查询、主键模型索引落盘以及部分列更新等方面表现符合达达快送对新一代数仓的期待，在开发成本、运维成本方面能取得良好的平衡。我们使用 StarRocks 取代了原有架构中的 Apache Kylin、Apache Druid 和 Clickhouse，同时调整了 Elasticsearch 的组件功能，有效解决了之前在 OLAP 分析层面临的大部分问题。这一系列调整不仅降低了 30% 的物理机器成本，还显著提升了数据开发效率。
我们一直坚持降低成本、提高效率的目标，对查询性能和系统稳定性也提出了更高的要求。随着 StarRocks 主键模型对主键索引落盘的全面支持，我们投入了一个季度的时间，成功将位于京东云上的所有业务迁移至 StarRocks 平台，并已持续升级至 2.5.5 版本。在 OLAP 分析层，我们的技术栈已经基本实现了统一。
二、StarRocks 在达达快送的应用
1.基于 StarRocks MV 构建实时数仓
在构建实时数仓时，我们在离线数仓的基础上，巧妙地将 StarRocks 与 Apache Hive 集群以及我们自研的任务调度平台相结合。实时数仓的数据源涵盖了离线数仓、MySQL、APP 埋点数据以及实时日志数据。我们充分利用了 StarRocks 异步多表物化视图的特性，对数仓进行了分层处理，经过各层的数据加工和处理，最终为各个场景提供了统一的数据服务。
图片
得益于 StarRocks 的单表实时 MV 和多表异步 MV 的 ETL 处理能力，不仅加速了整个数据链路的 ETL 过程， 而且以 StarRocks 为基座实现了与离线数仓对等分层的实时数仓。
在我们的架构中，ODS、DWD 和 DWM 层都充分运用了物化视图。基于单表实时物化视图，例如在“多级区域订单”的实时看板场景中，我们根据不同的行政区域划分层级进行物化视图的创建。在 ETL 过程中，多表异步 MV 扮演关键角色，许多任务的刷新频率达到每 5 分钟一次。以“订单退单”的场景为例，Flink 将数据汇入 ODS 层的数张基础表，然后通过异步 MV 构建到 DWD 层，接着在 DWD 层中与其他所需的事实表和维度表再次构建 MV，最终落到 DWM 层。
借助物化视图的构建，我们成功将业务查询响应时间从分钟级提升到秒级。对于那些需要风险控制和及时干预决策的场景，更快的查询结果返回意味着更快地发现问题，从而迅速引发运营的及时介入与干预。
2.基于 StarRocks 的流批一体计算
随着移动互联网的广泛普及、O2O 模式的爆发以及新零售的崛起，一个与传统物流快送行业完全不同的新型配送模式正悄然兴起，并逐步趋于成熟。即时配送是一种无中转、点对点的快速准时送达服务。其服务场景主要包括外卖、B2C 零售、商超便利、生鲜宅配、快递末端派送、C2C 配送等需求，配送距离通常在 5 公里以内，覆盖范围紧扣消费者的生活圈。
即时配送对时效性要求极高，通常以分钟为单位来衡量，订单的服务时长在 1 小时内完成，而在不同情境下，往往可以在半小时内完成送达。另一个角度来看，即时配送订单呈现出的另一特点是服务需求的不连续性，或者说是非计划性的消费需求，这导致订单数量的波动性极大。以外卖订单为例，全天订单量分布呈现明显的波峰和波谷，高峰值的订单密集度较高。
通过充分利用 StarRocks 在多种数据源场景下的不同导入方式，我们能够将实时数据与离线数据有机地结合在 StarRocks 中进行 ETL 处理与加工。
图片
达达快送使用基于实时环境下的配送区域动态网格统计计算，整合订单数据，对历史轨迹数据、行驶区域数据、配送业务数据、实时订单数据、骑手轨迹数据、库存数据、配送时间、配送路线、配送员信息、客户数据等以及与配送相关的特征和指标数据等进行精准迅速的流批一体数据计算。
借助 StarRocks 的实时更新列式存储引擎、全面向量化引擎、全新的基于代价的优化器 （CBO）、实时物化视图的能力，我们将实时运单流与区域网格数据的关联匹配，查询计算从分钟级别提升到了秒级别。在区域订运单状态统计场景中，有效提升了分析效率和用户体验。
3.基于 StarRocks 外部表的“读写分离”
在当前的 2.5 版本中，StarRocks 采用资源组（Resource Group）的方式来实现资源隔离，限制了查询对资源的消耗，从而实现了多租户之间的资源隔离和合理利用。但这种资源组的方式是对内存的硬隔离，对 CPU 和 I/O 的软隔离。对于我们的情况——离线数据通过 Hive+Spark 批处理后以 T+1 的方式通过 broker load 导入 StarRocks，实时数据通过 Flink 消费 Kafka，然后通过 routine load 导入 StarRocks。当实时数据导入任务较多时，会造成较大的资源消耗，在现有集群规模下可能会对业务查询产生一定影响。
为了解决这个问题，我们借助了 StarRocks 外部表的能力，构建了“读写分离”模式的集群。举例来说，我们多个业务功能的 StarRocks 集群主要负责各自数据的加工与写入，在面向报表查询的服务集群中会创建连接若干不同集群的 StarRocks 外表。这样做带来了多种好处，比如数据源保持一致，读写压力在一定程度上分离，从而提升了业务的使用体验。同时，我们也根据不同的业务功能群（包括业务等级）划分并建设了多个 StarRocks 集群，这在一定程度上也间接解决了资源隔离和争用的问题，当然，这也可能会带来相对较高的资源成本。
在未来的 StarRocks 3.2 版本中将会支持存算一体架构下的主备集群能力，以及存算分离架构下的多仓库（multi-warehouse）能力，这将完美解决读写分离的问题。
三、后续发展与计划
1.解锁存算分离持续降本增效
在今年 4 月发布的 StarRocks 3.0 版本中，StarRocks 推出了新的存算分离架构，且在这个月发布的 StarRocks 3.1 版本中，这一架构得到了进一步的加强，支持了主键模型表，并且引入了算子落盘的能力。
从 StarRocks 社区提供的数据看来，存算分离架构保持了 StarRocks 存算一体模式下强悍的查询性能。下图展示了在 TPC-DS 1TB 数据集规模下存算分离和存算一体的性能测试结果：
图片
图片
标准数据集结果显示：
1.在 cache 全命中的条件下，存算分离性能与存算一体查询性能几乎保持一致
2.即使在 cache 完全 miss 情况下，查询性能下降也在可接受的范围内
在这个 SAAS 时代，达达也会积极的依托京东云，积极利用 StarRocks 的存算分离能力，不断推动降本增效的进程。
2.从数仓到湖仓一体的进化
接下来，我们会逐步迁移我们在 OLTP 库上的 OLAP 分析业务。同时也会积极推动 Presto 查询场景向 StarRocks 迁移，完成数仓到湖仓一体的进化。
我们会基于 StarRocks 3.0 的另外一个重要能力——湖仓融合一体化的能力来简化数据分析。数据可以直接入仓分析，也可以写入数据湖后由 StarRocks 直接分析湖上数据，无需做数据迁移；通过物化视图的能力，可以将湖上的数据写入到数仓里加速查询，数仓的计算结果可以再写回数据湖，实现湖仓的无缝融合。
图片
StarRocks 直接分析数据比 Trino 平均快 3-5 倍，大幅提升整体的性价比。为了能更方便的从 Trino 到 StarRocks 升级，降低其分析成本，StarRocks 提供了 Trino SQL 语法兼容的能力，将 Trino SQL 自动改写成 StarRocks 的 AST，充分利用了 StarRocks 的高性能执行引擎。
图片
最后，我们要感谢 StarRocks 社区在达达 OLAP 极速统一上所提供的支持。未来，我们也希望利用 StarRocks 不断提升的能力完成湖仓一体的统一。祝福 StarRocks 开源社区繁荣发展，更上一层楼！
