首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >以朋友圈为例,腾讯资深架构师揭秘鹅厂大数据平台是怎样运营的

以朋友圈为例,腾讯资深架构师揭秘鹅厂大数据平台是怎样运营的

作者头像
IT阅读排行榜
发布2018-09-29 11:16:14
1.2K0
发布2018-09-29 11:16:14
举报
文章被收录于专栏:华章科技华章科技

导读:本文将从构成运营成本的主要运营资源(设备资源、带宽资源、专线资源)出发,以实际案例分别阐述精细化技术运营实施的要点。

需要提醒注意的是:精细化技术运营的目标是创造价值,而不是为了摧毁价值。精细化提升要注意把握度,切忌为了精细化而过于精细,掉入到钻牛角尖的地步,反而可能导致得不偿失。对于价值增加没有帮助的精细化工作要大刀阔斧地砍掉。

作者:熊普江

2015年7月22日,微信朋友圈图片显示出现了“清帐”问题:即图片都不能正常显示,取而代之的是显示一个粉色图片,上面列有「清账」两字。虽然故障持续的时间只有短短几分钟,但影响面却十分之广,引发各种猜想。著名自媒体作者Fenng在公众号“小道消息”文章《微信居然也会缺少服务器资源,你信么?》也提出该问题的讨论。

问题产生的原因确认是少数服务器升级所致,但也反映出设备资源对业务的支撑十分重要,而且运营的精细化还没有做得足够好。如何保障业务发展需要,保障用户体验,同时又充分利用好资源,控制好运营成本,是设备资源精细技术运营需要持续探索的关键。

01 设备资源精细化技术运营要点

设备资源精细化技术运营的方法论与要点。这里简要回顾一下:

第一步:明确业务运行时的主要设备资源瓶颈所在

第二步:使用性价比最合适的服务器硬件机型来适配

第三步:从以下精细化技术运营评估点上逐个检查评估:

  • 是否可减少不合理/不必要的调用请求量
  • 是否可优化减少调用层级或减少调用放大
  • 分配到服务器上的调用请求是否均匀
  • 是否可使用缓存减少后端数据层的存储访问
  • 架构上是否使用了异步调用或协程访问
  • 网络协议是否恰当
  • 网络收发包量是否合理
  • 操作系统或内核参数是否已做优化
  • 数据存储的内容、格式/编码、份数是否合理
  • 数据访问是否存在冷热

第四步:从管理策略与措施上进行提升,包括:

  • 是否可使用新服务区或长尾服务区进行业务新上线或下线管理
  • 容灾备份系统或区域可否用于跑离线业务
  • 资源供给能力是否可进一步提升,降低容量的水位线

我们将通过多个业务实际案例来阐述上述设备资源精细化技术优化的应用。

02 微信消息

微信收发消息是微信产品的核心业务,也是使用设备资源量的头部业务,因此对该业务功能的技术运营,具有重要价值。我们主要针对三个方面精细化:调用关系复杂、请求分布不均,资源使用瓶颈不一。

1. 调用关系复杂

为什么说调用关系非常复杂?微信消息收发分为两种情形,单聊与群聊。单聊指的是用户A和用户B之间发消息,群聊是单用户在群里面对N个用户发消息。我们看相对简单的收发单聊消息过程(见下图)。

▲微信单聊消息发送微模块

单聊实际上有9个以上的步骤:发一条消息,系统在后台处理要处理9次以上。消息连接接入,发送消息的逻辑模块,逻辑模块之后鉴权(帐号存在与否、帐号属性是否正常)、安全检查(是否垃圾、是否有害等)、收消息人检查(通信地址本)、生成消息序列号(确认不丢消息及消息有序拉取)、存储消息体、发送消息通知、收取新消息等。可见调用关系是非常复杂的。

因此,我们针对复杂的调用关系逻辑进行了优化,包括:调整RPC接口与后台数据存储,合并RPC调用;减少调用层次,缩减模块;逻辑层引入强一致性缓存,减少account/attr等模块持久数据的RPC访问;分离冷热数据,减少对冷数据的RPC访问等等。这些精细技术优化在2014年实施时,节省的设备量超过400台。

2. 请求分布不均

微信消息是多机集群处理的,如果负载不均的话,有些机器达到瓶颈时,有些机却还很空,需要将请求均衡的分布到机器上面。例如:消息的KV存储由按分号段存储改为一致性hash,使得每机性能更均匀:原来是按号段存储每机的负载很不均匀,而扩容是按最大负载的机器去扩容的;有些服务是串行处理的,例如优化容灾架构,使用异步队列进行IO优化。这些精细的技术优化在2014年节省设备近500台。

