《结构化大数据计算的理想模式》由会员分享，可在线阅读，更多相关《结构化大数据计算的理想模式（2页珍藏版）》请在金锄头文库上搜索。
1、1 MicroInsight 创新技术提升数据价值北京微视角软件技术有限公司 http:/结构化大数据计算的理想模式随着社会的信息化发展，企业IT 化的不断完善，业务的不断扩展，服务质量的不 断提高，企业数据越来越庞大：如何从海量数据中快速获取自己需要的数据？如何能够 完成越来越复杂的数据计算？在数据仓库和数据库中的数据以TBGB 级增长的时候， 如何能够保证数据查询和计算的高效率和响应度？这些问题都给CIO 带来了严峻的挑 战。 针对上述的问题，包括Teradata 、IBM 、ORACLE、EMC、Apache基金会等众多的 公司和机构，都提出了自己的解决方案。笔者在多年的BI 实施过程中
2、，对上述公司的 解决方案，或多或少都有所涉及，在这里，仅按自己的理解，对这些方案进行归纳和总 结，因为笔者的水平有限，观点难免有错误和片面之处，也希望读者给予指正。 笔者认为：当前数据计算所面临的问题，主要集中在三个方面：第一是数据存取和 数据交换时的 I/O 瓶颈问题，第二是复杂计算模型的完备性问题，第三是数据计算本身 的性能问题。 I/O 瓶颈问题，主要表现在和硬盘的交互以及通过网络输入输出，一般来说使用高 转速的硬盘以及增加网络带宽可以获得一定程度的缓解，大部分情况下不会成为瓶颈。 数据量大到一定程度时可以使用数据库集群，不过数据库扩容成本很高，该方案不是一 个很优的选择。 复杂计算模型
3、的完备性问题，影响的主要是开发效率。程序员一般采取两种方式实 现数据计算： 第一是使用 SQL/存储过程， 众所周知， SQL是结构化查询语言的最小完备 集。但是最小完备集并不是最好用的完备集，SQL的问题有很多：无序集合、集合化不 彻底、没有对象引用等等。虽然在SQL 2003 标准中增加了一些窗口函数，但是扩展的 程度有限，易用性也有限。所以SQL虽然提供了完备的计算体系, 可是开发效率太低。 第二是编程实现或者使用第三方工具。目前市面上很少有第三方工具具备完备的计算体 系，编程则遇到同样的问题：开发效率太低。 数据计算本身的性能问题则是一个最严重的问题。理论上，以存储过程或复杂SQL 来
4、实现计算逻辑是保证性能最好的做法， 数据库有很多优化措施， 且本身是 c语言开发， 可以让计算更快。但是优化总是有限的，数据量大到一定程度，性能终究是个瓶颈。 能有效解决性能问题的唯一办法就是并行计算。目前提供并行计算的产品有两大类， 一类是以 TD、 GreenPlum为代表的 MPP 数据库产品，其优点是计算快，并行算法透明， 缺点是数据库扩容成本太高，每增加一个并行节点则要增加不菲的费用，一般用户承受 不起。 另一类以 Hadoop 为代表的分布式数据处理的软件框架，该方案把数据存储在分布 式文件系统 HDFS 里。HDFS 分布式文件系统很好地解决了IO 问题，并具有很强的容 错能力，
5、是个很优秀的数据存储方案。但是Hadoop提供的并行框架 MapReduce则不敢 苟同了，该框架是为非结构化数据的搜索统计而设计的, 由于本身不提供算法，又没有 现成的类库，导致程序员编写算法难度很高，工作量很大。同时由于MapReduce 框架 把任务拆分得过细， 使得很简单的一个计算任务，需要编写数个 Map 和 Reduce方法来 实现，开发和运行效率都很低。 因此笔者认为，理想的大数据计算模式，应该具备以下特征： 1、计算层独立于数据库和应用程序之外，既不受数据库难扩容的影响，也不受应 用程序的限制。 2、计算层能够访问分布式文件系统（如HDFS 等） ，便于在海量数据时避开IO 瓶2 MicroInsight 创新技术提升数据价值北京微视角软件技术有限公司http:/颈。 3、具有足够完备的计算体系，在编写算法时，有丰富的类库和方法支持，减轻开 发工作量。 4、计算层提供并行框架，并行节点扩充容易，成本低廉。且数据块的拆分比较灵 活，允许程序员根据实际情况随意指定。 5、计算层对外提供标准的数据访问接口, 如 JDBC 等作者介绍：张淳，从 2008年起一直从事 BI 领域数据计算和分析方面的咨询和项目实施 工作。在电信、移动、金融、能源等领域处理海量结构化数据业务方面，具有丰富的咨 询和项目实施经验。现在北京微视角软件技术有限公司担任资深产品支持顾问。
