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

总结下来 Quora 将数据做了很好的 model，主要分为两大类，有计数的、有图的，然后对两类数据分治处理，尤其是在处理图数据的时候通过将图分割来解除依赖，所以不需要加锁，极大提升了并行度；对系统也做了很好的设计，比如写和更新解耦、更新可弹性伸缩、存储采用HBase更为灵活，当然前提是要对业务有深度思考并对约束有清晰的判断。

接下来的案例是 Spotify，Spotify 的问题是成长太快，在流量和用户快速增长的时候，系统服务依赖也成指数级别增长，由于整个架构缺乏体系的思考和设计，所以在服务多了之后就出了一系列的问题，如隔三差五的小故障、Hadoop 挂掉、数据重复处理、很多数据流水线上的 bug 无法追查等等，针对这些问题，Spotify 做了一系列的改造。

首先是先暴露问题，做早期报警，然后做了一个有领域编程语言支持的监控工具 Datamon，Datamon 不仅仅做报警，更重要的是对数据的所有权进行了划分，这是一个比较大的进步，报警大家都会做，但是把报警发给谁是一个更有挑战的问题；针对调度和计算不好 debug 的问题做了一套叫 Styx 的服务，Styx 的每一个 job 都用 docker 来做隔离，也暴露了更多的 debug 信息出来，易用性上也比之前有很大提升，具体实现细节没有多讲；最后一步为了实现弹性扩缩容利用 Kubernetes 做了一套系统叫 GABO，不再赘述。

从Spotify这个例子可以看出，如果一个架构师或者 CTO 没有从体系上和整体架构上去思考问题，业务发展越快跪得越快，给飞机换轮子听着很英勇，但是能避免的还是尽量提前避免。

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

QCon 北京 2017 将于 2017 年 4 月 16—18 日在北京国家会议中心举行，现已启动筹备，想听什么，提出你的愿望吧，可以在后台直接回复或发送邮件到 qcon@cn.infoq.com 。

点击“阅读原文”，可查看大会专题。