结构化大数据计算的理想模式

math3056

随着社会的信息化发展，企业IT化的不断完善，业务的不断扩展，服务质量的不断提高，企业数据越来越庞大：如何从海量数据中快速获取自己需要的数据？如何能够完成越来越复杂的数据计算？在数据仓库和数据库中的数据以TB\GB级增长的时候，如何能够保证数据查询和计算的高效率和响应度？这些问题都给CIO带来了严峻的挑战。

针对上述的问题，包括Teradata、IBM、ORACLE、EMC、Apache基金会等众多的公司和机构，都提出了自己的解决方案。笔者在多年的BI实施过程中，对上述公司的解决方案，或多或少都有所涉及，在这里，仅按自己的理解，对这些方案进行归纳和总结，因为笔者的水平有限，观点难免有错误和片面之处，也希望读者给予指正。

笔者认为：当前数据计算所面临的问题，主要集中在三个方面：第一是数据存取和数据交换时的I/O瓶颈问题，第二是复杂计算模型的完备性问题，第三是数据计算本身的性能问题。

I/O瓶颈问题，主要表现在和硬盘的交互以及通过网络输入输出，一般来说使用高转速的硬盘以及增加网络带宽可以获得一定程度的缓解，大部分情况下不会成为瓶颈。数据量大到一定程度时可以使用数据库集群，不过数据库扩容成本很高，该方案不是一个很优的选择。

复杂计算模型的完备性问题，影响的主要是开发效率。程序员一般采取两种方式实现数据计算：第一是使用SQL/存储过程，众所周知，SQL是结构化查询语言的最小完备集。但是最小完备集并不是最好用的完备集，SQL的问题有很多：无序集合、集合化不彻底、没有对象引用等等。虽然在SQL 2003标准中增加了一些窗口函数，但是扩展的程度有限，易用性也有限。所以SQL虽然提供了完备的计算体系,可是开发效率太低。第二是编程实现或者使用第三方工具。目前市面上很少有第三方工具具备完备的计算体系，编程则遇到同样的问题：开发效率太低。

数据计算本身的性能问题则是一个最严重的问题。理论上，以存储过程或复杂SQL来实现计算逻辑是保证性能最好的做法，数据库有很多优化措施，且本身是c语言开发，可以让计算更快。但是优化总是有限的，数据量大到一定程度，性能终究是个瓶颈。

能有效解决性能问题的唯一办法就是并行计算。目前提供并行计算的产品有两大类，一类是以TD、GreenPlum为代表的MPP数据库产品，其优点是计算快，并行算法透明，缺点是数据库扩容成本太高，每增加一个并行节点则要增加不菲的费用，一般用户承受不起。

另一类以Hadoop为代表的分布式数据处理的软件框架，该方案把数据存储在分布式文件系统HDFS里。HDFS分布式文件系统很好地解决了IO问题，并具有很强的容错能力，是个很优秀的数据存储方案。但是Hadoop提供的并行框架MapReduce则不敢苟同了，该框架是为非结构化数据的搜索统计而设计的, 由于本身不提供算法，又没有现成的类库，导致程序员编写算法难度很高，工作量很大。同时由于MapReduce框架把任务拆分得过细，使得很简单的一个计算任务，需要编写数个Map 和Reduce方法来实现，开发和运行效率都很低。

因此笔者认为，理想的大数据计算模式，应该具备以下特征：

1、计算层独立于数据库和应用程序之外，既不受数据库难扩容的影响，也不受应用程序的限制。
2、计算层能够访问分布式文件系统（如HDFS等），便于在海量数据时避开IO瓶颈。
3、具有足够完备的计算体系，在编写算法时，有丰富的类库和方法支持，减轻开发工作量。
4、计算层提供并行框架，并行节点扩充容易，成本低廉。且数据块的拆分比较灵活，允许程序员根据实际情况随意指定。
5、计算层对外提供标准的数据访问接口, 如JDBC等

作者介绍：张淳，从2008年起一直从事BI领域数据计算和分析方面的咨询和项目实施工作。在电信、移动、金融、能源等领域处理海量结构化数据业务方面，具有丰富的咨询和项目实施经验。现在北京微视角软件技术有限公司担任资深产品支持顾问。