3. 资源使用瓶颈不一

消息业务的每个key都放内存,海量key致使需多台服务器来存放数据,显然这些服务器的资源瓶颈在内存上;适当将冷数据的key落地到磁盘上,可以缩小内存容量;同时考虑零散碎小模块可以合并一起,使资源充分使用;而合并在一起存储,就需要技术方法解决某个业务突变引起扩容。

另外,有些业务模块则资源瓶颈的CPU或磁盘存储上,甚至在不同的时间消耗的资源量不同,可以考虑资源混合与错峰调度。

解决资源使用瓶颈及错峰调度,2014年微信优化中节省服务器超过250台。

4. 其他的优化措施

操作系统优化及RPC框架性能改进。如原来微信服务器的操作系统层面单机性能比较差,每台机器只能处理不到100万左右的消息调用量,使用tlinux大幅将单机性能提升到近200万。微信单机性能改进的优化于2014年中节省设备超过3000台。

服务器的容量管理,优化容量水位,提升快速扩缩容能力。

新业务服务区及长尾服务区的管理优化。设定业务进入或迁出新服务区或长尾服务区的请求调用量阀值标准。

03 朋友圈

朋友圈是微信里最为重要功能之一,帮助用户向好友展示自己的想法与最近状况,同时便于用户了解好友的状态、评论或点赞。朋友圈与收藏很相似,用户数据也是永久保存,不会删除。

朋友圈的产品形态很特别。细心的读者会发现,用户发一条朋友圈,实际上是先在用户自己个人相册里面存一条记录数据;但同时会往该时刻、允许查看其朋友圈且未屏蔽该用户的好友时间线上插一条索引数据。

▲朋友圈时间线与个人相册

也就是说朋友圈有两个功能点:

  • 看所有自己发的朋友圈记录,就是个人相册,保存了自第1条朋友圈以来的所有朋友圈消息记录。访问的频率相对不高,但这部分存储数据,用户一般很少删除,它是持续增长的,这个存储量是巨大的。
  • 我们平时刷朋友圈,即朋友圈信息流,按时间倒序,列出某个时刻,好友发了一条状态信息(文字、图片、视频、图文等),这就是时间线。只存放2000条索引记录,存储所需空间不会有太大变化,但用户访问频率高,经常被刷新访问。用户如果要看2000条以外的好友朋友圈消息,只能点开到某个好友的个人相册才能看了。

朋友圈每天上传图片请求近10亿次,上传视频请求近1亿次。数据访问超过5000亿次/天,单机峰值访问超过120万次/分钟。为确保数据可靠性与良好体验,会存储多个规格及存储份数。因此,朋友圈的存储体量及访问量是非常大的,而且是永久保存,随时间推移,只会增不会少。这就有一个问题,如果都使用高性能存储来服务用户的话,服务器资源成本将会是天量。

技术运营团队跟踪运营数据发现,用户看朋友圈的时候,访问一天之内发的朋友圈内容,大约占了70%,一天之外内容被访问次数大幅减少,当前1天之内的朋友圈内容存储量只占总朋友圈存储量的0.3%。90%以上的访问请求的数据都在1个月以内,当前1个月之内的朋友圈内容存储占总朋友圈存储量的6.5%。

也就是说,朋友圈业务呈现访问量大、数据冷热非常分明的特点。需要将考虑将数据分成热数据集群与冷数据集群,而且基本可以确定,热数据集群的增长不会太明显,增长主要在冷数据集群上。热数据集群我们就用性能最好的设备,让大家可以很快速访问到所需的内容与数据;冷数据集群就使用价格低廉的多的大容量存储设备。从架构上,除要支持按时间序列进行冷热数据的迁移转换,还需要支持用户访问的转换。最终重新优化实现新的朋友圈数据冷热分离存储架构,如下图:

▲朋友圈冷热分享架构示意图

这里的热数据集群,使用高性能SSD存储机型TS8/TS80;冷数据集群使用高存储量的SATA存储机型TS6/TS60。

其中TS8/80 使用SSD盘,作RAID5的情况下,最大存储量为2.4T,极限随机iops可达到50000次,TB访问量可达到2w次/s。

TS6/TS60使用机械SATA盘,每台机器12块,单块盘容量为2T,测试并发情况下极限iops不到200次。No Raid情况下总容量为24T,极限随机iops为2000次。TB访问量为100次/s。

