Feed stream data to see people - architecture practice

background

Feed stream: can be understood as information flow, the solution is the information between information producers and consumers of information delivery problems.
Our Common Feed flow scenarios are:
1 hand wash, micro Amoy provided to consumers home product information, news and other users concerned about the store's
2 micro-channel circle of friends, friends to share timely access to information
3 microblogging, fans get concerned about the star, big V information
4 headlines, users access the system recommended news, reviews, gossip

About Feed flow architecture design, including the scenario above, many industry experts gives the corresponding thinking, design and practice. I am a big data direction of the origin of the art, where teams are involved in Ali hand Amoy, micro Amoy Feed stream storage layer related services, our HBase / Lindorm data storage products in the public cloud also supports the Soul, interesting headlines, benefits Some popular headlines and other new media, social networking products. Some of our understanding of the functional data storage products, performance, availability, and real hope for a landing Feed stream architecture can have some help, as well as to discuss the future of data products and how to help Feed Feed stream flow further iterations.

This article hopes to provide two values:

1 Feed stream current mainstream architecture and floor plan
how 2 choose a start-up company architecture evolution path Feed flow

Business Analysis

Feed value stream participants

• Information producers

Hope the information rich supported formats (text, image, video), published fluency (availability of production information), subscribers receive timely information (timeliness), the subscriber does not leak information (transmission reliability)

• Consumer information

We hope to receive timely information of interest (timeliness), hoping not to miss a friend, idol of the message (delivery reliability), hoping to obtain valuable information (to solve the information overload)

• platform

We hope to attract more producers and consumers (PV, UV), the user longer residence time, advertising, higher commodity conversion

Feed Information Transfer

One is messaging based on the relationship, the relationship by adding friends, concern, subscription, etc. established, may be a two-way may also be one-way. One is based on the recommendation algorithm, according to the system user portrait, portrait message category or label using collaborative filtering algorithms such as push messages to the user. Weibo micro-channel and biased in favor of relations based on headlines, vibrato-based recommendation in favor.

Technical difficulties Feed flow

Internet scene always need a certain size in order to reflect technical bottlenecks, let's look at two sets of public data:

Sina microblogging, for example, as a heavyweight social sharing platform for mobile social networking era, early in 2017 160 million daily active users, nearly 330 million monthly active users, add hundreds of millions of pieces of data each day, the total data capacity of one hundred billion, a single core QPS access back-end data services of up to one million

As of the end of December 2016, headlines daily active users 7800W, monthly active users 175 million, the average length of a single-user 76 minutes, user behavior peak 150w + msg / s, the training data every day 300T + (compressed), the machine scale million level

Above or historical metrics for the two giants, assuming a message 1KB then the amount of data of about 93TB of one hundred billion messages daily increase in the scale of a few hundred GB and QPS up to a million, and therefore have a high need to read and write throughput, scalability good distributed storage system. Users expect hundreds of milliseconds in response to browse news, news seen hope, real-time requirements of the system is very high at the second level or at least about 1 minute, and there needs multi-level cache architecture. The system must have high availability, good fault tolerance. Finally, this system is best not too expensive.

Therefore, we need a high throughput, scalable, low-latency, high availability, low cost Feed Streaming Architecture

Mainstream architecture

FIG. 1 is a simple flow abstract Feed, to complete the process of passing a message from the producer to the consumer.

FIG simple abstraction 1 Feed flow

Message and relationships

First of all, users get the APP side is a Feed ID list, this list does not necessarily contain all the new messages, each user will not necessarily open the browser, if you pass the entire message is a waste of resources, so the message is generated out of the first generation two body portions and the index, wherein the index contains the message ID and metadata. Secondly, an application always a relationship, relationship-based delivery is essential, therefore there must be a relationship between the store and query service.

FIG 2 Feed stream stored message, the relationship between

消息本身应该算是一种半结构化数据（包含文字，图片，短视频，音频，元数据等）。其读写吞吐量要求高，读写比例需要看具体场景。总的存储空间大，需要很好的扩展性来支撑业务增长。消息可能会有多次更新，比如内容修改，浏览数，点赞数，转发数（成熟的系统会独立一个counter模块来服务这些元数据）以及标记删除。消息一般不会永久保存，可能要在1年或者3年后删除。

综上，个人推荐使用HBase存储

