[翻译]Twitter的实时海量数据 处理方案

首发于：我是买家博客

作者：杨鑫奇

 

对于实时的海量数据处理方案，最近在看hadoop和storm的比较，以及细看了下nathan marz大侠的storm介绍之后，决定深入，在他的博客中发现了一本他写的big data这本书，遂决定深入研究下big data下的各种的principles,就找资料在slideshare上发现了twitter的nk在2010.4.13的Qcon大会的分享。就决定把这个ppt翻译下，加深下认识。翻译中有很多不当的地方，大家欢迎指出，本来自己的因为也很差，大学的计算机专业英语也是勉强及格的货，所以大家凑合着看吧！

PPT地址：http://www.slideshare.net/nkallen/q-con-3770885

Big Data in Real-Time

at Twitter
Twitter的实时海量数据
--xinqiyang 翻译
2010.4.13 Qcon

What is Real-Time Data?
什么是实时数据?

On-line queries for a single web request
单个web线上查询

Off-line computations with very low latency
低延时的离线计算

Latency and throughput are equally important
延时和吞吐量同等重要

Not talking about Hadoop and other high-latency,Big Data tools
不讨论高延时的hadoop等其他海量数据处理工具

The four data problems

Tweets
消息

What is a Tweet?

140 character message,plus some metadata
140个字符的消息，添加了富元素

Query patterns
查询模式

by id
通过id查询

by author
通过作者查询

(also @replies.but not discussed here)

Row Storage
行存储

Original Implementation
原实现方案

Relational
关系型

Single table,vertically scaled
单表,垂直切分

Master-Slave replication and Memcached for read throughput
主从同步和memcached读缓存

Problems w/ solutions
问题和解决方案

Disk space:did not want to support disk arrays larger than 800GB
磁盘空间，不支持大于800g的磁盘数组

At 2954291678 tweets,disk was over 90% utilized.
当达到2954291678条消息的时候，磁盘使用率高于90%

Partition 分区

Possible implementations
可行的实现方案

Partition by primary key
按照主键来分区

通过主键奇偶来分布到2个分区

通过user_id查询最近的tweets 得查询N个分区

Current Implementation
当前的实现方案

Partition by time
通过时间分区

查询一定量的tweets需要遍历好几个分区

LOCALITY
本地化

Low Latency
低延时

PK Lookup
主键查找

Memcached 1ms

Mysql <10ms*

依赖于搜索到的分区的数量

Principles
原则

Partition and index
分区和索引

Exploit locality(in this case,temporal locality)
开发本地化（临时的本地化）？？

New tweets are requested most frequently,so usually only 1 partition is checked
发送tweets的并发量大，所以只有一个分区被检查?

Write throughput
写处理能力

Have encountered deadlocks in MySQL at crazy tweet velocity
在高并发的tweets下遇到Mysql死锁

Creating a new temporal shard is a manual process and takes to long;it involves setting up a parallell replication hierarchy.Our DBA hates us
经常手动创建进程建立一个新的临时的水平切分层，它解决了同步的问题，但是DBA讨厌这样

将来的实现方案

分区

分片 id 奇偶 + 时间切，分成k1,k2, u1,u2………

使用Cassandra(non-relational 非关系型)

Primary Key partitioning 主键分区

Manual secondary index on user_id 手动把user_id设为第二索引

Memcached for 90+% of reads memcached承担了90%+的读压力

Timelines
时间线

What is a Timeline?
什么是Timeline?

Sequence of tweet ids
tweet id的顺序

Query pattern
查询模式

get by user_id

Operations

append 附加

merge 合并

truncate 截断

High-velocity bounded vector
高速的有界矢量??

Space-based(in-place mutation)
基于空间（地方的突变)???

Original Implementation
原实现方案

SELECT * FROM tweets
WHERE user_id IN
 (
FROM followers
WHERE destination_id = ?)
ORDER BY created_at DESC
LIMIT 20

SELECT * FROM tweets
WHERE user_id IN
 (
SELECT source_id
FROM followers
WHERE destination_id = ?
)
ORDER BY created_at DESC
当好友很多的时候消息很多，很慢

OFF-LINE VS ONLINE COMPUTATIONS
离线VS在线计算

Current Implementation
当前的实现方案

Sequences stored in Memcached
序列话存储在memcached中

Fanout off-line,but has a low latency SLA
开始低延时的离线计算

Truncate at random intervals to ensure bounded length
随机间隔的截断确保相同边界长度？？？

On cache miss,merge user timelines
当cache失效，合并用户的timelines

Throughput Statistics
流量统计

date
时间

average fps
平均tps

Tps:Transaction Per Second 每秒事物处理量

peak tps
峰值tps

fanout ratio

deliveries

1.2m Deliveries per second

MEMORY HIERARCHY
内存分层

Possible implementations
可行的方案

Fanout to disk
散列磁盘

Ridonculous number of IOPS required,even with fancy buffering techniques
使用昂贵的缓存技术来实现高并发的IO操作???

Cost of rebuilding data from other durable stores not too expensive
从其他的存储中重建数据的代价不是很高

Fanout to memory
散列内存

Good if cardinality of corpus *bytes/datum not too many GB
在少量的GB的技术下还算好

Low Latency
低延迟

get 1ms

append 1ms

fanout <1s*

Depends on the number of followers of the tweeter
依赖于关注发布者的人的多少

Principles
原则

Off-line vs. Online computation
离线 VS 在线计算

The answer to some problems can be pre-computed
使用预计算来解决部分问题

if the amount of work is bounded and the query pattern is very limited
如果工作可以预计还有查询模式很有限

