集算服务器解答.docx

集算服务器：助力大数据高性能计算集算服务器定位与理念集算服务器是在集算器基础上发展出来的大数据计算引擎。大数据在技术上的本质是高性能问题，即如何能计算得更快。常用的方案有内存化、多线程并行、分布式集群等，以及索引、有序利用等技术手段。而集算服务器即面向结构化数据提供了这些常见的算法类库。集算服务器是众多大数据计算方案中的一种，它有适合的场景，不可能也不打算解决大数据的所有问题。集算服务器重点面向如下两类的应用场景：在线报表查询这类场景的数据量并不算很大，运算的复杂度也不算高，涉及步骤较少，但常常需要秒级的响应，而且伴有多并发的情况。随着数据量的增大，简单基于传统数据库的运算机制难以获得即时的响应速度了。在线报表查询一般需要采用内存化技术来实现。离线数据准备这类场景的数据量大得多，涉及大量外存计算，运算的业务逻辑也很复杂，步骤多，但一般没有并发需求。复杂外存运算很难用SQL和存储过程写出高效代码，开发和运行效率都低，大数据量处理耗时过长，会导致窗口时间不够用而影响下一轮的业务应用。离线数据准备常常需要引入可横向扩展的并行计算方案。集算服务器是个技术型产品，它以程序设计语言的形式提供了一些大数据运算需要的类库和方法，其中并没有行业分析模型，需要程序员进一步开发才能形成应用级解决方案。集算器也没有机器学习和数据挖掘算法，用它写出的某些算法可以理解为数据挖掘的某种应用，但本身算不上数据挖掘产品。集算服务器将设计计算方案的自由留给程序员，它提供各种计算类库（某些方法甚至相互矛盾而不可同时使用的），程序员可以根据计算任务和数据的特征设计计算方案，这样可能获得最优性能，但会导致透明化程度较低，程序员需要对数据物理存储和运算过程中数据变换都有深入的了解。集算服务器不是（集群）计算框架，其重点在于提供类库，应用框架和计算流程由程序员决定，无论采用何种框架，这些底层的基础计算方法总是需要的。特别地，集算服务器几乎没有集群框架,程序员可自由决定每个集群节点的计算任务和数据分布，这样能带来更高性能，但也会导致更多更细致的工作量，因此适合于中小规模的集群甚至单机，而不适合大规模集群（此时需要采用统一的管理方式），从这个意义上讲，集算器是个轻量级大数据解决方案。Hadoop和SQL说到大数据技术，就不能不提Hadoop。集算服务器没有基于流行的Hadoop体系，完全是自己的并行和集群机制。为什么不用Hadoop呢？Hadoop的优点很多，但这里主要谈谈其缺点，也就是为什么没采用Hadoop的原因。Hadoop是个庞大的重型解决方案，虽然软件本身开源免费，但要配置好并把它的众多功能都用好，产生的维护支持成本并不低。Hadoop产品线丰富，这是好事情，但相互依赖性又进一步提高了维护成本。Hadoop的设计目标是几百几千的大规模集群，这个规模下随时可能有设备故障，Hadoop投入了相当多资源用于解决容错，这非常必要。但从这些意义上讲，Hadoop是个高端产品，并不很适合普通用户。我们希望搞个轻量级的东西，从单机到集群都可以适用，面向几到十几最多几十的中小规模集群，对其它产品和技术的依赖性很小。这个规模的集群也不需要太强的容错能力，但要强调自由度而换来更高的性能。Hadoop有明确的框架体系，程序员只能去适应，这样会限制程序员的灵活性，难以写出适应业务和数据特征的代码。比如想控制HDFS的文件冗余方案，我们后面会谈到特定的冗余能有效地减少网络传输量，这也许能够通过修改源码实现，但并不轻松，而且随意修改源码会影响升级。再比如MapReduce为了容错把任务拆得太碎，且无法直接控制执行次序，这样导致许多序运算描述困难。集算服务器的思路则是提供类库，无论程序员要怎么做，总需要一些底层的基础方法，那么我们就写出来让程序员去调用。集算器几乎没有框架，流程由程序员用代码控制，不象MapReduce那样只要填空，这样可以充分利用业务和数据特征去编码。Hadoop是个相对封闭完整的体系，要应用它的计算方案需要先数据置于Hadoop之内，Hadoop不能计算关系数据库或其它网络文件系统中的数据；而集算服务器则是个单纯的计算方案，相对来讲更为开放，可以计算包括HDFS之内的各种数据，作为纯Java产品，也可以被Hadoop的技术方案集成。MPP技术让SQL在大数据时代再次找到了机会。SQL语法的透明程度更好，程序员无须关心数据物理存储方案，但过于自动化的方案也会导致难以根据数据和任务的特征优化控制计算过程的细节。集算服务器没有提供SQL风格的语法，需要程序员了解数据存储方案才能写出正确高效代码，好处是可以根据任务特征局部计算的每个步骤，充分利用硬件资源。做SQL解决方案的厂商很多，有些已经做得很好，包括Hadoop阵营内也有几家，能在SQL机制下顺利解决的问题（难度和性能）已经有足