作者：网易邮箱 黄贤康。现任职网易邮件事业部资深数据开发工程师，作为主要开发人员参与网易邮箱大数据平台的建立、优化、重构等工作，并取得相当的成效。他长期从事服务端应用及大数据领域的架构研发工作，对相关领域的底层架构、开发流程及技术细节等都有一定积累。

（本文为作者在 StarRocks Summit Asia 2022 上的分享）

从零到一，臻于至善，反映了网易人对于数据追求的不断进步，也反映了 StarRocks 在技术方面尽善尽美的追求。本次分享给大家介绍网易邮箱基于 StarRocks 开发大数据平台的实践心得。

#01

网易邮箱业务背景

1.1 网易邮箱发展史

网易邮箱作为国内互联网行业一个活化石级别的业务，从诞生到现在已经进入第二十五个年头：

• 1997年：第一个国内互联网电子邮箱系统。

• 2000年：VIP收费邮箱和免费邮箱齐头并进。

• 2008年：桌面端的闪电邮面世。

• 2009年：企业邮箱上线。

• 2010年：拥抱移动互联网浪潮，手机号码邮箱以及邮箱大师 APP 上线。

• 2016年：从网易邮箱孵化的网易严选电商平台上线

网易邮箱见证了国内互联网行业从诞生到发展以及壮大的整个过程，相应的数据处理架构也发生了一系列变化：

• 2005年至2017年：基于 Hadoop 生态构建的大数据架构。

• 2018年到2020年：基于 Flink + ClickHouse 自研的批流合一的大数据平台。

• 2021年至今：基于StarRocks构建的极速统一的大数据平台。

1.2 邮箱数据应用场景

业务日志数据存储：所有业务日志都要求永久冷备存储，同时在一些关键的业务上面，要求至少有半年以上的热点数据的热备存储。不同的数据分别存储，离线数据存储到 HDFS ，实时数据存储到 ClickHouse。

业务可用性保障：网易邮箱作为一个通信性质的业务，它的核心收发信链路以及用户登录验证机制对可用性要求非常高。

核心指标统计：包括用户的活跃度，用户新增/流失/挽回等转化率，APP的安装率， Webmail 的登录等数据，会生成数据报表进行数据展现。

运营策略指引：包括直邮、推送等的转化率的分析，以及引流用户的留存率等方面的一些数据统计。

反垃圾与风控：邮箱需要具备反垃圾的能力以及风控的能力，会对用户的敏感行为做出判断，通过数据的反馈来进行捕捉，同时制定反垃圾策略。

业务产品优化：邮箱的数据产品会支持一些业务的优化，包括对一些新业务的用户使用数据的采集分析，以及诸如用户支付和订阅情况的分析等。

1.3 数据规模与业务现状

服务器方面。包括一些实体机和云上的一些虚机，总的算力超过1万核，服务器分布在华北和华东等各个 IDC 机房。数据比较分散，汇总处理的难度较高。

用户量方面。网易邮箱存量的注册用户达到10亿级别，同时每天还在新增巨大的新注册用户量。存量和增量巨大，风控的压力较大。

数据量方面。冷备的历史压缩数据已经达到PB级别，同时每天新增的数据量也很大，内外网的数据流量峰值达到每秒上G的级别。资源吃紧，维护成本高。

业务线方面。核心的收发信数据链路和登录服务的可用性要求都是 SLA 达到 99.99%，同时每天都有超过1000个的离线数据处理任务，实时数据处理要求7×24小时无间断运行，下游支撑超过1万个数据服务。业务模型复杂，服务精度、可用性要求高。

#02

OLAP 引擎演进与选型

2.1 OLAP 平台演进

网易邮箱作为国内互联网行业里面最早接触大数据领域的互联网厂商之一，从05年就开始接触 Hadoop 架构作为大数据处理平台。当时主要功能是数据的存储和采集，使用 MapReduce 进行数据处理，使用 Hive 和 HBase 进行离线和实时数据查询任务，数据输出使用 Oracle 的 BI 系统实现。

随着技术的不断发展，到18年逐渐过渡到基于 Flink + Kafka + ClickHouse 以及网易杭研自研的猛犸平台组建的一个批流合一的数据平台。ClickHouse 作为 ODS 基础数仓，主要用来支持实时性的查询任务，猛犸平台主要负责任务的编排和调度，自研的数据报表系统进行数据的呈现。

随着业务深入的发展，现有的架构在一些特殊的场合或需求下，有些力不从心。包括一些跨表的或者复杂度较高的查询，以及一些高并发的场景，还有一些大数据的热点更新的场景，现有的架构都没有办法做到满意。

