番外篇:新鲜上市的 Unicorn - Pinterest 的数据系统

发布于: 11 小时前
番外篇:新鲜上市的Unicorn - Pinterest的数据系统

我是数据库内核杂谈系列的作者。首先和大家道个歉,数据库内核杂谈拖更了。时至年中,工作有点忙,要总结也要计划,另外,北美特别是北加这边疫情也愈发严重,导致心情也沉重了,导致拖更了。新的一期已经在创作了,绝对不会荒废的,今天这期,插播一期番外,是当时Pinterest刚上市时写的博客。

话说为什么会有番外篇呢?上次休假写上一篇数据库杂谈的时候正值Pinterest上市,小葡萄就问了一句“Pinterest上市啦!话说,写了这么多期数据库,那你知道Pinterest用的是什么数据库吗?”。“嗯,that's a very good question! 首先他们需要blah blah blah ...”,我开始一本正经地说... “太多啦,我不要听啦,要不你写一期Pinterest的数据库吧,算是数据库内核杂谈的番外篇?” 这一期,咱们就围绕着Pinterest有哪些数据要存储和处理,来聊聊Pinterest可能会用到的大数据系统。为了写这一期,我翻阅了一系列Pinterest的技术博客外加一些自己的理解。如有不当,欢迎拍砖和指正,尤其是Pinterest的朋友!

用户信息怎么存?

首先,Pinterest有很多用户,得有个系统存储这些用户信息。网上能查到的数字是超过250Million月活(写这篇文章的时候,月活肯定已经超过这个数字了)。用户信息,比如用户名,登陆信息,偏好等等是非常结构化的信息,属于非常典型的关系型数据库应用。那么多用户,你可能会觉得,需要很多台服务器再搭载分布式数据库才能存储。其实,做个简单计算,250M * 10KB(假设每个用户信息存放10KB,我已经很大方啦) = 2.5TB。一台安装关系型数据库(可选用受欢迎的开源数据库MySQL或者Postgres) Amazon x1e.32xlarge 服务器(搭载2块2TB硬盘)就可以勉强存下所有的用户数据啦。存是存下了,那么多用户的请求,一台服务器是否能处理过来呢?对于用户的请求分为读请求和写请求:读请求可以理解为用户登陆,需要确认登陆信息,这类请求的数量巨大;写请求可以理解为新用户注册或者现有用户更改信息。考虑到用户更改信息的频率不会太高以及网站已经比较知名,不太可能再出现短时间内大量新用户注册。而一台MySQL服务器至少能做到100K QPS(我找了很久,也没找到非常靠谱的benchmark,请读者赐教),所以,如果优化得好,一台服务器是勉强可以处理所有写请求的。对于读请求,其实很容易想到,虽然量巨大,但因为数据不变,没必要每次都从数据库读取,完全可以用Memcached或者Redis这类缓存来处理高并发请求。可见,并不是动不动就需要分布式数据库的。当然,我们的计算非常理想主义,完全没有考虑容错,备份,灾难恢复等。在现实情况下,Pinterest肯定会对用户信息做sharding(每个shard数据库只保存一部分用户信息),并且对每个shard还会有replica做备份(也可以用Master-slave模式,master负责处理所有的写请求,slave同步数据并且负责处理所有的读请求)。

Pin - Interest