Keep the memory hierarchy in mind
在思想上关注内存的层级

The efficiency of a system includes the cost of generating data from another source(such as a backup) times the probability of needing to
一个高效的系统包含了从可能需要从其他数据源（例如备份中）恢复数据所消耗的时间

Social graphs
社会图谱

What is a Social Graph?
什么是社会图谱?

List of who follows whom,who blocks whom,etc.
是谁关注谁，谁阻止谁的一个列表。等....

Operations
操作

Enumerate by time
通过时间计算

Intersection,Union,Difference
交集，并集,2个集合差异

Inclusion
包含

Cardinality
基数

Mass-deletes for spam
spam的大量删除

Medium-velocity unbounded vectors
中速的无界限的矢量？？

Complex,predetermined queries
复杂预查询

PPT中列举了一些@用户时候的消息提示，已经关注和被关注列表的关系等，来说明如何实现

方案

Original Implementation
原始方案

Single table,vertically scaled
单表，垂直切分

Master-Slave replication
主从同步方案

遇到的问题

Write throughput
写并发

Indices couldn't be kept in RAM
索引不能保存在内存中

Current solution
现在的解决方案

建了2个表Forward,Backward 前后端的2个表 source_id,destination_id,updated_at,delete

Partitioned by user id
通过user id 切分

Edges stored in "forward" and "backward" directions
分别存储向前和向后2个方向,关注和被关注，2个user_id做主健的2张表

Indexed by time
通过时间索引

Indexed by element(for set algebra)
通过集合运算的元素进行索引

Denormalized cardinality
不规则的计数

Challenges
挑战

Data consistency in the presence of failures
当出现失败的时候的数据一致性

Write operations are idempotent:retry until success
幂等写操作，一直重试直到写成功

Last-Write Wins for edges
最后的写入为准
(with an ordering relation on State for time conflicts) 当时间冲突的时候实现有序的的状态 ??

Other commutative strategies for mass-writes
其他的针对大量写操作的策略

Low Latency
低延迟

cardinality 1ms
基数

iteration
迭代 100edges/ms*

write ack
写操作 1ms

write materialize
写入实现 16ms

inclusion
包含计算 1ms

Principles
原则

It is not possible to pre-compute set algebra queries
无法预计算集合的相关查询，（由于操作的涉及写次数太多）

Simple distributed coordination techniques work
简单的分布树技术能用

Partition,replicate,index.Many efficiency and scalability problems are solved the same way
分区，复制,索引，同样可以解决很多的性能和可用性的问题

Search indices
搜索索引

Real-time results for xxxxxxx场景，响应实时的搜索请求

What is a Search Index?
什么是搜索索引

"Find me all tweets with these words in it…"
找到包含某些词的tweets

Posting list
出列表

Boolean and/or queries
布尔及and/or查询

Complex,ad hoc queues
复杂的广告查询 ??? what is "ad hoc" ??

Relevance is recency
最新的关联内容

Note:there is a non-real-time component to search,but it is not discussed here
这里不讨论非实时的搜索模块

方案

Original Implementation
原方案

Single table,vertically scaled
单表，垂直切分

Master-Slave replication for read throughput
主从同步

Problems w/ solution

Index could not be kept in memory
索引无法保持在内存中

Current Implementation

按照term_id和doc_id建表，分区

Partitioned by time
通过时间分区

Uses MySQL
使用mysql

Uses delayed key-write
使用延迟key写锁

Problems

Write throughput
写并发

Queries for fare terms need to search many partitions
查询稀疏需要夸多个分区

Space efficiency/recall
磁盘利用和重写

MySQLrequires lots of memory
mysql占用了大量的内存

DATA NEAR COMPUTATION
贴近数据计算

Future solution
将来的解决方案

Document partitioning
文档行分区

Time partitioning too
按时间分区

Merge layer
合并层

May use Lucene instead of MySQL
使用lucene来替代mysql

Principles
原则

Partition so that work can be parallelized
分区使得可以水平扩展

Temporal locality is not always enough
临时的空间往往不够????

Principles
原则

All engineering solutions are transient
所有的工程解决方案都是寻瞬变的

Nothing's perfect but some solutions are good enough for a while
没有完美的，但是有些方案在当时是足够好的

Scalability solutions aren't magic.They involve partitioning,indexing,and replication
可靠性方案不是虚幻的，因为他有 分区，索引和复制

All data for real-time queries MUST be in memory.
Disk is for writes only .
所有的实时查询的数据都必须放到内存里面，磁盘只是写的时候用到.

Some problems can be solved with pre-computation,but a lot can't
一些问题可以通过预运算来解决，但是大部分是不行的

Exploit locality where possible
开发替代方案是可能的?????

附图：

对于twitter系统的更新：

对于2010年的twitter好像，搜索方面还是只是使用mysql,现在他们的搜索后端采用了solr，来解决搜索的问题了。

这个是2010年的方案，2011年底到现在这段时间，twitter等其他的一些公司都在使用storm了。

现在对于垂直切分和水平切分都是很有必要的，在前期的时候其实就应该考虑挺提供可行的解决方案。这块自己弄了2个一个叫sharding_mysql,一个叫sharding_redis,用来处理sharding。

对于技术方案随着系统的演进会一直的进行下去，工程方案却是没有完美的，在当下够用，有一定的扩展空间就好了！

基本遇到的挑战，任何的大型系统都有，那就是高并发的写操作，这个大部分前期的解决方案都是使用Master-Slave Replication.后来都切分的了.

其实很多的技术方案也是不会过时的，也有很多人都是别人会遇到过的，自己也遇到了，都会走这样的一个过程。