卫星影像处理中间件开发报告

项目简介

同济的同学有一个分析卫星遥感图像的科研项目，他为图像的分析设计了一种新的算法，能够推荐原先的研究。他的算法是用Matlab实现的，涉及一些矩阵的运算。Matlab的计算在图片尺寸较小的时候运行比较顺利，但当图片超过100x100 pixel, Matlab就无法计算，因为它需要的数据都是单机内存存储的，无法适应更大的数据规模。为了解决这个问题，我利用HBase开发了一个存储中间件，可以利用一个集群来运行同学的算法，从而扩大运算规模。

方法的分析

首先想到的方法是用MIT的chord。这是一个能够快速扩容的键值存储协议，chord的逻辑负责存储调度和结点管理，外部的算法可以运行在一个实现了chord的系统之上。MIT的论文中提到了chord在实验条件下的性能：在结点不断增加的情况下系统延迟只增加 O(log2n) .

我先用了一个星期时间开发了一个一致哈希系统（chord的前提条件），发现从底层开发起的复杂调度和管理已经超出问题所在的范畴，如果使用chord的话，这个中间件的开发可能需要好几个月的时间。

使用chord是有它的优势的。首先当然在开发过程中我能够学到非常多的东西，结束以后对于分布式系统、对哈希算法肯定有自己独到的见解；其次对于性能而言，如果今后的计算规模继续扩大，一个可行的chord系统能够迅速调整，而其他的系统则需要更多的修改；现在市面上的各大服务器屡屡由于过多的访问而崩溃就是这个原因。

HBase提供了一种只需要关注业务逻辑的方式来解决问题。仔细阅读HBase文档以后我发现我第一次阅读就能只用半天时间搭建好一个分布式的存储系统，业务逻辑的加入也非常简单。Lamport的系统开发论文里对于程序员的第一个建议就是Keep It Simple.

同时HBase的弱点也存在，它是一个master-slave的系统架构，对于master的要求非常高，实际上每个机器的崩溃概率都是差不多的，所以不当地赋予某个结点过多责任是一种降低系统可靠性的做法。

方法的选择

选择HBase的理由很直接，就是因为它简单。我在一天之内就完成了安装配置HBase和业务逻辑的集成。很少的功夫就能够完成一个分布式系统的搭建，这是非常有效率的一种方法。开发过程中的反馈是非常重要的，这也是近些年大家推崇敏捷开发的原因，周期要短，反馈要多，HBase的使用很显然符合这种标准。

那么如何克服HBase的弱点呢？它本身架构不是最优的，但是要实现chord这要完全decentralized的系统，分布式系统的知识要求是非常高的，而master-slave结构是一种比较直观的方式，所以把HBase的搭建当成一种锻炼也无妨，这对于实现chord只有好处，而且要实现chord，这种master-slave系统开发的练习也是必不可少的。

系统如何使用

系统开源，代码在这里. 此中间件主要支持两个操作：

1. 遇到新的图片，处理这个图片，用集群去存储计算好的数据
2. 提供数据查询的接口

在com.puzhen.visionstorage.main.ImageProcessBO 类中，我们使用 process(Image image) 来处理图片并存储，用户可以用getDistance(SimplePixel pixel1, SimplePixel pixel2) 方法来提取计算好的数据。

Image 类是我自己定义的数据格式，和实际上的png或者jpeg图片有一些出入，具体应用的时候需要调整一下数据.

SimplePixel 是我用来封装所有跟某个pixel有关信息的一个类，有些像素点会有多个维度的数据，所以需要一种合理的信息保存方式。SimplePixel 默认该像素点只有3个维度，具体工作需要拓展该类。

未来能做什么工作

在卫星定位中，目前存在着大量的数据需要计算，但受限于内存与单台计算机的运算量限制很多数据闲置无法利用。受pixelValue的存取的启发。

我们可以尝试这样的事情：在slave上部署我们的算法，通过master对固定大小的数据量作为package map到slave上进行计算并将结果返回到master上进行管理与后续的组织和使用。

这样子同时使用了闲置计算机的计算能力和内存，当然这是在我们的机房有很多计算机闲置的基础上。