Pinterest用户当然是来分享和浏览Pin的。Pin的主要格式为图片,动图(gif)或者视频格式。网上查到的数字是超过175Billion个Pin。假设每个Pin的大小是500KB(估算相对保守), 175Billion * 500KB = 87.5PB。OMG!87.5PB的数据。假设还是用前面提到的Amazon x1e.32xlarge, 要超过22000台服务器才能存下,还不算备份。Pin这类图片或者视频都是字节流文件,属于非格式化信息,一次写完后都不需要再改变,读取主要是通过key-value读取,属于典型的NoSQL应用。我大致搜索了Pinterest的技术博客,确实没有发现提到存储Pin用的是什么NoSQL系统,最像的可能就是Cassandra。Cassandra是Facebook开源的key-value的NoSQL系统,源于Amazon的Dynamo系统,咱就不先细聊,以后单独一篇来讲。一言以蔽之,Cassndra通过一种叫consistent hashing的技术来维护一大群key-value服务器成为一个集群。每个服务器用来存储一部分的数据,任何服务器都能接受读请求,当所读数据不在本地时,会发送给有这个数据的服务器。虽然理论上是可以建立超大规模集群,但实际情况可能是一个集群有1000+左右的服务器。如此,即便每台服务器加载10块2T硬盘,一个1000+的Cassandra集群也只能存储20PB的数据,依然没有计算冗余备份。所以,如果Pinterest使用Cassndra存储Pin,那还需要在application层面再做一层sharding。这层sharding可能基于区域划分:不同数据中心存储各自新增的Pin,或者根据数据冷热划分:新鲜的数据都存放在一个集群,并且在每个数据中心都备这样一个集群,超级热的数据应该也会缓存到CDN上,冷数据单独存放因为读取需求不大。如果没有用开源的NoSQL系统,也可能是in-house自建了一个,就像Facebook的Haystack系统专门用来存储图片视频。

关注的背后是怎样的?

有了用户,用户能发Pin看Pin,还有什么信息需要保存呢?你可能会在Pinterest上关注了某网红(influencer),想第一时间看到她(他)发出的pin,需要follow她(他)。这层follower关系同样需要存储。这类信息也是非常结构化的信息,依然可以选择用关系型数据库来存储。或者也可以用图数据库(graph database)来存储。我个人感觉如果单单是follower关系,查询通常只需要针对直接follower信息,最多再加一次跳转用来推荐熟人或好友,因此并不需要用到特别复杂的图查询操作,其实关系型数据库已经可以很好地处理这种请求了。

搜索,推荐时,都发生了什么?

聊完Pin,用户和follow关系,读者可能觉得,数据大头都搞定啦。用户可以登陆,可以发pin,也可以第一时间浏览关注网红发的pin啦。真的是这样吗?打开app后,会给你一个可以无限下拉的下拉框,随着你不断下拉,持续刷新你关注的网红发的pin,这些pin多以时间排序,也可能根据相关度做微调。你可能会有疑问,如果每次打开App,浏览关注网红的pin,都要直接先从follow关系出发,找到关注账号,再去获取关注账号最新发布的pin,最后再聚合,排序发给你。即使前面所有的数据都已经放入缓存,也要花不少时间聚合,肯定会影响用户体验。到底是怎么实现的?至此,feed流系统闪亮登场。概括来讲,feed流系统的职责就是空间换时间,利用额外的资源提前把要发送给你的pin聚合好,当你发出请求时(甚至可以不定期主动推送),直接把结果发给你。一种实现的方法是,为活跃用户(如果不是活跃用户,当有请求发来再计算就好,同时也降低了资源的使用)维护一个固定的队列用来缓存最新需要推送的pin,当有关注账号发了新的pin后就推送到这个队列进行排序。然后根据请求把缓存的好的pin发给用户。

除了feed流应用,还有什么常见的需求?有读者肯定猜到了,搜索!用户通过搜索来找相关的pin。和搜索息息相关的另一个应用就是推荐。为了让你花费更多时间在app上(increase user engagement),系统会时不时地推荐一些它认为你感兴趣的东西。为什么说搜索和推荐特别相关呢?引用一句名人名言:搜索是有关键字的推荐,推荐是无关键字的搜索。而且很多相关技术都相通。对于搜索和推荐系统,读者可能会听到很多下面这些buzz word:用户画像,协同过滤,倒排索引,多轮打分等等。搜索和推荐系统本身就和数据库一样,是个非常复杂的系统。今天咱们就不跑题啦,有机会可以再作一期番外篇(有幸做过Facebook搜索,知道些皮毛,可以和大家分享)。

点击Pin后,Pinterest都做了什么?

