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

总结下来 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 。

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

（编辑：上海站长网）

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