【转】使用Storm处理事务型实时计算需求时的几处难点

http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html

接触流计算领域不长时间，对这个领域可以说还是个门外汉。最近在做实时计算相关的应用，简单说下自己的感受，以后再展开来讨论。
比流量或者订单淘宝可以把我们甩出几条大街。淘宝的兄弟可以自豪地说他们的实时应用已经承受住了双十一全世界范围内最大的单日数据流的冲击。而阿里巴巴中文站的流量和订单与淘宝相比则少的可怜。同时B2B自身业务又存在不同的特点，我们的客单价和笔单价要高得多，因此对于实时数据的误差是零容忍的（比如丢了一个几百万的单子，那实时数据就没有参考价值了）。
所以中文站的实时应用的特点是零误差，事务性，故障可恢复。
在开发实时应用的过程中，我发现当实时计算需要保证数据完全不出错的时候，逻辑就变得复杂起来。效率和精度本身就是不可兼得的。
1、假设实时应用在运行的过程中服务器突然宕机，或者应用需要重启。当应用重新启动时要能够载入应用停掉时刻的状态。虽然我使用的Storm框架可以保证数据流的失败重发，但是数据计算的一些中间状态还是必须要持久化下来。例如计算UV，如果不持久化保存会员ID或cookie ID，就无法做去重处理并得到最终的UV。而流计算一旦要做涉及到磁盘I/0的持久化操作，效率必然会大打折扣。
2、持久化操作带来的另一个难点是保证事务性。例如我们要将数据写入到数据库，当写入多个表时一定要保证多表的数据同时commit，否则当应用异常中断重新从数据库中载入中间状态数据时，由于数据库中的数据不一致就会导致最终计算结果的错误。当然，对于传统关系型数据库来说保证事务性是小菜一碟，但是对于一些分布式数据库或者NOSQL数据库（例如Hbase）来说保证事务性并非易事甚至是做不到的。
3、当数据量大到一定程度时就要使用并发，当并发需要考虑容错与事务性时处理逻辑又会变得复杂起来。在Storm中，每个bolt可以启动多个task，每一个task会有一个唯一的task ID。当需要持久化操作时，每个task必须把自己的中间状态连带自己的task ID一起持久化下来，而在故障恢复时，每个task只从数据库中读取属于自己的状态数据，否则很容易导致内存溢出。再加上有些业务逻辑要求多个task的数据必须在数据库中一起commit，这又增加了复杂性。
4、如果在使用并发时想动态地调整并发数，那需要增加很多额外的处理逻辑。因为Storm默认的fieldsGrouping是根据并发数进行Hash计算取模。如果并发数变动，那么每个数据流应该分配到哪个task中也就发生了变动。在故障恢复时，如果并发数发生了变化，每个task的task ID也会发生变化，这会导致一个task从数据库中读取不到本来属于自己的那部分中间状态数据。这时需要采用一致性Hash策略来解决该问题。
5、Storm处理事务性应用时是按照batch来接收和处理数据的。当一批数据跨在两天的交界处时，一批数据中既有前一天的数据，又有后一天的数据。如果应用是按天为维度来计算的，就要保证不能把前一天的数据算在后一天里面，也不能把后一天的数据算在前一天里。例如计算一天的GMV，理论上讲，因为数据存在延迟，当bolt接收到第二天的订单数据时，自己的服务器时间也应该是第二天。但是有可能不同的服务器时间存在误差，一个bolt有可能接收到在自己看来不是当天而实际上是当天的订单，这在程序处理时也应该考虑，否则就无法保证数据零误差。
总之，阿里巴巴中文站的特点是流量与订单量小，但是客单价与笔单价大，实时计算如果不能保证数据准确性，计算结果与实际结果将产生比较大的误差，失去应用价值。为了保证数据准确性，就要牺牲一定的性能。同时，B2B的业务与市场正在迅速地发展，流计算所需要处理的数据流也会成倍地增长，因此我们必须不断寻求与优化算法与策略，在精度与性能两方面把握平衡。