草庐IT

网易邮箱数仓演进之路

张睿 2023-03-28 原文
本文介绍了网易邮箱数仓的演进过程和期间一些关键的技术方案引入决策,并阐述了这些决策背后的业务需求和技术考虑因素,以及实施后的实际产出成效。最后对整个过程进行了总结及后续展望。

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引擎层面的存算分离和资源隔离机制;
  • 为了应对业务领域拓展可能会带来的不同的数据分析模式,还需要考虑湖仓一体和简化、加速数据湖分析的方案。
本次的分享就到这里,谢谢大家。

有关网易邮箱数仓演进之路的更多相关文章

  1. 焕新古文化传承之路,AI为古彝文识别赋能 - 2

    目录1古彝文与古典保护2古文识别的挑战2.1西文与汉文OCR2.2古彝文识别难点3合合信息:古彝文保护新思路3.1图像矫正3.2图像增强3.3语义理解3.4工程技巧4总结1古彝文与古典保护彝文指的是云南、贵州、四川等地的彝族人使用的文字,区别于现代意义上的彝文,古彝文指的是在民间流通使用的原生态彝文,多达87046字。古彝文的起源距今至少数千年,是世界上最古老的文字之一。对古彝文字集研究有助于理解尚未被翻译成汉文、用字尚未规范化的古籍,更深层、透彻地作用于传统文化保护。古彝文字义对照图(网络资料+邵文苑供图)古籍是不可再生的宝贵资源,应当得到妥善保护。中国的古籍在历史上迭经水火兵燹等自然灾害、

  2. 【思考】聊聊低代码的实践之路 - 2

    文章目录背景一、最初的疑惑二、简单聊聊原理三、组织内实践案例四、实践带来的反思五、最后聊几句问题背景这个概念由来已久,但是在国内兴起,是最近几年;低代码即Low-Code;指提供可视化开发环境,可以用来创建和管理软件应用;简单的说就是可以通过各种组件的拖拽,实现页面的创建,交互流程和逻辑,以及数据层面的管理,更加高效的实现需求;早先在数据公司时;见识过低代码的应用,也参与过部分研发,比如元数据平台,BI分析等;不过,当时还是以数据管理的工具来定义项目,并非是低代码;从「2020年底」开始;实际上,那个时间节点,低代码平台的应用已经形成趋势了;现在的公司,将低代码平台的使用规划到业务体系中;后来

  3. 「前端代码简洁之路」后台系统之详情页设计 - 2

    一、乱花迷人眼我就是被迷的那双眼。有时候需求来了,用熟悉的套路进行开发,确实很节省时间也能保证功能的稳定,但是这些开发的惯性无形中阻碍了我对技术的探索。我一直想改造详情页,解放重复功能开发的劳动力,但是详情页一眼望都是内容平铺,好像并没有什么可做的代码设计。后来我拨开繁花,发现详情页的组件化不必想的过于复杂,后台系统风格统一即可。因为大部分的详情页面是内容的展示,偶尔会出现少量的操作功能。将风格统一的部分进行组件化处理,操作功能使用回调函数放回当前页面,避免组件里做过多的业务逻辑。看,这不就成了。项目基于React框架开发的,所以代码写法是JSX语法,组件开发使用的hooks函数式组件,UI框

  4. 奇舞周刊第486期:ChatGPT 的狂飙之路 - 2

    记得点击文章末尾的“ 阅读原文 ”查看哟~下面先一起看下本期周刊 摘要 吧~奇舞推荐■■■ ChatGPT的狂飙之路最近随着ChatGPT爆火出圈,网络上各种关于ChatGPT的争论声也不断;有些人把它当成一个更高级的聊天机器人,有人兴奋地看到了创业的风口,而另一些人对它取代人类的工作露出了不少担忧;那么它到底是推动社会不断前进的工具,还是妄图颠覆人类社会的T-1000?本文我们来深入的探讨一下ChatGPT的那些事。 带你看看前端生态圈的技术趋势今年的state-of-css调查共回收了14310份问卷结果,state-of-js调查共回收了39472份问卷结果,希望各位能在这些数据和分析中

  5. 云计算学习之路——LVS负载均衡 - 2

    LVS文章目录LVS一、负载均衡集群介绍1、集群是什么?2、负载均衡集群技术3、负载均衡集群技术实现方式和产品4、负载均衡实现效果图5、负载均衡分类6、四层负载均衡与七层负载均衡的区别二、LVS介绍三、LVS工作模式1、LVS负载均衡的四种工作模式2、四种工作模式的原理、优缺点3、四种工作模式的区别四、LVS管理工具——ipvsadm五、LVS负载均衡集群实战应用1、环境:2、搭建web服务器3、LVS负载均衡配置4、验证六、LVS的调度算法1、静态算法2、动态算法七、LVS健康监测脚本一、负载均衡集群介绍1、集群是什么?集群技术是一种较新的技术,可以在付出较低成本的情况下获得在性能、可靠性、

  6. ChatGPT原理与技术演进剖析 - 2

    ——要抓住一个风口,你得先了解这个风口的内核究竟是什么。本文作者:黄佳(著有《零基础学机器学习》《数据分析咖哥十话》)ChatGPT相关文章已经铺天盖地,剖析(现阶段或者只能说揣测)其底层原理的优秀文章也已经出现,其中就包括爱丁堡大学符尧博士的文章:HowdoesGPTObtainitsAbility?TracingEmergentAbilitiesofLanguageModelstotheirSources以及AlanD.Thompson博士的文章:GPT-3.5+ChatGPT:Anillustratedoverview。再继续等待OpenAI发表ChatGPT的官方论文之前,我也谈谈自己

  7. 【宝塔面板部署nodeJs项目】网易云nodeJs部署在云服务器上,保姆级教程,写网易云接口用自己的接口不受制于人 - 2

    看了很多部署的,要么少步骤,要么就是写的太简洁,对新手不友好文章目录前言一、下载网易云nodejs项目1.gitclone下载,两种方式2.运行项目二、使用步骤1.先在本地运行2.测试接口三、部署服务器1.在宝塔面板安装pm2管理器2.压缩网易云nodeJs项目,上传到宝塔面板3.添加一个nodeJs项目4.填入参数5.放开防火墙,宝塔面板+服务器后台面板6.测试接口总结前言参考链接网易云音乐API安装及部署全过程【本地跑项目以及远端部署均详解】服务器如何上线node.js项目【项目放置在github中】宝塔部署nodejs项目参考多篇文章,主要为上3篇,才总结本篇提示:这里可以添加本文要记录

  8. 网易音乐网站系统|前后端分离springboot+vue实现在线音乐网站 - 2

    作者主页:编程千纸鹤作者简介:Java、前端、Python开发多年,做过高程,项目经理,架构师主要内容:Java项目开发、毕业设计开发、面试技术整理、最新技术分享收藏点赞不迷路 关注作者有好处文末获得源码项目编号:BS-PT-104前言:网易音乐网站系统是一个在线的音乐网站,普通用户通过注册的账号进行登录并且进入客户端首页,用户使用鼠标点击某音乐进行收听播放,网站提供个人空间,用户可以把喜欢的歌曲进行收藏,以便于之后反复收听。用户平台还提供歌曲评价功能,对喜欢与不喜欢的歌曲进行打分和评论,管理员用户通过账户登录可以对音乐网站的基本数据进行管理,如音乐数据,用户数据等,还可以通过后台的数据展示来

  9. 【JavaScript速成之路】一文带你掌握DOM基础 - 2

    📃个人主页:「小杨」的csdn博客🔥系列专栏:【JavaScript速成之路】🐳希望大家多多支持🥰一起进步呀!文章目录前言1,WebAPI简介1.1,初识WebAPI1.2,WebAPI与API的关系2,DOM简介2.1,DOM概述2.2,DOM树3,元素获取3.1,根据id获取元素3.2,根据标签获取元素3.3,根据name获取元素3.4,HTML5新增获取元素3.5,document对象的属性4,事件基础4.1,事件概述4.2,事件三要素5,元素操作5.1,元素内容操作5.2,元素属性操作5.3,元素样式操作6,属性操作6.1,属性值获取6.2,属性值设置6.3,属性值移除7,自定义属性7

  10. 小程序开发第一天 项目基本结构和组件概述 大龄java程序员转行之路 - 2

    pages文件夹page翻译为页面,就是说微信小程序里包含的页面都放在这个文件夹里。类比我们常见的index主页面,login登录页面,这些web页面文件夹转化在微信小程序中就是pages页面。用户创建的文件夹就是index,login等页面文件官方建议把小程序的页面都放在pages我文件夹中,每个文件夹里都有四个文件,分别是。.js文件控制页面的脚本文件,包括存放数据,业务逻辑,事件处理函数等调用Pages()函数实现对页面的调用.json文件这个页面自己的配置文件,管理窗口外观,表现等.wxml相当于html文件,就是存放页面的模板结构wxml是一种类似于html的标签语言,是由微信自己创

随机推荐