QCon思考之通过Quora和Spotify案例,直击数据处理背后的魅影

简介:

有的同学很困惑米国人不看知乎怎么知道那么多知识呢?米国人当然看Quora啦,Quora是一个问答社交软件,问答社交的特点就是有各种各样的计数器,比如帖子的支持、反对、评论数量,用户的关注、粉丝数量等等,随着用户量的增加、帖子的增多、以及带来的互动的增长,Quora处理的数据也是爆炸式增长。Quora从第一天开始就长在云上(AWS),生产环境使用MySQL和HBase做存储,使用RefShift和Spark用来做数据分析,在这些组件的基础上Quora做了一个数据服务叫Quanta,Quanta的设计约束是:

A:数据更新之后不能丢失,要求持久化到disk

B:有billion级别的counter,单机放不下,所以需要分布式集群

C:每秒写>10W次,每秒读>100W次,只能用追加写

D:读写都要很快

E:资源和负载能够线性扩展,而且能够扩展到目前负载的50倍

F:成本越低越好

 

Quora还有很多基于时间序列数据计算,比如:

A:过去T时间内发生了什么,基于滑动窗口

B:过去Y时间内每隔X该事件发生了多少次,需要访问历史存储数据

C:X和Y可以是任意的

 

还有比较复杂的计算是关系图引入的多层聚合,如:

对于图有两种计算方式,一种是lazy update,只更新单个节点,关联节点在有读操作发生时再触发,一种是eager update,每次update都触发整个关联图的更新,Quora最终采用的是eager update,理由是:每次读的时候都去做一次更新会加大延迟,不可接受;更新即使慢也没关系,因为是异步的;图更新比起读操作还是极少的。当然有向无环图DAG有多种形状,有线性的、菱形的,每种图上的counter更新算法也略有不同,不再赘述。

 

整个Quora的架构大概是这样子的:

客户端写日志到一个journal系统,数据处理Processor从journal系统不停pull数据然后分别更新图和counter存储服务,客户端从counter服务读数据,写操作是追加数据到journal服务,update操作是以thrift message的形式来封装的,所以可以支持各种各样的client;Processor是stateless的异步服务,可以批量读取数据并做处理;counter存储服务用的是HBase,理由是每个计数都可以利用column family字段来保存若干个时间窗口的数据,比如一天的、一周的等等,而且schema还可以随时改变,当设置TTL的时候数据还可以自动过期,吞吐量也足够大;图服务用的也是HBase,每一个row就是图的一个edge,column family存储的是入边和出边,而且通过设置bloom filter还可以实现negative查询,这些模型都比较适合图运算。

目前存在的问题是当Processor处理update数据的时候可能会存在两个job处理同一个图的不同vertex的问题,Quora对这个问题的解法也比较巧妙,就是通过简单的算法将整个连通图隔离出来,这个子图中的所有节点都只会在一个job中去运算,这样就解决了冲突的问题。

总结下来Quora将数据做了很好的model,主要分为两大类,有计数的、有图的,然后对两类数据分治处理,尤其是在处理图数据的时候通过将图分割来解除依赖,所以不需要加锁,极大提升了并行度;对系统也做了很好的设计,比如写和更新解耦、更新可弹性伸缩、存储采用HBase更为灵活,当然前提是要对业务有深度思考并对约束有清晰的判断。

 

接下来的案例是Spotify,Spotify的问题是成长太快,在流量和用户快速增长的时候,系统服务依赖也成指数级别增长,由于整个架构缺乏体系的思考和设计,所以在服务多了之后就出了一系列的问题,如隔三差五的小故障、Hadoop挂掉、数据重复处理、很多数据流水线上的bug无法追查等等,针对这些问题,Spotify做了一系列的改造。

首先是先暴露问题,做早期报警,然后做了一个有领域编程语言支持的监控工具Datamon,Datamon不仅仅做报警,更重要的是对数据的所有权进行了划分,这是一个比较大的进步,报警大家都会做,但是把报警发给谁是一个更有挑战的问题;针对调度和计算不好debug的问题做了一套叫Styx的服务,Styx的每一个job都用docker来做隔离,也暴露了更多的debug信息出来,易用性上也比之前有很大提升,具体实现细节没有多讲;最后一步为了实现弹性扩缩容利用Kubernetes做了一套系统叫GABO,不再赘述。

从Spotify这个例子可以看出如果一个架构师或者CTO没有从体系上和整体架构上去思考问题,业务发展越快跪得越快,给飞机换轮子听着很英勇但是能避免的还是尽量提前避免。

通过上面这两个例子我们也能看出无论目前有了什么样的工具、多么牛逼的产品,定义问题、提炼需求、确定问题边界反而比直接去写代码更有价值,这才是我们的核心竞争力,这些技能也就是我们平时所倡导的调研和思考,用在思考上的时间多了用在擦屁股上的时间也就少了,与君共勉。


来源:中生代技术

原文链接


相关文章
|
运维 负载均衡 网络协议
从底层技术来看,GSLB 究竟难在哪儿
本文作者吕宏利来自硅谷的SRE,有着多年的国内外大型互联网公司运维开发经验,专注于分布式系统设计、监控、容量规划,数据中心技术以及生产环境的最佳实践。在本文中他将他将向读者介绍什么是GSLB,以及实现细节和维护方法。
9214 0
|
Java 应用服务中间件 持续交付
Docker+Jenkins+Gitee+Maven构建自动化部署
Docker+Jenkins+Gitee+Maven构建自动化部署
921 0
Docker+Jenkins+Gitee+Maven构建自动化部署
|
移动开发 前端开发 JavaScript
详细说明前端和后端限制文件大小的具体实现方式
详细说明前端和后端限制文件大小的具体实现方式
864 1
|
JSON Java 数据安全/隐私保护
一篇文章讲明白Java第三方支付接入案例(支付宝)
一篇文章讲明白Java第三方支付接入案例(支付宝)
745 0
|
存储 运维 DataWorks
淘系数据模型治理最佳实践
本次分享题目为淘系数据模型治理,主要介绍过去一年淘系数据治理工作的一些总结。
2070 0
|
架构师 机器人 Java
测试理论-软件测试理论基础
软件测试的IEEE定义:使用人工或自动的手段来运行或测量软件系统的过程,目的是检验软件系统是否满足规定的需求,并找出与预期结果之间的差异。
499 2
测试理论-软件测试理论基础
|
人工智能 自然语言处理 达摩院
构建从智能质检到对话分析的一体化智能对话分析平台 ,杭州银行客服中心打造智慧运营新名片
杭州银行客服中心运用智能技术改变传统人工作业方式、提升智慧运营管理水平成为客服中心沉淀数据能力、实现业务敏捷赋能的重要突破口。
构建从智能质检到对话分析的一体化智能对话分析平台 ,杭州银行客服中心打造智慧运营新名片
|
机器学习/深度学习 人工智能 缓存
|
机器学习/深度学习 数据采集 人工智能
中科大提出统一输入过滤框架InFi:首次理论分析可过滤性,支持全数据模态
中科大提出统一输入过滤框架InFi:首次理论分析可过滤性,支持全数据模态
432 0
|
数据可视化 Python
sklearn之XGBModel:XGBModel之feature_importances_、plot_importance的简介、使用方法之详细攻略
sklearn之XGBModel:XGBModel之feature_importances_、plot_importance的简介、使用方法之详细攻略