1. HBase支持结构化和半结构化数据；
2. 具有非常好的写入性能，特别对于Feed流场景可以利用批量写接口单机（32核64GB）达到几十万的写入效率；
3. HBase具备非常平滑的水平扩展能力，自动进行Sharding和Balance；
4. HBase内置的BlockCache加上SSD盘可以提供ms级的高并发读；
5. HBase的TTL特性可以自动的淘汰过期数据；
6. 利用数据复制搭建一个冷热分离系统，新消息存储在拥有SSD磁盘和大规格缓存的热库，旧数据存储在冷库。
7. 运用编码压缩有效的控制存储成本，见HBase优化之路-合理的使用编码压缩

图3 使用HBase存储Feed流消息

对于关系服务，其写入操作是建立关系和删除关系，读取操作是获取关系列表，逻辑上仅需要一个KV系统。如果数据量较少可以使用RDS，如果数据量较大推荐使用HBase。如果对关系的QPS压力大可以考虑用Redis做缓存。

图4 用户关系存储

消息传递

讲到Feed流一定会有关于推模式和拉模式的讨论，推模式是把消息复制N次发送到N个用户的收信箱，用户想看消息时从自己的收信箱直接获取。拉模式相反，生产者的消息写入自己的发信箱，用户想看消息时从关注的M个发信箱中收集消息。

图5 消息传递的推模式和拉模式

推模式实现相对简单，时效性也比较好。拉模式要想获得好的性能需要多级的缓存架构。推模式重写，拉模式重读，Feed流场景下写的聚合效果要优于读，写可以大批量聚合。N越大，写入造成的数据冗余就越大。M越大，读消耗的资源越大。

随着业务的增长，推模式资源浪费会越发严重。原因在于两点：第一存在着大量的僵尸账号，以及大比例的非活跃用户几天或者半个月才登陆一次；第二信息过载，信息太多，重复信息太多，垃圾信息太多，用户感觉有用的信息少，消息的阅读比例低。这种情况下推模式相当一部分在做无用功，白白浪费系统资源。

是推？是拉？还是混合？没有最好的架构，只有适合的场景~

基于关系的传递

图6是纯推模式的架构，该架构有3个关键的部分

1. 异步化。生产者提交消息首先写入一个队列，成功则表示发布成功，Dispatcher模块会异步的处理消息。这一点非常关键，首先生产者的消息发布体验非常好，不需要等待消息同步到粉丝的收信箱，发布延迟低成功率高；其次Dispatcher可以控制队列的处理速度，可以有效的控制大V账号造成的脉冲压力。
2. 多级队列。Dispatcher可以根据消费者的状态，信息的分类等划分不同的处理方式，分配不同的资源。比如对于大V账号的消息，当前活跃用户选择直接发送，保障消息的时效性，非活跃用户放入队列延迟发送。比如转发多的消息可以优先处理等。队列里的消息可以采用批量聚合写的方式提高吞吐。
3. 收信箱。假如有两亿用户，每个用户保留最新2000条推送消息。即便存储的是索引也是千亿的规模。收信箱一般的表结构为用户ID+消息序列 + 消息ID + 消息元数据，消息序列是一个递增的ID，需要存储一个偏移量表示上次读到的消息序列ID。用户读取最新消息 select * from inbox where 消息序列 > offset。

图6 基于关系传递的纯推模式

推荐使用HBase实现收信箱

1. HBase单机批量写能力在几十万并且可以水平扩展。
2. HBase的高效前缀扫描非常适合读取最新的消息。
3. HBase的TTL功能可以对数据定义生命周期，高效的淘汰过期数据。
4. HBase的Filter过滤器和二级索引可以有效的实现Inbox的搜索能力。

消费者收信箱hbase表设计如下，其中序列号要保证递增，一般用时间戳即可，特别高频情况下可以用一个RDS来制造序列号

Rowkey	消息元数据列	状态列	其它列
MD5(用户ID)+用户ID+序列号	消息ID、作者、发布时间、关键字等	已读、未读

图7是推拉结合的模式

• 增加发信箱，大V的发布进入其独立的发信箱。非大V的发布直接发送到用户的收信箱。其好处是解决大量的僵尸账号和非活跃账号的问题。用户只有在请求新消息的时候（比如登陆、下拉消息框）才会去消耗系统资源。
• 发信箱的多级缓存架构。一个大V可能有百万粉丝，一条热点消息的传播窗口也会非常短，即短时间内会对发信箱中的同一条消息大量重复读取，对系统挑战很大。终态下我们可能会选择两级缓存，收信箱数据还是要持久化的，否则升级或者宕机时数据就丢失了，所以第一层是一个分布式数据存储，这个存储推荐使用HBase，原因和Inbox类似。第二层使用redis缓存加速，但是大V过大可能造成热点问题还需要第三层本地缓存。缓存层的优化主要包括两个方向：第一提高缓存命中率，常用的方式是对数据进行编码压缩，第二保障缓存的可用性，这里涉及到对缓存的冗余。