单台TS6/TS60硬件的成本约为TS8/TS80的70%。但定义TB存储成本为每TB数据存储对应的硬件价格,则可知在磁盘完全利用的情况下,TS6/TS60的TB存储成本仅为TS8/TS80的7%。满足iops要求,磁盘不能完全利用情况下,TS6的TB存储成本为TS8的15%。也就是说,冷热集群的存储成本,可节约85%的成本。

冷热集群架构上,还有很多细节的技术优化点:如满足时间序列的热数据存储结构优化(采用LSM Tree算法);满足冷数据平行扩容的冷数据存储结构优化(采用单点串行写入的一致性模型)等等。

04 大数据平台管理

现在一般上规模的公司,都会建立公司统一的大数据平台。腾讯也不例外,数据平台部建有超大规模的数据处理集群平台TDW(Tencent distributed Data Warehouse:数据仓库),包括实时计算、离线计算等等,用于全公司的数据实时处理、离线分析、个性化推荐、业务计费等。

由于移动互联网的发展,数据呈现爆炸性增长,同样腾讯的TDW集群规模也迅猛增长。目前TDW单一集群能力已达2万台。数据处理平台的管理与利用,成为业务发展与成本优化管控的巨大挑战。

大数据平台的管理分为计算单元与存储单元的管理。2016年以前,腾讯TDW集群从CPU利用率上看,平均达85%。集群存储数据中,3个月内数据占比56%,6个月内数据占比70%,12个月以上占比16%;集群计算使用数据,73%为1个月内数据,92%为3个月内数据,12个月以上占比约2%。

在精细化运营方面,技术运营团队实施的措施有:

首先定义了沉默数据。沉默数据是指一定时间周期内未被访问的数据。如2015年8月,腾讯TDW中3个月以上至1年的沉默数据有25PB,1年以上的沉默数据有14PB。

其次,技术运营团队强化了数据存储的生命周期管理。管理规定要求:所有业务申请接入TDW的数据时,都需要填报“数据存储周期”。通过生命周期管理及沉默数据差异化存储,2015年前8个月仅增长23%的存储量(见下图)。

▲数据平台强化存储生命周期管理

再次,通过监控大任务效率及清理无价值任务对计算单元进行优化。对于执行时间长、扫描数据量大的任务,实施主动监控并及时通知业务进行优化,必要时进行主动清理,确保平台计算单元合理利用。在业务层面,清理两类无价值任务:长期失败任务与长期计算结果为空的任务(见下表):

无价值计算任务

定义及描述

长期失败任务

两周内失败超过7次

长期计算结果为空任务

入库、计算、出库任务连续10个周期的计算结果为空

独立计算

不依赖入库或其它计算任务且计算结果无其它任务依赖,计算结果不出库

无价值计算

数据入库后没有被访问,或计算结果出库后没有被访问

▲无价值任务说明

在2015年前8个月时间内,通过监控大任务效率及清理前两类无价值任务(18398个),已优化计算单元超过800个(见下图)。

▲清理无价值任务个数

对于计算单元的管理,除了无价值计算外,可以通过类似于域名管理的方法来监测计算任务的有效性。即:

  • 业务每申请增加一个计算任务,需要注明:用途、有效期(默认为6个月或1年)、主要责任人(任务开发人)、次要责任人(产品或运维)。
  • 任务到期前一个月或一周,提醒主要责任人renew(续期)或放弃(删除)任务。
  • 任务到期后一个月为赎回期,任务继续运行,但每天提醒主要责任人及次要责任人。
  • 任务过期一个月仍不续期,该任务将暂停执行。
  • 任务过期3个月,该任务将物理删除。

关于作者:熊普江,腾讯公司布道师、腾讯云高级总监,负责公司云技术、解决方案布道及技术架构评审等工作。自1997年涉足互联网,曾服务美国Supreme、太平洋网络、PPTV等互联网公司,任网络运营总监、运维总监等职务。逾20年互联网从业背景,对大型网络架构规划与建设、海量用户平台规划与运营技术支持、超大规模业务资源规划与技术架构管理优化有丰富的经验。

本文摘编自《技术运营》,大数据(ID:hzdashuju)经出版方授权发布,如需转载联系我们。

延伸阅读《技术运营》

点击上图了解及购买

转载请联系微信:togo-maruko

推荐语:由腾讯资深架构师熊普江携手海尔电器集团CTO盛国军共同打造!详细阐述技术运营的精细化方法及具体实施步骤,披露大量真实案例!多位知名架构师联袂推荐!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-08-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 大数据DT 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档