本文介绍了网易邮箱数仓的演进过程和期间一些关键的技术方案引入决策，并阐述了这些决策背后的业务需求和技术考虑因素，以及实施后的实际产出成效。最后对整个过程进行了总结及后续展望。
1 概述
到目前为止，网易邮箱数仓的发展大致经历了三个阶段：
第一个阶段是2020年10月份之前，这时候我们的数据系统的主要任务是支持邮箱日常的运营统计；
第二个阶段大概是2020年11月份到2021年的11月份，这段期间公司尝试做业务的调整，挖掘新的长期增长方向。我们在这时候对邮箱数仓底层的OLAP引擎和整个数据处理链路都进行了重构，以适应业务方宽泛的即席数据探索需求；
第三个阶段大概是2021年的12月份到现在，我们进入了精细化运营探索期。这个时期我们的主要工作是完善数仓结构，满足更多、更深入的数据应用需求。
可以看到，由于每个时期面临的主要问题不同，前两个阶段切换的主题在于重建基础设施，而后两个阶段切换的主题则是完善上层建筑。
2 初始状态
早期的网易邮箱数仓底层是一套完整的Hadoop体系结构，它的组件构成比较庞杂。但后期它完成的主要任务就是从贴源层计算统计结果到应用层，用作BI报表展示。
有一组数据能够反映2020年10月份之前这个系统的状态：整个集群大概有300个节点，存了9P+的数据，其中小文件众多，导致元数据条目有6亿+，这个元数据规模让HDFS的NameNode不堪重负，2次崩溃。其中第二次崩溃导致邮箱所有的数据统计任务停了整整1周多的时间，这也是导致我们下决心后续对数仓进行升级改造的直接原因。
然而我们当时只有两名数据开发人员，并且没有专职的大数据运维人员。因此，从资源的角度看，我们实际上也是没有条件继续支撑这套体系持续稳定运转的，一次彻底的底层重构势在必行。
根据当时的情况，重构方案在技术层面需要下面考虑三点：
开发效率：因为开发人员少，而基于MR框架的开发效率比较低，我们需要一个使用成本更低、效率更高的开发平台；
系统性能：老系统的任务执行效率较低（尤其是逻辑较复杂的长周期统计任务），新方案应该要在大规模数据集下有更好的查询性能；
运维效率：因为缺少专职的数据运维，我们需要架构相对简单，维护难度相对低的技术选型。
另外，在业务层面，当时我们的产品和运营侧都还在新方向探索期，对业务指标间的关联性了解不足，没有形成稳定的观察指标体系。具体的症状就是这两个：
“不知道要什么”：当你问业务方：“最想要看哪些指标？”，结果通常都是说不上来，不知道哪些指标和用户、会员等核心指标的提升关联度大；
“什么都要”：当业务方提需求的时候就是：什么都要。各种业务过程的不同维度、不同粒度下的指标都要看。
如果在这个时期就去构建完整的多层数仓结构，预先做好多维度的聚合指标，很容易变成无用功，最后要推倒重来。实际上业务侧这时候最需要的是在明细事实数据层面的高性能的ad-hoc查询能力，并且最好更够支持他们进行自助的数据探索。
3 数仓1.0
于是经过综合考虑，我们从2020年底到2021年中逐步做了下面几个工作：
第一个是将旧Hadoop集群的数据进行压缩、清理后，迁移到新搭建的猛犸Hadoop集群（规模小了很多），成为新数仓的ODS层，向上层提供原始数据输入；
第二个是选型、引入了以数据查询和写入性能著称的OLAP引擎ClickHouse（下文简称CK），作为新数仓的DWD层，支持应用侧以SQL的形式查询、挖掘事实数据；
第三个是基于Kafka和Flink搭建了一套新的、支持实时数据采集的数据处理链路，为CK输入清洗后的事实数据。
这套框架搭建完之后带来下面几个方面的好处：
（1）在开发层面
统一用SQL进行数据需求的开发，降低了开发难度，也便于形成统一的开发规范；
降低了业务侧自助查询的门槛，让运营、QA、前后端开发等职能可以自己实现数据统计任务和报表产出，相当于增加了数据开发的人力（这点对我们来说很重要，它让我们能够在人力资源这么紧张的情况下，还能腾出手来，在数仓的外延去补充数据中台的一些能力）；
实现了高效的数据接入流程。
（2）在业务提效层面
CK具有很高的单表查询和写入性能，提升了数据需求实现的效率；
依靠强大的基础性能，CK可以覆盖从T+1的运营统计到准实时的服务质量基线统计需求。
（3）在运维层面
尽管CK自身也有在扩容等方面的维护难点，但整体上相比Hadoop技术栈的组件要少，部署结构相对简单；
另外CK在数据压缩后仍能维持较好的查询性能，有助于我们控制存储规模。
在新数仓上线后，我们取得了比较显著的业务和技术成效。比如在业务支撑方面，业务侧自助取数占比从0提升到了80%以上，平均取数时长从天级缩短至分钟级，当时的业务指标覆盖度也有了质的提升；在开发层面，统计任务的开发效率、数据查询性能和数据接入效率都成倍地提升；而在运维层面，我们用比之前更少的服务器资源支撑了更高的数据吞吐量，同时系统可用性还得到了提升。
看上去我们已经很好地支撑了当时的业务需求，为什么还要继续折腾呢？
因为业务会成长。随着各项运营目标的推进，大家总算是形成了一些相对稳定的业务观察指标了，但观察了一段时间之后的结论就是：很多关键业务指标的增长都出现了瓶颈。而同时在降本增效的趋势下，运营触达行为的转化率要求也提升了。
实际上是业务增长现在需要更精细化的运营策略了，而这时候我们的系统能力就逐渐和新的需求演化趋势之间产生了一些失配：
首先是深挖业务增长因素的多维度分析场景增多了，而CK的Join性能优化较弱，或者说对于业务侧同学和数据分析师来说，要写出高效的关联查询SQL的门槛比较高，所以应用复杂的维度建模方法的难度较大（如果都打成CK喜欢的大宽表的模式的话，数据表的复用度低，重复开发量大，数据变更的影响也大）；
第二个是运营策略越来越依赖用户、设备等维度的标签，而标签（尤其是统计数值类标签）是容易发生变更的，而CK对数据热更新的支持不完善，会增加标签维护的成本；
第三个是随着更多数据应用的出现，分析查询的频次提升了，对数仓的并发请求增多，但CK的并发查询支撑能力不强。
所以我们需要对系统进行进一步的能力提升。但从资源、成本以及需求时效性的角度考虑，去改造CK或者等它升级提供所需要的能力和特性显然都不现实。
为了能够在不大规模地改变现有架构的前提下，快速地补充缺失的能力，我们考虑新引入一个能满足这些能力要求的OLAP引擎，并让它主要工作在DWM层，用来承载轻度聚合数据、标签及其他维表，并支撑业务的多维度分析需求。
在这个新数仓的选型上，我们对比了业界多个优秀的OLAP引擎，其中有基于Hadoop生态的方案，也有采用独立研发的存算系统的方案。最终考虑到StarRocks在与现有系统的整合难度、关联查询优化、数据更新支持、并发查询能力和运维成本等方面的均衡表现，决定选择它作为新的选型。
StarRocks实际上是与Doris同源的另外一个开源分支。这背后其实还隐含了另外一个选型因素，就是我们和StarRocks的技术团队在很早之前就建立了联系，他们也在我们的实践过程中提供了很好的技术支持。
4 数仓2.0
于是从2021年年末起，我们按计划引入了StarRocks，并调整了数仓的逻辑结构，从而又带来了一系列提升：
（1）在业务支撑层面
可以支持并发度比较高的多维度分析查询需求；
以较小的开发、维护成本满足了数据应用侧的标签查询需求。
（2）在开发及架构层面
我们让CK和StarRocks工作在了各自擅长的层次。在数据规模比较大的细粒度事实层，数据探索依然可以依赖CK的大宽表模式；而在中间层的开发中我们也能充分利用StarRocks的自动聚合、智能物化视图等这些特性来提升开发效率；
提升通用指标的复用度，减少了重复开发；
降低了对明细层数据的查询压力。
目前，我们StarRocks中存储了40多个标签表，数据量达300多亿条，日均数据更新7亿多次，每天承载的查询量达到了千万级（这里包括了一些在线应用的实时请求）。
在业务成效方面，一些特定的用户标签让定向引流触达活动的点击率平均提升了90%以上；基于数仓中间层的取数系统和画像系统上线以来，累计节省了约10人月的数据开发人力投入；同时标签库也支撑了风控因子库和个性化反垃圾模型的构建。
5 总结
如果用一句话来总结到目前为止的数仓建设过程，那就是：“虽然起步晚，但几乎总是在关键的业务发展节点前补充了与之匹配的能力”。我们从中得到的感触主要有两点：
首先是数据团队应该时刻关注业务的运营状态和数据的产出价值。这是我们跟上业务的发展节奏甚至推动它前进的前提，同时也体现了一种价值取向：就是技术团队的最终产出价值通常不是技术本身，我们的技术活动的终极目标通常也不是技术先进性，而是让业务在残酷的市场竞争中获得生存优势；
其次是数仓建设无法一蹴而就。因为业务需求的演进需要一个过程，而方案的实施又有各种资源和成本上的限制，所以不可能也没有必要从一开始就考虑实现一个大而全的系统。更好的方式可能是提前预判需求的演变趋势，用来做长期的建设规划，但按中短期的能力要求循序渐进地推进。
6 展望
展望未来，邮箱业务会持续发展，甚至会尝试突破业务的领域边界。预计会有更多针对特定领域的数据应用出现。这些应用实际上是把调用数仓算力的门槛降低了，会给数据支撑工作带来更大的压力。
为此我们计划做好以下几件事情：
为了保持数仓系统的健康度，需要完善数据中台的数据治理能力，尤其是通过数据价值评估和数据生命周期管理，有效地控制数仓的热存储中的数据规模；
为了在降本增效的前提下应对不断提升的应用算力需求，需要提升数仓系统的资源利用率和弹性伸缩能力，因此考虑引入OLAP引擎层面的存算分离和资源隔离机制；
为了应对业务领域拓展可能会带来的不同的数据分析模式，还需要考虑湖仓一体和简化、加速数据湖分析的方案。
