背景

Galaxy是阿里数据平台事业部，实时计算组自研的增量计算框架。今年双十一，阿里直播大屏就是Galaxy支持和保障的重要业务之一，相信大家可能看过双十一之后网上一些介绍性的文章了，比如阿里研发实时计算平台 每秒运算量将超千万，不过这篇文章面向非技术人员，最后的比喻也是有点醉。还这篇比较新的 阿里巴巴实时数据公共层助力双11媒体直播。
本文我会介绍一些我认为可以公开出来说的galaxy技术上的特点，让技术人员对该计算框架有个更准确的认识。

计算模型

首先明确根本的一点，Galaxy是增量计算模型，不是"简单"的流计算，这点在业界是没有的。增量计算是有状态的计算。批量计算里，每一次的输出结果只与本次全量扫进来的数据有关，而且计算是幂等的。增量计算，每批计算结果，是由本批数据和历史批次结果计算出来的，即newValue = function(currentBatchValue, oldValue)，然后本批计算出来的newValue会作为oldValue参与下一批数据的计算中。这个公式看起来与迭代计算相似，实质上，迭代计算是增量计算的一种。
下面说明流计算与Galaxy的关系。

Galaxy与Storm

网上对Galaxy有过了解的技术朋友，包括阿里内部的同事，可能会认为Galaxy只是Storm上的一层封装。在这里，我严肃地告诉大家，只要你动脑子想一想，绝对不是的，不但不是封装，而且与Storm有本质区别。
Storm是流式计算，数据流进，经历拓扑计算，数据流出，与增量模型没有半毛钱关系。如果真要类比storm和galaxy，大家可以想一想Trident。trident是storm上的封装，暴露接口让用户可以操纵state，如此，批与批之间的计算结果的确可以通过state持久化起来了，并且可以参与下一批的计算，这看上去与galaxy做的相似。但还是有一个本质区别，trident的state不是它能掌控的，说白了，你state是额外的辅助存储，不是与我这个引擎挂钩的，而Galaxy中的state是与整个计算框架关联起来的，这点太重要了，而且实现起来是很复杂的。
再说为什么现在的galaxy版本需要依赖storm。galaxy目前旧的版本还是跑在storm上的，借助storm的拓扑拉起，worker调度和消息传递。galaxy只是需要一个能够拉起worker，传递消息或者作RPC的引擎而已，storm是当时一个的临时选择。目前，storm引擎已经不再适合galaxy，无论是其拓扑构建和拉起的耗时，还是拓扑的不可变性，或是消息格式及序列化方面的性能等等种种问题，都不再适合galaxy，而仅仅适合于流计算。所以，将来galaxy的引擎，不会是这样。

Galaxy的未来

简单说几点Galaxy的想象空间。
现今Spark可以做的场景，Galaxy都是可以做的，而且Galaxy在性能上至少是准实时的。Spark的RDD代表了使用上的易用性和计算上的reuse数据。Galaxy同样有增量语义，表达能力同样强大的算子层和增量计算模型天然引入的数据reuse。
Galaxy的计算模型在业界是没有的，其计算场景覆盖了流式计算，迭代计算，还可以轻松愉悦地做BSP模型。

全文完 :)