编者按：大数据的题目看起来好写，因为大家似乎都懂，但是其实也难写，因为太大了，没有具体的问题很难写出有营养的东西，所以今天选取两个qcon比较典型的例子来管中一窥大数据的魅影。
有的同学很困惑米国人不看知乎怎么知道那么多知识呢？米国人当然看quora啦，quora是一个问答社交软件，问答社交的特点就是有各种各样的计数器，比如帖子的支持、反对、评论数量，用户的关注、粉丝数量等等，随着用户量的增加、帖子的增多、以及带来的互动的增长，quora处理的数据也是爆炸式增长。quora从第一天开始就长在云上（aws），生产环境使用mysql和hbase做存储，使用refshift和spark用来做数据分析，在这些组件的基础上quora做了一个数据服务叫quanta，quanta的设计约束是：
a：数据更新之后不能丢失，要求持久化到disk
b：有billion级别的counter，单机放不下，所以需要分布式集群
c：每秒写>10w次，每秒读>100w次，只能用追加写
d：读写都要很快
e：资源和负载能够线性扩展，而且能够扩展到目前负载的50倍
f：成本越低越好
quora还有很多基于时间序列数据计算，比如：
a：过去t时间内发生了什么，基于滑动窗口
b：过去y时间内每隔x该事件发生了多少次，需要访问历史存储数据
c：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没有从体系上和整体架构上去思考问题，业务发展越快跪得越快，给飞机换轮子听着很英勇但是能避免的还是尽量提前避免。
通过上面这两个例子我们也能看出无论目前有了什么样的工具、多么牛逼的产品，定义问题、提炼需求、确定问题边界反而比直接去写代码更有价值，这才是我们的核心竞争力，这些技能也就是我们平时所倡导的调研和思考，用在思考上的时间多了用在擦屁股上的时间也就少了，与君共勉。