随着需求的增长，计算资源也随之增长，每个季度有20%-30%。经过一年半，机器数从160台增长到了5000台。记得2009年产品发布后第一次提机器预算时，为了保证新产品部的核心统计能在员工上班之前跑出来，提了100多台，那个时候一个像百度知道这样的业务线也只是申请添加十几台机器满足正常的业务增长，经理都在担心部门是否会批。后来，再提需求都是以千台计，我的经理只能用心惊胆颤来形容。这么小的团队，要提这么多的机器。我们觉得是该做些优化了，这种膨胀速度实在扛不住。
在2010年初，发生了一次部门调整，我们新产品部和网页搜索部合并了。我们Nslog团队和网页搜索的相关性部门下的Rank-Ubs团队合并，我们起了个新大组名字叫Rank-Us(user study)。好的是我们自然名正言顺的覆盖了更多的业务，不好的是因为属于相关性部门，部门的核心指标和我们的工作似乎没有太大关系，包括部门负责人对我们的期望是优先支持好本部门，其次再是其他部门的业务。早在2009年，随着Log平台的用户越来越多，我的想法就不只是做一个简单的统计了。我的想法是要把团队面向全公司服务，甚至成为像NLP(自然语言处理)部门在厂长心中的地位。显然这两个思路存在着冲突，我一方面需要照顾部门的需求，另一方面是要考虑如何在全公司推进。
那个时候每个季度都要做规划，我的直接经理(我在2010年初晋升了项目经理)总觉得我做的规划太粗略，可以说是未来半年之后会咋样是看不清楚的。我甚至觉得Log平台已经比较成熟了，我需要花更多的精力研究如何做用户行为分析，以及数据挖掘。我和我的一个团队成员(也是我现在的合伙人)花了很多精力帮着各个业务线做宏观的用户行为分析，比如根据用户的活跃程度、地域、渠道等，做多维分析，但业务线的产品经理看了之后，也不知道能怎么用。当时还基于数据立方体的概念做了一个失败的Cube产品，用于流量分析。基于Hypertable(后来改成HBase，再后来改成百度基于Mysql研发的一个分布式数据库DDBS)做了个叫Logdata的用户行为查询工具，通过输入一个IP/UserID获取到用户在产品上的详细行为。总之那个时候是在不断的尝试，不断的学习，但又看不清该往那个方向走。
前面提到机器数的膨胀太厉害，我们分析这其中的原因，最大的就是中间数据没有得以利用。所有的任务都是基于原始日志的，如果生成的中间结果能被重复使用，那就会降低计算量。 我们就想给中间数据加上Schema，让其他人能够知道平台上已有的数据每一行都表示什么。但因为大家已经习惯于从原始数据取，根本就推不动。我自己对Schema的价值也理解不到位，思维还是停留在如何做一个更牛逼的计算平台上。
这种理念的极致是我有一天意识到查询也是一种计算，数据库无非是计算的一种特定模式。Log平台是做MapReduce任务的，而LogData是用于Key-Value查询的，甚至是简单的SQL查询，两者能否统一起来在海量数据的情况下，我们是否可以把传统数据库当作Hadoop的缓存来使用，如果数据在传统数据库中，我就通过SQL来查询，如果是在Hadoop中，我就转化成MapReduce任务，当然响应会更慢一些。对外暴露的接口，统一到我们发明的DQuery。这样，整个架构就变成了这个样子：
(图1 查询也是一种计算)
用户在前端界面提交查询后，并不关心数据的存放位置，由调度器根据数据库的数据就绪状态信息来判断查询分发到什么地方去。我觉得我们理念还是挺先进的，但似乎没太大用处。
到了2010年底，我们既要维护Log平台的业务增长需求，又要维护Logdata平台和Cube平台，而团队才只有不到10个人，其中包括3~4个实习生。这样的团队配置，根本没有精力再搞出像样的东西来。后来曾经出现我们设计了一套新方案，都评审过了，都被我按下先不做了。
在思路上，我们逐步做出了转变，从以计算为中心，转变到以数据为中心。我们渐渐认识到我们做的其实就是提了多年的老掉牙的数据仓库，只是用的云计算的技术。但如何做到数据为中心，这是一个挑战。
本文采用「CC BY-SA 4.0 CN」协议转载自互联网、仅供学习交流，内容版权归原作者所有，如涉作品、版权和其他问题请给「我们」留言处理。
