1.查询等待时间缩短数秒: 之前几秒现在几秒 做了哪些方面的优化？
答：之前少则5秒多则10秒以上，现在一般情况下3秒内就会响应。
直播模块是针对直播节目数据的统计查询，涉及指标主要是vv和uv，要做的事情就是针对这两个指标在时间、业务线、镜头等多个维度下进行展示，具体表现形式是指定维度下指标占全局的百分比、指标随时间的变化趋势，以及日vv/uv、总vv/uv等。
前端和后台的隔离是指，在前端通过刷新页面请求在线人数和vv、uv的变化趋势时，后台每5分钟处理一次请求，这样就保证了当用户频繁刷新前端页面时，不至于给服务器带来过于繁重的压力。这种处理方式也决定了vv/uv/在线人数这几个指标的数据粒度为5分钟。
实时和离线的隔离是指，对于正在播放的直播节目，vv/uv/在线人数的变化趋势是时间敏感的，需要实时监测数据，这就要求服务器需要尽量实时地对数据进行处理和响应。而对于已经结束的节目，它们的数据没有意外的话是不会再变化的，这个时候我们就把它们存放在服务器的磁盘中，当服务器负载较低的时候再按照预先配置的计划任务进行离线处理，这跟计算日vv/日uv等实时性不强的数据是一个道理。
2.产品上线数据准确率达95+%：以前准确率是多少，低了大概会有哪些问题，如何处理？处理的难点？
答：从测试团队反馈过来的问题数量来看，之前的准确率大概80%左右，甚至还有一些测试团队没有发现的问题，这跟团队架构有关，测试团队负责整个研发中心所有项目组的产品验证，针对各个产品的业务并不能做到百分百的理解，这种情况下就很容易出现我们的魔方数据有些问题他们却未发现的状况。所以我加入魔方团队后就一直负责产品内部验证，加了这么一个流程之后再上beta版本那边就很少提问题过来了，因为我在检查数据问题时功能性问题也一并处理了。;)
准确率低地后果当然严重啊，这是拿给业务方作为参考决策的，又是给上面领导看的，如果错误率很高那么所有决策就是在错误的数据基础上做决策。
如何处理：大体思路首先是看运算规则是否正确，然后同一指标在不同页面的数据本该相同的实际上是否相同？
处理的难点：像vv这种指标因为不涉及到去重所以基本上不存在很严重的问题，但是uv、在线人数这种就不一定，各个镜头或者业务线加起来跟总的一般是不一样的，uv过滤指标在pc上是按照cookie，业务线上是按照设备号，如果一个用户在登陆情况下既用pc看又用手机看怎么处理呢，这就涉及到算法选择的问题。没有绝对的准确。这个时候需要有清晰的逻辑思维和不屈不挠的坚持精神。;)
3.产品由社交转型为本地服务平台：为啥转型，转型的结果？
答：因为一上来就做远距离社交真的很困难，平台信息和用户密度过低，用户上来没有内容可看，自然没有欲望去创造去互动，所以虽然我们通过推广在首周获取了500+种子用户，但是后续发展不怎么样。所以觉得转型为本地服务，这样的优势是我们可以专耕一小块，先把一个地方的内容做起来，通过地推的方式纳入商家，为他们提供免费的推广和沟通渠道。
转型的结果是产品变得不伦不类，失去了原先的小清新，不够专业的商业平台也不能给商户或是用户带来很大的价值，所以最后不了了之。