网易邮箱从21年开始引入了 StarRocks，作为下一代数据引擎架构，解决高并发查询输出，复杂事务跨表查询，数据热更新支持等问题。

2.2 为什么引入 StarRocks

网易邮箱为什么会引入 StarRocks，这要从业务痛点说起。

首先，从资源方面来说，网易邮箱因为用户量和数据量都非常大，资源显得有些不足，造成 Kafka 和 ClickHouse，以及运算机器本身等，经常会出现一些因为压力过大而产生的报警，影响数据业务的开展和数据处理任务的开发。

其次，因为现有架构里面会同时存在多个数据平台，每个平台都要相应的运维人员介入，造成运维成本和采购费用居高不下。

再次，在数据需求方面，当前的架构与一些业务需求不匹配，主要体现在包括离线实时，和一些高并发以及跨表的查询，都没有一劳永逸的方案。

同时，作为移动互联网的一个永恒不变的矛盾，产品对于数据需求的紧迫性，当前的架构没有办法很好的快速支持。

另外，在数据开发方面，由于邮箱的一些历史原因，一些比较老旧的基础服务的日志，开发的时候并没有考虑到数据统计方面的需求，这些日志的格式参差不齐，对数据清洗以及下游的数据存储的技术迭代有一定影响。

最后，系统的一些链路经过多年的迭代之后有些臃肿，而数据需求经常变化多端，导致开发人员的人力资源不是很够，造成开发难度的增大。

因为上述问题，我们迫切需要一个性能强悍、上手容易、部署简单、使用方便、适配性高、安全稳定的 OLAP 系统，而 StarRocks 刚好能满足我们的需求，这是我们为什么要引入 StarRocks 的根本原因。

2.3 OLAP 指标维度对比

我们对比了国内外一些比较常见的 OLAP 系统，包括 StarRocks、ClickHouse、Impala 以及最基础的 Kylin。下图是我们的对比结果。

我们对比的维度包括底层技术、查询性能、维护难度、场景适配、兼容易用、安全稳定和扩展伸缩7个维度。

ClickHouse 作为当前比较流行的 OLAP 系统，我们重点分析一下它跟 StarRocks 的一些区别。

底层技术方面， StarRocks 与 ClickHouse 都是基于 MPP 架构实现。

查询性能方面，StarRocks 的性能在单表查询上表现良好，多表联合查询方面比 ClickHouse 更有优势。

维护难度方面，StarRocks 没有三方依赖，可以开箱即用，而 ClickHouse 的维护难度在业界是出了名的高。

场景适配方面，我们当前的实际应用是实时数仓，存储海量的流水数据。StarRocks 提供了若干种数据模型，可以覆盖大部分的业务场景。

兼容易用方面，两者的表现差不多。ClickHouse 支持 HTTP 接口，StarRocks 的优势则体现在提供多种 IO 的支持，以及对于 MySQL 协议的兼容。

安全稳定方面，分区分桶和多副本架构两者都支持，最大区别是 ClickHouse 的分布式高可用是基于ZooKeeper 实现的。我们在实际应用中发现，在高负载的情况下，ZooKeeper 的表现是比较差的，经常出现一些诸如复制失败、数据丢失的情况。StarRocks 则是基于自研的 BDBJE 来实现，在我们的实际应用过程中并没有发现它出现类似 ClickHouse 那样的数据异常的问题。

扩展伸缩方面， StarRocks 的优势主要体现在它可以对每一个分区来灵活的定制它的数据扩容的方案，同时它在扩容之后，可以自动实现数据均衡，相对来说 ClickHouse 则需要人工介入来处理。

经过以上7大方面的对比，StarRocks 在各方面的均衡表现，都非常适合作为网易邮箱的下一代 OLAP 系统的选型。

#03

系统架构

3.1 系统架构描述

下图左边就是网易邮箱大数据处理系统的系统结构图，从左到右，从下到上可以分为5个层次。

左下角是数据采集层，它主要的任务就是将分布在各个服务器上的日志数据，通过 Flume 采集汇总到数据处理层，按照不同的类型诸如离线的或者是实时的分别存储到对应的存储介质上。

再上一层是数据加工层，对应不同的数据类型，离线数据使用MapReduce 任务处理，实时数据使用 Flink 任务处理，然后把数据存储到数据存储层。

再往上是数据存储层，最原始的没有经过任何加工的 ODS 数据会存储到 HDFS 上，经过一定的清洗形成的结构化数据会放到 ClickHouse 的实时数仓里面。从21年开始，数据存储层引入了 StarRocks 把 ClickHouse 实时数仓上的基础数据进行聚合提炼，以应对更深层更复杂的查询，和一些实时性的查询。

