JAVA的数据计算层主要是为了降低应用层和数据持久层之间的耦合度，分担他们的计算压力。应满足以下特点：java数据计算层的5种解决方案1.可以统一计算来自任何数据持久层的数据，不仅包括数据库，还包括非数据库的Excel/Txt/XML。其中，最常见的结构化数据的计算是重点。2、可以统一进行不同类型数据源之间的相互计算。它不仅包括异构数据库之间的计算，还包括数据库与非数据库之间的计算。3、数据库与计算层、计算层与JAVA代码的耦合度尽可能低，便于移植。4.可以是非JAVA架构，但必须能方便地与JAVA集成。5.开发效率高，包括脚本编写、可读性、调试、日常维护。6、复杂计算对象和大数据计算是大势所趋，数据计算层应能直接支撑。考察了五个数据计算层：Hibernate、集算器、SQL、iBatis、R语言。考察的指标包括：成熟度、低耦合、脚本化、集成度、界面友好性、性能、复杂计算、大数据支持、非数据库计算、跨数据库计算、调试便利性。HibernateHibernate是由GavinKing创建的轻量级ORM框架，现在归JBOSS所有。是非分布式环境（内网）中优秀的数据计算层。它具有彻底的基于对象的访问方式，而集算器和iBatis只能算是半对象或类对象。Hibernate几乎完全解耦了计算脚本、JAVA代码和数据库。但是计算能力的不足使得它在很多地方仍然依赖于SP/SQL，这是一个比较尴尬的问题。另外，EJB的JPA属于数据计算层协议，但考虑到Hibernate才是真正的JPA，就不介绍了。成熟度：4星。经过10多年的市场考验，Hibernate已经非常成熟。低耦合：4星，这就是Hibernate的原因。但是nativeSQL还是不可避免，很难完美移植。脚本：2星。Hibernate的计算方式有对象引用和HQL，前者最简单，我给5星；但后者比SQL更难学，调试难度极大，开发效率不如SQL，2星；另外，有些计算还是要依赖SQL，2种语言混用，难，给2星。平均3星。整合：2星。Hibernate是纯java架构。只需要复制jar包和N个映射文件，利用好session。上手相对容易。但是控制Hibernate的缓存是必修课，对架构设计能力要求极高，不建议普通程序员学习。当然，ORM的这种先天缺陷在其他数据计算层是不存在的。界面友好性：0星。Hibernate有一个对象生成器；但它缺少最重要的HQL图形化设计界面，也就是说没有GUI。性能：3星。支持三级缓存，虽然肯定不如SQL，但根据我个人的经验，其综合性能达到了SQL的60%。复杂的计算：0星。不支持复杂的计算。需要依赖SQL/外部工具来实现。大数据支持：1星。不直接支持Hadoop体系结构，但有人正在研究它。非数据库计算：0星。不直接支持非数据库计算。跨数据库计算：0星。不直接支持库之间的计算。每个HQL只支持一个库。易于调整：0颗星。很难调试，对于程序员来说，是致命的。esProcesProc是最近兴起的一种新型JAVA计算层，擅长复杂、跨库的计算。与其他数据计算层不同，集算器只使用SQL作为数据源，获取数据后的计算与SQL无关。PJA/hibernate被迫开放SQL接口来实现自己无法处理的计算。成熟度：1星。上市才一年，应用的广度和深度都不及其他数据计算层。低耦合：4星。脚本独立于数据库和Java代码，算法与具体数据库无关，耦合度低。可以很容易地移植到不同的数据库。因为输出接口是JDBC，所以也可以方便的移植到报表中，这是其他数据计算层所不具备的。脚本：4星。脚本写在网格中，可以通过单元格名称调用单元格，可以直接观察每一步的计算结果，将复杂的目标分解成简单的步骤。但是它的语法偏向对象引用（而不是对象），这与SQL偏向描述语句的风格不同，所以需要学习。但是很难说JAVA程序员喜欢哪一种。集成度：5星。集算器为纯JAVA架构，输出JDBC接口，集成无需学习。使用过任何一种数据库的程序员都可以毫无障碍地使用它。界面友好性：4星。独立的图形编辑器，易于使用和直观。但是帮助系统不够友好。性能：2星。全内存计算，数据量不宜过大。复杂的计算：5星。这就是集算器出现的原因。非数据库计算：3星。支持Excel/Txt，但不支持xml或webService。大数据支持：4星。可以访问HDFS，同步号称支持并行计算，具体细节不太了解。跨数据库计算：5星。集算器的语法与具体数据库无关，天然支持跨数据库计算。易于调整：5颗星。调试功能完善，使用起来非常方便，可以观察到最细粒度的计算步骤。其他数据计算层远远达不到这种便利。SQLSQL/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、linkserver等中间件勉强支持，但离“自由便捷”的水平还差得很远。易于调整：1星。很难调试，也很难观察到中间结果。最终的计算结果只有在全部执行后才能看到。唯一的办法就是“为调试而编程”，即刻意建立大量的临时表。iBatis：简单、敏捷因而功能强大的数据计算层。不像Hibernate，它鼓励写SQL，所以学习成本是最低的。同时以最小的成本实现了计算脚本与JAVA代码的解耦，仅用20%的成本实现了hibernate80%的功能。还有20%没有实现的是计算脚本和数据库的解耦。复杂的计算环境是它的弱点，如：分布式计算、复杂计算、无数据库计算、跨数据库计算等。成熟度：4星。iBatis经过了十多年的市场考验，是我最喜欢的框架之一。但是缺乏对缓存的支持仍然是一个缺陷。低耦合：2星。SQL可以无缝替换，但它仍然是数据库特定的SQL。其实后者是数据库的问题。厂商要粘客户，所以SQL不兼容，让你迁移困难；但程序员不想被卡住，坚持迁移。脚本：3星。它是SQL。集成度：4星。基本没什么难度，初学者半天就能掌握。界面友好性：4星。没有图形化的计算流程设计界面，但可以借用SQL工具。性能：3星。性能略低于SQL，主要是resultSet和map/list之间的转换时间稍长。另外，缓存支持不如hibernate。总的来说，两者之间没有太大区别。其实我认为引入ORM的同时引入性能问题是失败的。复杂的计算：3星。和SQL一样，比hibernate强。大数据支持：1星。与SQL非数据库计算相同：1星。同SQL跨库计算：1星。与SQL调试便利性相同：1星。和SQLR语言一样R语言不容易和JAVA结合，但是强大的计算能力和广泛的社区支持，还有大数据的特性让我不得不提。此外，跨库计算、非库计算、模型计算也是它的强项。当然，在各种数据计算层中，它也是最难学的。成熟度：5星。R语言的历史仅次于SQL。无数社区都在谈论R。尤其是在大数据时代。低耦合：4星。R语言和集算器在这方面没有区别。脚本：3星。在这一点上，R与集算器非常相似，不同的是集算器更敏捷，代码更灵活，支持更专业的结构化数据，而R内置了大量的模型算法。所以基本上是平的。整合：1星。R不是JAVA架构，很难融入JAVA。性能不高，集成后性能大打折扣。界面友好性：3星。有专门的IDE界面，但是很粗糙，实用价值不大。这也是开源产品的通病。性能：2星。全内存计算难以应对大量数据。复杂的计算：5星。类似于集算器。大数据支持：3星。R和Hadoop之间有组合机制，但是JAVA系统和非JAVA系统之间的组合并不容易，性能损失比较大。非数据库计算：5星。类似于集算器。跨数据库计算：5星。类似于集算器。易于调整：2星。勉强算是一个调试功能，但是很不专业。