说了这么多关于feed流,搜索和推荐系统的事,我想引出的关键问题其实是要建立一个优秀的feed流,搜索或者推荐系统的重中之重在于(敲黑板!),需要收集大量的高质量的用户行为数据(当然是在用户知情并且允许的前提下)。读者可能会有疑问,哪些行为数据会对构建上述系统有帮助呢?举个例子,你对某个Pin的点击,在这个Pin停留了几秒,都隐式地反馈了你对这个Pin的喜爱程度,当然如果你选择转发,点赞,或者关注都显式地表达了你对这个Pin的喜爱。这个行为,不仅可以帮助系统完善对你的用户画像:假设这个Pin是体育相关,系统可能对于你是个体育爱好者这个维度上进行加分,也同时完善了这个Pin的信息:比如统计全球范围内被多少人喜欢,喜欢它的人都是什么类型等等。这些信息都会最终被推荐和搜索系统用来建模,训练生成机器学习模型来服务新的搜索和推荐需求。简而言之,任何形式的用户行为信息都可能对系统改进有帮助,所以当然是多多益善。这类信息多以事件或者log形式存在,定期地传回服务器端。这类数据有多大呢?我在一篇博客中看到,Pinterest每天会记录100TB的log(https://medium.com/@Pinterest_Engineering/scalable-and-reliable-data-ingestion-at-pinterest-b921c2ee8754) (这个数据应该除了用户数据还包括各种其他日志数据)。事件信息根据事件不同,所存储的属性也各不相同,因此并不适合用关系型数据库。除了数据量大,这类数据的另一个特点是会被不同的下游应用所需要。比如,对于Pin的点击事件,一小时最热榜说我需要这个数据实时地传输给我,方便我计算出上一个小时最受欢迎的pin。搜索系统说,我需要统计每个Pin在前90天总共的点击次数,不需要实时,每天发给我一次即可。除了手机端的用户数据,服务器端也会生成相关行为数据,这些数据也同时被不同应用所需要。于是,整个数据流变成了如下这么个复杂的交互:

pipeline_complex (credit from: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)

怎么才能很好地解决这类量大,错综交错复杂,对实时性要求高的数据需求呢?Linkedin的大牛们发明了Kafka,一个分布式,高并发,低延时的消息发布订阅系统。所有的数据源都把数据以topic的形式在Kafka上发布,不同的应用只要订阅相关的topic来获取数据即可。Pinterest也使用了Kafka来处理分发log数据。有了Kafka,上述的交互就变得清爽多了,如下图所示:

pipeline_clean (credit from: https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)

这里,我们也不展开讲Kafka,强烈推荐Kafka作者之一,Confluent公司CEO Jay Kreps的一篇博文:The log: What every software engineer should know about real-time data's unifying abstraction

有了Kafka这个实时数据分发中心,我们再来看有哪些下游应用。一类应用属于实时类,这类应用数据量不会太大,但对延时要求高。现在特别火的流式处理系统(streaming processing)正好非常契合这类应用,比如Spark, Storm, Flink等,包括Kafka也在集成streaming的功能。数据从Kafka中取出,再流入这些系统的计算节点后,就能产生相应的结果而被使用。另一类实时性的数据系统称之为时序数据库系统(Timeseries Database),专门用来查询,展示和时序相关的数据。除了应用相关的数据比如实时的点击率,搜索次数,QPS变化等。另一个主要应用在于监控整个数据流和系统稳定性,比如服务器的带宽,CPU,内存使用等等。Pinterest一开始使用开源的OpenTSDB,后来自行开发了Goku聊完了实时性要求高的,自然也有没那么紧迫的应用,也称batch job,频率一般是每天运行一次,对实时性要求并不高,可能几小时,或者只要保证24小时内能完成(不至于job一天一天不断积压)。但是数据量会特别大,比如搜索系统可能希望对前90天所有浏览过的pin统计浏览次数。流系统为了追求性能,数据处理多放在内存中,显然并不是很好的候选方案。这时,咱们的老朋友map reduce就该出场啦。Pinterest使用开源的Hadoop来支持大数据存储和处理。HIVE,基于Hadoop,提供了类似SQL的语法来省去程序员自己写map reduce job。一般的数据处理流程会被分成好几个阶段,这些阶段成DAG(directed acyclic graph)状。每个阶段会等待前一阶段的job完成,然后将这些job的输出(比如生成的HIVE table)作为这个阶段的输入。这类场景就是原来数据库应用里的ETL(extract, transform and load),只是传统的数据库可能处理不了这么大量的数据,才催生出了大数据产品。

除了上述两类,当然还会有数据量大,同时延时要求高的应用(人类真是贪得无厌呢!),比如,Data scientists可能会想要运行一些adhoc query来快速验证某些想法,如果这些query需要运行好几个小时,DS岂不是哭晕在厕所了。这就不得不搬出分布式OLAP数据库啦(终于说到老本行了)。Pinterest使用的是AWS提供的Redshift数据库。按照博客中写的,Redshift对于90%的查询语句能在120秒内完成,相对于HIVE的增速在50到100倍。不过同时也提到,使用Redshift并不是没有代价的,Redshift使用的是列存,存储方式和Hadoop不兼容,专门需要一个ETL job负责每天导出导入100TB的数据,同时还需要保证数据的完整和正确性。Facebook内部使用的是Presto,好处在于直接兼容HIVE数据格式。

上述提到的三种类型的应用,对应三种不同的数据系统,可以覆盖大部分的业务逻辑需求。不同的组根据自身业务不同,分别用对应的数据系统去实现自身的应用。比如,搜索系统的某些模块需要实时更新,可以使用流系统处理,而基数索引只需要每天更新,可以运行batch map reduce job来做统计。

数据安全和隐私保护

收集数据最终是为了能够更好地改进App,提供更好的用户体验。但必须强调,数据安全和隐私保护永远是第一位的。有哪些实践操作来保护数据安全和隐私呢?对数据进行加密和提高服务器安全性能可以很好地保护数据安全。对于用户隐私的保护,可以选择在收集用户行为数据时作随机采样,在基数足够的前提下,不会对应用或算法模型产生不良影响。就像Mark Zuckerberg说的,future is private。保护用户隐私一直是很火热的研究方向,如differential privacy,或者Google最近提到的federated training(把ML模型推送到device端做training和evaluation来避免敏感数据传回服务器端)。另一个实践是对于已经收集和存储的用户数据,设置一个table retention,如超过30天或90天后就删除原始数据。读者可能提问,只能保存90天是不是太短了。对于需要长期收集的信息,可以根据用户画像的维度作统计信息而不是保留原始数据。路漫漫其修远兮,我们都需要再接再厉!

总结

至此,我们结合Pinterest的业务和数据流图,讨论了它可能会用到的各种数据系统。要做好一个app,还有许多我们能想到的,不能想到的业务和逻辑,本文也只能从3000miles角度,概括地介绍各种系统。画了一张图,一起围绕这张图总结一下。

Pinterest BigData Systems

从App出发:

1)对于强一致,结构化的数据如用户信息等,使用关系型数据库存储