在数据存储层上面就是数据应用层了，应用层主要包括了数据大盘报表的输出，以及给下游业务提供的实时查询的业务接口。

右面绿色部分是数据治理框架，包括数据链路的监控，实时和离线任务的配套 Sloth，以及 Azkaban 的模型，还有我们出于对数据血缘方面的考虑，自己研发的一套任务执行框架，以及对应的 Kibana 和 Promethues 的数据监控系统。

这5大部分共同组成了一个完整的大数据处理架构。

3.2 StarRocks 使用场景

StarRocks 在网易邮箱的实际业务中的使用场景，可以分为4个类型：

• 多维度数据查询：包括支付链路漏斗分析、活动引流效果分析以及风控用户行为分析等。

• 日常数据处理：在这方面是把 StarRocks 作为一个工具库来使用，比如一些推广或者一些用户导流方面的用户筛选，以及一些多元数据的合并处理如关联过滤去重等。

• 实时数仓的聚合处理：用户的存储容量需要实时的叠加汇总，来生成一个最终的指标，另外还需要对用户行为进行分析、识别恶意用户等。

• 高并发数据查询接口：包括数据链路的告警，还有一些用户行为机制的触发等。

以上4种场景都是基于 StarRocks 提供的，包括跨表查询的能力、聚合模型实现的数据热更新以及高并发的数据查询响应能力等。这使得 StarRocks 能够适应网易邮箱大部分的使用场景，能够做到以往要靠多个系统才能完成的工作。

3.3 StarRocks 表现

• 性能

下图中的3是我们生产环境中的一个 StarRocks 集群，包括三台物理机。

图中的1是一个跨表查询的结果，在若干个数据规模超过亿级的大表上进行一个联合查询，大概两分钟左右能够产生结果，这是比较强悍的一个跨表查询，解决掉了我们以往的比较头痛的问题。

对于这些复杂的查询，以往只能在数据规划阶段，把所有维度都合成一个大宽表来实现，一来导致维护的难度较高，二来会造成数据冗余，实现不够优雅。有了 StarRocks 之后，可以充分利用它的跨表查询的能力，把不同的数据，按照各自的特性切分到最合适的维度，在查询时根据各自的特性，组合成一个结果输出。

图中的2是在一个高并发场景下的压测结果，在100个并发以内，StarRocks 的响应时间都可以控制在50毫秒以内，这样的高并发的响应效率，已经足以媲美 HBase 或关系型数据库的能力了。因此StarRocks 其实已经能够取代关系型数据库的部分应用场景，从而不需要部署多种不同的业务架构，实现我们减少投入的目标。

图中的4是数据的 IO 的压测结果，基于文件的 Stream Load 来进行压测，导入1.1亿条数据，耗时5分钟左右。比较强大的交互式数据导入能力，保证了 StarRocks 作为基础数仓对接不同数据源的扩展能力。

• 运维

对比 ClickHouse 和 Hadoop 这些比较传统的大数据架构，StarRocks 的系统维护门槛相对较低，主要体现在它是一个没有第三方依赖的系统，能够开箱即用。

StarRocks 的 FE/BE 的分离设计，分区分桶的数据存储方案，还有多副本机制，能够最大程度的保证数据的可用性。

StarRocks 分区分桶的设计，保证了能够支持在线扩容、自动数据均衡、自动冷备等特性，很大程度上降低了维护人员的工作强度。

StarRocks 还配备了覆盖面比较广的Grafana模板，提供集群性能指标的全方位可视化监控，使我们能够随时随地监控集群的运行情况。

• 使用

StarRocks 提供了多种数据模式来支持不同的业务场景，像明细、聚合以及主键更新等，可以选择最贴切的数据模型来应对业务场景的开发。

StarRocks 支持文件、流以及外部表等多种数据交互方式，还提供了 Flink Connector 来提供流数据的支持，可以直接对接 Flink 任务实现数据流的导入。

StarRocks 的存储可以灵活的配置，像分区分桶的策略、TTL 的自动实现以及对外部表和物化视图的支持等，这些设计都能更好的提升查询性能。

StarRocks 支持标准的 SQL95 语法，同时提供了丰富的函数以及 UDF 自定义函数的功能。另外 Bitmap 可以实现数据的过滤去重以及索引的管理等。

StarRocks 在交互接口方面，它提供了 FE 多节点自动轮巡的 HTTP 接口，能够实现负载均衡。同时它对于 MySQL 协议的全兼容，很大程度上方便了业务开发，可以直接使用 MySQL Client 或者 JDBC 的驱动来开发对接。

