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没有从体系上和整体架构上去思考问题,业务发展越快跪得越快,给飞机换轮子听着很英勇但是能避免的还是尽量提前避免。

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

来源:中生代技术

原文链接

时间: 2024-10-30 00:19:33

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

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

编者按:大数据的题目看起来好写,因为大家似乎都懂,但是其实也难写,因为太大了,没有具体的问题很难写出有营养的东西,所以今天选取两个QCon比较典型的例子来管中一窥大数据的魅影.     有的同学很困惑米国人不看知乎怎么知道那么多知识呢?米国人当然看Quora啦,Quora是一个问答社交软件,问答社交的特点就是有各种各样的计数器,比如帖子的支持.反对.评论数量,用户的关注.粉丝数量等等,随着用户量的增加.帖子的增多.以及带来的互动的增长,Quora处理的数据也是爆炸式增长.Quora从第一天开始就

《像计算机科学家一样思考Python》——第4章 案例研究:接口设计 4.1 乌龟世界

第4章 案例研究:接口设计 4.1 乌龟世界 程序包(package)是多个模块的组合:Swampy中有一个模块"乌龟世界"(TurtleWorld),它提供各种函数,可以引导一只乌龟在屏幕上爬行,并画出其踪迹. 系统中安装好了Swampy之后,就可以像下面这样导入TurtleWorld模块: from swampy.TurtleWorld import * 如果你下载了Swampy但并没有安装,则可以在其代码目录中使用,或者将其目录加入到Python的搜索路径中.接下来就可以这样导入

2016美国旧金山QCon序:硅谷加班或是常态 有的晚上8点才有晚餐

    这次会议的全称是2016 San Francisco QCon,顾名思义是在旧金山开的,而旧金山又比较接近硅谷,所以有很多硅谷的公司参加了本次会议并带来了很多有意思的议题,对于公司来说,参加这种会议很有必要,既可以跟上前沿的节奏,也可以从侧面了解硅谷是如何思考问题的.这次集团委派了多个子公司各个技术领域相关的七.八人参与该大会,我也是其中之一.     参会之前拿到了会议三天的所有议程表,从安排篇幅就可以看出今年大会的几个重点:Docker/容器,MicroService/微服务,Jav

优化SQL的另类思考

今天给大家介绍一个SQL优化案例,这是statpack中逻辑读排名第一的SQL.当前创建的索引建在 (username,ends,approve_status,promoted_status)上. 以下是引用片段: Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value ------------- ------------ -------------- ------ -------- --------- -

阿里云机器学习平台的思考

最近读了阿里的<大数据之路-阿里巴巴大数据实践>,对于其机器学习平台也蛮感兴趣,正好阿里出了本新书<解析阿里云机器学习平台>,顺便读了下,感触也不少,结合最近团队机器学习的一些思考,特别在此分享于你. 一.机器学习的门槛降得更低了 这本书的第一章是这么描述阿里云机器学习平台的,"阿里云机器学习平台是构建在阿里云MaxCompute计算平台之上,集数据处理.建模.离网预测.在线预测为一体的机器学习算法平台,用户通过拖曳可视化的操作组件来进行试验,使得没有机器学习背景的工程师

对交互设计师的几点期望

虽然今年名义上已经不再管人了,但也不得不掺和进很多人事,这里想简单说说,即使不能帮助这个行业的从业者规划职业道路,也算是把之前摸过的路小结一下,给大家一个参考. 相关文章:页面重构工程师应该具有的技能和素质 交互,视觉,前端开发,用户研究,其实任何一个岗位,我都喜欢从意愿,能力,潜力这三个方面来说. 先说潜力吧,之前不觉的,现在越来越觉的,做交互是需要一点潜力的.一是逻辑思维的能力,结构化思考,推理假设,即使不需要太严谨,也是需要自己先把逻辑搞合理了,设计出来的东西才能合理.(在设计评审中,经常

CMMI5在项目中的应用

这周,我们的新产品--DM项目正式启动,作为公司参与CMMI5评审的项目.对于我们的team来说,以往基本上没有在流程上做严格的控制,现在以CMMI5的标准来要求项目的实施,一方面可以说是机会与挑战,趁机规范我们的开发.测试流程:另一方面,因为以往没有这方面的实践,一下子要以CMMI5的标准要求我们,实施起来也会有一定的难度.将会有怎样的效果,投入这么多的人力物力是否值得,现在还不好说,且看项目结束后的收效吧. DM这个项目,按我们以往的开发与测试模式,3个月之内会完成所有的工作,虽然测试一般都

如何在用户体验与业务目标之间寻求设计平衡点?

  在设计师眼中,似乎所有与业务.营销相关的东西都是垃圾.首先,它们不是垃圾.其次,就算它们是垃圾,你觉得谁更应该站出来做好清洁工作?你觉得谁更适合于将各种复杂.混乱.差劲的东西梳理清楚,整合成为既能让用户开心又能推动业务发展的表现形式?在很多时候,答案是"设计师". 产品设计的目标在于解决问题.优秀的设计来自于对功能特性及目标实现流程的完美诠释,而非赏心悦目的界面外观. 随着数字化营销理念逐渐深入人心,与公司业务紧密相关的那些部门也争相扮演起产品设计与体验决策者的角色.不得不说,在如

美团数据库运维自动化系统构建之路

美团点评技术沙龙由美团点评技术团队主办,每月一期.每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京.上海和厦门等地举行,要参加下一次最新沙龙活动?赶快关注微信公众号"美团点评技术团队". 本次沙龙主要围绕数据库相关的主题,内容包括美团数据库自动化运维系统构建.点评侧MySQL自动化服务平台RDS.美团数据库中间件.和小米高级DBA带来的Redis Cluster的大规模运维实践. 讲师简介 宁龙,美团网高级DBA,现负责美