java数据计算层的几种解决方法2

2、SQL
    SQL/SP/JDBC在这里属于一类，这是老牌的数据计算层，性能和灵活性是它的优势。但随着新情况的不断出现，单纯用SQL已经难以满足需求，比如： JAVA开发规模的扩大，数据量的剧增，复杂计算问题的涌现。虽然SQL得高分的指标不多，但都是权重最高的。

    成熟度：5星。最成熟的。
    低耦合性：0星。耦合性极高。除了在实验室之外，几乎不可能写出与数据库无关，与代码无关的计算脚本。

    脚本编写：3星。SQL实际很难写出也很难维护，需要大量的时间去学习，好在SQL非常成熟，资料丰富论坛很多。但各种数据之间的不兼容也是个巨大的障碍，这是Hibernate之所以流行的主因。
    集成：5星。JAVA程序员的第一课就是用JDBC连接数据库。
    界面友好性：5星。有大量的SQL开发工具，成熟度都很高，我自己用过不下10种。
    性能：5星。数据库直接支持的语言，性能最高。
    复杂计算：3星。SQL适合普通的计算问题，可以解决复杂问题但非常困难（而Hibernate是完全不能）。SP的出现并不能有太大的改善。代码难以拆分，复杂目标难以分解为简单步骤是主因。
    大数据支持：1星。个别数据库厂商表示已经支持大数据了，但这让SQL语句的不兼容程度加剧了，而且我也没见过成功案例。
    非数据库计算：1星。不直接支持。采用ETL/数据仓库可以达到这个目的，但代价巨大。
    跨库计算：1星。个别数据库支持，但性能较差，也可以采用DBLink和link server等中间件勉强支持，但离“自由方便”的程度还差得远。
    调式方便性：1星。很难调试，难以观察中间结果，只能全部执行完才能看到最终计算结果。唯一的办法是“以调试为目标进行编程”，即刻意建造大量临时表。

3、集算器
    最近在研究的就是这个，号称擅长复杂、跨库的计算，跟Cloudera在2012年发布了impala 1.0 beta版（开源）类似。和其他数据计算层不同，集算器只是将SQL作为一种数据源，而取到数据后的计算则完全和SQL无关。PJA/hibernate则被迫开放SQL接口，用来实现自己处理不了的计算。

    成熟度：1星。在市场出现仅1年，应用的广度和深度都不如其他数据计算层。
    低耦合性：4星。脚本独立于数据库和Java代码，算法和具体数据库无关，耦合性低，可以轻松移植到不同的数据库。因为输出接口为JDBC，所以也可以移植到报表，这是其他数据计算层所不具备的特征。
    脚本编写：4星。脚本写在网格中，单元格可以按格名调用，可以直接观察每一步的计算结果，复杂目标可以分解为简单步骤。但它的语法偏向对象引用（但不是对象），与偏向描述语句的SQL风格不同，需要学习。JAVA程序员到底喜欢哪一种，还很难说。
    集成：5星。集算器是纯JAVA架构，输出JDBC接口，没有学习成本，用过任何一种数据库的程序员都可以无障碍使用。
    界面友好性：4星。独立的图形化编辑器，使用方便直观，但帮助系统不够友好。
    性能：2星。全内存计算，数据量不能太大。
    复杂计算：5星。这是集算器出现的原因。
    非数据库计算：3星。支持Excel/Txt，但不支持xml或webService。
    大数据支持：4星。能访问HDFS，同步宣称支持并行计算，但细节还不太了解。
    跨库计算:5星。集算器语法与具体数据库无关，天生支持跨库计算。
    调式方便性：5星。调式功能完善，而且使用非常方便，可以观察到最细粒度的计算步骤。

    现在在做性能测试，看表现如何。