StarRocks 有充分的技术团队支持，这也是它最重要的优势。镜舟公司提供了强大的业务团队，帮助解决我们在开发过程中遇到的问题，对于一些数据处理的工作，也提供了强大的业务支持。

#04

应用案例

4.1 用户登录处理链路

左边是数据链路的一个示意图，用户登录的行为数据，经过 Kafka 以及 Flink 的实时处理之后，存储到 StarRocks 数仓，然后同时支持下游4个不同的数据需求。

1. 数据的落盘存储。

2. 基于存储之后的数据，在 T+1 的时间窗口进行数据的统计，最终生成 OKR 指标，输出到下游的数据报表系统。

3. 实时的用户登录，我们要求进行一些监控，来保证用户的敏感行为能够自动聚合叠加，到达一定阈值之后，触发一些风控处理。

4. 针对需要实时查询的数据，提供一个查询接口，供下游业务调用。

以上4个需求，正好分别对应 StarRocks 的4个特性：

• 明细模型可以很好的支持海量数据的落盘。

• 聚合模型能够最大程度的简化数据叠加的处理逻辑。

• 跨表查询能力能够简化 OKR 指标的生成。

• 高并发的能力能够最大程度的支持数据接口的开发。

4.2 推广活动漏斗分析模型

左上角的图是网易邮箱比较常见的推广活动的节点链路的示意图，它包括6个数据节点，每个节点都会按照用户的操作行为，将数据反馈到后台的数仓里面。

我们的任务就是根据这些反馈的素材数据，建立如右图这样的漏斗模型，方便产品和推广人员直观的分析出推广链路里面的短板是哪个环节，用户在每个环节里流失的具体原因是什么。在模型的建立过程中充分利用了 StarRocks 的跨表查询的能力，能够根据用户ID以及一些时间参数，对6个不同节点上反馈的数据进行串联，最终生成大宽表来支持模型的建立。

#05

未来展望

5.1 StarRocks 的优势和展望

StarRocks 的优势包括开箱即用、投入较少、功能强大、覆盖的场景多、架构先进简洁、迭代迅速、支持到位等。

这里重点说一下我们的展望。首先，网易邮箱作为一个历史比较久的业务，有大量的数据存储在一些比较老旧的数据架构里面，如何快速并且低成本的将这些数据迁移到 StarRocks 平台上，同时能够保证迁移过程中数据的安全稳定，并且不影响正常的数据链路，很希望能够看到 StarRocks 有相应的支持。

其次，对于像AI算法之类的数据挖掘的需求，也希望看到 StarRocks 的支持。

再者，网易邮件里面存储了很多图片文件视频等非结构化的内容，如果要把它们全部迁移到 StarRocks 存储系统里面来，也希望能有一个类似数据湖的解决方案。

最后，在可视化工具方面，也希望能够看到 StarRocks 的有力支持。

5.2 总结

网易邮箱从21年开始接触 StarRocks，到现在一年多的时间里，作为一个刚刚崭露头角的 OLAP 系统，StarRocks 在各方面的表现都很不错，它在功能、性能以及覆盖的场景方面的表现，都让我们相当满意，甚至超出了我们当初的预期。

后续网易邮箱会上线更多基于 StarRocks 的业务应用，同时也会在网易集团内部推广，希望能够得到厂商更有力的支持。

希望在厂商的不断努力，以及 StarRocks 开源之后的用户反馈和积极参与下，StarRocks 能够实现更进一步的能力发挥。最后也借此机会再次感谢镜舟公司对于网易邮箱在大数据开发方面的最体贴最有力的支持，谢谢大家！

• 关于 StarRocks

StarRocks 是数据分析新范式的开创者、新标准的领导者。面世三年来，StarRocks 一直专注打造世界顶级的新一代极速全场景 MPP 数据库，帮助企业建立“极速统一”的数据分析新范式，是实现数字化转型和降本增效的关键基础设施。

StarRocks 持续突破既有框架，以技术创新全面驱动用户业务发展。当前全球超过 200 家市值 70 亿元以上的头部企业都在基于 StarRocks 构建新一代数据分析能力，包括腾讯、携程、平安银行、中原银行、中信建投、招商证券、众安保险、大润发、百草味、顺丰、京东物流、TCL、OPPO 等，并与全球云计算领导者亚马逊云、阿里云、腾讯云等达成战略合作伙伴。

拥抱开源，StarRocks 全球开源社区飞速成长。截至 2022 年底，已有超过 200 位贡献者，社群用户近万人，吸引几十家国内外行业头部企业参与共建。项目在 GitHub 星数已超 3800 个，成为年度开源热力值增速第一的项目，市场渗透率跻身中国前十名。