distributed online HB updating

姑且叫之前的在HB中对candidates的处理算法叫做local HB updating。

对于分布式的online HB updating，有三个难点：

1、unknown cluster evolving

由于data是增量式到来，无法知道下一时刻的clustering结果，所以clusters的演化情况是未知的，因此不能使用star partitioning。
针对这一问题，暂时想法是每次对新到来的data做聚类，然后，中心节点上将每个new cluster与各个nodes上的candidate做快速匹配，将new cluster分配到对应的nodes上

2、space cost

涉及两个子问题：1）每个candidate能存多长时间的data在machine node上；2）每个node上能存多少个candidate？
针对这一问题，暂时想法是对candidate采取summary的结构，这样每个candidate所需的字节少，且所需字节数差不多。因此，可以将a candidate summary 作为一个存储单位，既能节省空间，又方便计算。

3、load balance

怎么保证负载均衡，不至于有长尾现象？
针对这一问题，可以转化为平衡每个node上存储多少个candidate summary的问题。暂时想法是对于每个时刻的new candidate，分配到candidate summary少的nodes上去。

distributed online HB updating初步算法的流程：

1、t=0时，先聚类，生成的每个结果聚类都是一个new
candidate，初始化它们的summary结构，此时的所有candidates的object group都无交集，因此相互独立，然后将其平均分配到各个node上；

2、t>0时，先聚类，中心节点对new clusters与candidates on nodes作快速匹配，匹配上的new cluster进入对应node，执行local HB updating算法。未匹配上的new cluster成为new candidate，初始化summary结构后，分配到比较空的nodes上。

目标：efficiency和scalability

为达到efficiency的目标，主要解决中心节点上new clusters与candidates的快速匹配这个瓶颈问题。拟对数据集中的object采用全局编号，那么在cluster和candidate中只需要记录下object的编号即可。而快速匹配采用哈希表的结构，用core points作为candidates的key，candidate的object group作为value，每个new cluster的core points也是key，只需要匹配key即可。

为达到scalability的目标，主要想法是对各节点上的candidate采用summary结构，所需空间小，便于扩展。