从Quora和Spotify案例看数据处理与背后的思考——QCon旧金山参会

编者按：QCon 是由 InfoQ 主办的全球顶级技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、东京和旧金山等城市召开。前不久，阿里云工程师子嘉赴美参加了 QCon 旧金山，并撰写了几篇笔记。第一篇我们已经发布：容器与调度——QCon旧金山参会总结 。本文是第二篇。

子嘉，阿里云缓存数据库总负责人，负责 Redis 和 Memcached 的开发团队。Redis 中文社区的核心发起人。本文首发于云栖社区，转载已获授权。

原文链接：https://yq.aliyun.com/articles/63149

大数据的题目看起来好写，因为大家似乎都懂，但是其实也难写，因为太大了，没有具体的问题很难写出有营养的东西，所以今天选取两个 QCon 上比较典型的例子，来管中一窥大数据的魅影。

Quora 是一个问答社交软件，问答社交的特点就是有各种各样的计数器，比如帖子的支持、反对、评论数量，用户的关注、粉丝数量等等，随着用户量的增加、帖子的增多、以及带来的互动的增长，Quora 处理的数据也是爆炸式增长。Quora 从第一天开始就长在云上（AWS），生产环境使用 MySQL 和 HBase 做存储，使用 RedShift 和 Spark 做数据分析，在这些组件的基础上Quora 做了一个数据服务叫Quanta。

Quanta的设计约束是：

• 数据更新之后不能丢失，要求持久化到 disk

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

• 每秒写>10W次，每秒读>100W次，只能用追加写

• 读写都要很快

• 资源和负载能够线性扩展，而且能够扩展到目前负载的 50 倍

• 成本越低越好

Quora 还有很多基于时间序列的数据计算，比如：

• 过去 T 时间内发生了什么，基于滑动窗口

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

• 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 中运算，这样就解决了冲突的问题。

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!