2)对于非结构化的数据如Pin的图片,视频,使用NoSQL系统存储

3)对于各种用户行为信息,app log,和服务器端log,用Kafka作消息分发订阅系统

4)下游应用,根据数据量和延时要求,又大致分为:

4.1)对数据量不大,延时要求高,采用流式系统或者时序数据库作实时数据处理

4.2)对数据量大,延时要求不高的应用,可以用Hadoop/HIVE作batch处理

4.3)对数据量大,同时有延时要求的,将数据导入到高性能的OLAP数据库作分析查询

5)对于不同业务逻辑需求,如搜索,feed,或者推荐,会根据需要采用4)中提到的方法来生成和消费相应数据

6)这些业务逻辑最终和app作交互

最后,贴一下Pinterest Engineering的blog地址:https://medium.com/@Pinterest_Engineering

以及文中提及的一些blogs:

https://medium.com/@Pinterest_Engineering/powering-interactive-data-analysis-by-redshift-b108c2ea9165

https://medium.com/@Pinterest_Engineering/building-pinalytics-pinterests-data-analytics-engine-e14c651780ca

https://medium.com/pinterest-engineering/looking-inside-the-technology-that-powers-pinterest-2e8bd1cfc329

https://medium.com/@Pinterest_Engineering/scalable-and-reliable-data-ingestion-at-pinterest-b921c2ee8754

https://medium.com/pinterest-engineering/goku-building-a-scalable-and-high-performant-time-series-database-system-a8ff5758a181

感谢阅读!

发布于: 11 小时前 阅读数: 12
用户头像

顾仲贤

关注

数据库内核杂谈作者,程序员。 2018.04.27 加入

数据库内核杂谈作者,程序员。

评论

发布
暂无评论
番外篇:新鲜上市的Unicorn - Pinterest的数据系统