图7 基于关系传递的推拉混合模式

基于推荐的传递

图8是基于推荐的模型，可以看出它是在推拉结合的模式上融合了推荐系统。

1. 引入画像系统，保存用户画像、消息画像（简单情况下消息画像可以放在消息元数据中）。画像用于推荐系统算法的输入。
2. 引入了临时收信箱，在信息过载的场景中，非大V的消息也是总量很大，其中不免充斥着垃圾、冗余消息，所以直接进入用户收信箱不太合适。
3. 收信箱和发信箱都需要有良好的搜索能力，这是推荐系统高效运行的关键。Outbox有缓存层，索引可以做到缓存里面；Inbox一般情况下二级索引可以满足大部分需求，但如果用户希望有全文索引或者任意维度的检索能力，还需要引入搜索系统如Solr/ES

图8 基于推荐的Feed流架构

用户画像使用HBase存储

1. 画像一般是稀疏表，画像总维度可能在200+甚至更多，但单个用户的维度可能在几十，并且维度可能随业务不断变化。那么HBase的Schema free和稀疏表的能力非常适合这个场景，易用且节省大量存储空间。
2. 对画像的访问一般是单行读，hbase本身单行Get的性能就非常好。阿里云HBase在这个方向上做了非常多的优化，包括CCSMAP、SharedBucketCache、MemstoreBloomFilter、Index Encoding等，可以达到平均RT=1-2ms，单库99.9% <100ms。阿里内部利用双集群Dual Service可以做到 99.9% < 30ms，这一能力我们也在努力推到公有云。hbase的读吞吐随机器数量水平扩展。

临时收信箱使用云HBase

1. HBase的读写高吞吐、低延迟能力，这里不再重复。
2. HBase提供Filter和全局二级索引，满足不同量级的搜索需求。
3. 阿里云HBase融合HBase与Solr能力，提供低成本的全文索引、多维索引能力。

初创公司的迭代路径

在业务发展的初期，用户量和资源都没有那么多，团队的人力投入也是有限的，不可能一上来就搞一个特别复杂的架构，“够用”就行了，重要的是

1. 可以快速的交付
2. 系统要稳定
3. 未来可以从容的迭代，避免推倒重来

本人水平有限，根据自身的经验向大家推荐一种迭代路径以供参考，如有不同意见欢迎交流

起步架构如图9，使用云Kafka+云HBase。如果对Inbox有检索需求，建议使用HBase的scan+filter即可。

1. 消息分为主体和索引
2. 采用纯推的模式
3. 采用异步化

图9 起步架构

数据量逐渐增大后，对推模式进一步迭代，主要需求是

1. 控制大V造成的写入脉冲高峰
2. 控制存储成本
3. 提升读写性能
4. 提升一定的Inbox搜索能力

进一步的迭代架构如图10

1. 消息分为主体和索引
2. 采用纯推的模式
3. 采用异步化
4. 采用多级队列解决大V问题
5. 采用冷热分离降低存储成本
6. 此时Inbox中的消息也很多，对搜索的需求增强，仅仅Scan+Filter不够，可能需要二级索引

图10 纯推模式的演进

业务迅猛发展，消息和用户增长迅速，僵尸账号、非活跃账号较多，信息过载严重

1. 消息分为主体和索引
2. 采用推拉结合模式
3. 采用异步化
4. 引入推荐系统
5. 采用冷热分离降低存储成本
6. Outbox采用多级缓存提高读取性能
7. Inbox增加二级索引提升搜索能力

使用云Kafka+云HBase+云Redis

图11 基于推荐的推拉混合架构

总结

Feed信息流是互联网场景中非常普遍的场景，遍布于电商、社交、新媒体等APP，因此研究Feed流是非常有价值的一件事情。本文总结了Feed流的业务场景和主流架构，分析了不同场景、体量下技术的难点与瓶颈。对Dispatcher、Inbox、Outout几个组件进行了详细的演进介绍，提供了基于云环境的落地方案。本人水平有限，希望可以抛砖引玉，欢迎大家一起探讨。Feed流的架构演进还在持续，不同业务场景下还有哪些缺陷和痛点？数据产品如何从功能和性能上演进来支撑Feed流的持续发展？在这些问题的驱动下，云HBase未来将会大力投入到Feed流场景的持续优化和赋能！

原文链接
本文为云栖社区原创内容，未经允许不得转载。