作者：网易邮箱 黄贤康。现任职网易邮件事业部资深数据开发工程师，作为次要开发人员参加网易邮箱大数据平台的建设、优化、重构等工作，并获得相当的功效。他长期从事服务端利用及大数据畛域的架构研发工作，对相干畛域的底层架构、开发流程及技术细节等都有肯定积攒。
（本文为作者在 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 个不同的数据需要。
- 数据的落盘存储。
- 基于存储之后的数据，在 T+1 的工夫窗口进行数据的统计，最终生成 OKR 指标，输入到上游的数据报表零碎。
- 实时的用户登录，咱们要求进行一些监控，来保障用户的敏感行为可能主动聚合叠加，达到肯定阈值之后，触发一些风控解决。
- 针对须要实时查问的数据，提供一个查问接口，供上游业务调用。
以上 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 个，成为年度开源热力值增速第一的我的项目，市场渗透率跻身中国前十名。