现在几乎所有的大公司都会采用AB实验来进行数据驱动的决策。任何细微的改动、新功能的上线，如果没有AB实验结果的佐证，你都不好意思上线。所以一个AB平台，动辄每天几百个实验在同时测试着我们的用户，而根据Netflix的经验，不好意思，这其中90%的实验会得出错误的结论。

先说观点，spark和flink都是目前能够一站式解决lambda架构的计算框架。因为spark出来的早，现在在活跃度、成熟度方面比flink强。flink发展相对较晚，相比spark各个细节做了很多优化。个人觉得二者是同一个世代计算框架的不同实现，细节方面会相互学习、增强。但要说谁能干掉谁，恐怕都没有这能力。

在实际工作中经常碰到这样的监控需求，重点城市的访问流量是否有大的波动、一个广告位的ecpm是否在合理的范围内、机器的CPU利用率是否正常… 经过一段时间case by case的支持，我们想到或许有通用的办法去解决这类问题。

最近半年花了不少时间在实时olap上，业务场景是全维度实时监控，这里记录下自己的一些思考。 对于大多数大数据底层应用，公司都有很成熟的支持中间件。比如实时消息队列(TDBANK)、KV存储(CKV)、sql on hadoop(tdw)等等。可是实时olap这个场景，基本上都是各个业务自己小规模的玩玩。之前一直想吐槽数据平台不作为，现在自己摸索了这么久才终于明白，实时olap场景的投入产出比 – 真的有点低。

大数据计算框架日新月异，而每次计算效率的大幅提升，简单总结就一句话：IO优化。不管是存储，还是计算的优化，都是更少的磁盘IO，更多的内存IO。本文结合本人在自身工作中的经验，主要讲一下对大数据计算效率上的一些思考。