对Java数据处理技术再探究.docVIP

对Java数据处理技术再探究 　　摘 要：得益于数字技术、存储技术与互联网技术的综合发展与推动，信息数量以几何式增长，标志着大数据时代来临。在笔者已经拥有了对 Java数据处理技术的基本认识的基础上，进一步探究提高对数据的“加工能力”，通过“加工”实现数据的“增值”。探究的聚焦点是求解大数据的拆分和合并中将会遇到的比较典型的问题及其解决办法。 　　关键词：Java数据；加工能力；增值能力；处理技术 　　当今时代，伴随着数字化技术及网络技术的迅猛发展，信息的传播与存储媒介不断更新，并进一步趋于科学化、合理化发展，伴随而来的是信息数据数量的爆炸式增长，big-data时代（大数据时代）正式到来。信大数据的拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，如果拆分合并的数据量在我们可以控制的范围内，文件中的数据最终是可以组织的，那么在数据需要拆分与合并的时候，就不要按照数据逻辑行数来做了，因为行数最终需要按照解释数据本身来判定，仅仅只是做数据拆分处理是没有必要的，这时需要的是二进制处理，在这个二进制处理过程，需要特殊进行和平时读文件不能使用一样的方式，通常对一个文件读取只是用一次读操作，如果对于大文件内存不够大的会导致内存溢出错误，此时应该在每次读取一个可控范围的数据，读方法提供了重载的offset和length的重要数据范围，要根据读取文件大小进行拆分数据量计算，写入大文件和上面一样，要读取到一定程序就要通过写入流flush到磁盘；其实对于小数据量的处理在现代的NIO技术的中也有用到，比如多个终端同时请求一个大文件下载，视频下载，在常规的情况下，都可以用java的容器来处理，可能会发生两种情况： 　　最为常见的情况内存溢出，因为每个请求都要加载一个数据文件的内存甚至于大于其内存，因为Java包装数据的时候会产生额外的内存开销，如果使用二进制会减少这类情况的出现，而且在经过输入输出流的过程中还会发生多次内存复制现象。如果使用nginx之类的中间件去出来情况会好很多，那么可以通过send_file模式将二进制数据文件发送出去，但是如果你要用程序来处理的时候，除非内存足够大，但是Java内存再大也会有内存溢出的时候，假设服务器内存真的很大，发生GC的时候情况会更糟，当然这个地方也可以考虑自己通过直接内存的调用和释放来直接处理数据文件过大的情况。需要追求求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率。 　　现在假设内存足够大，无限制大，此时的限制数据文件操作的就是线程问题，传统的IO模型是线程是一个请求一个线程，这个线程从主线程线程池中分配后，就开始按照预定方式工作，经过Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程中线程都是被挂住的，所以这时候系统资源非常有限，如果是大数据处理是属于IO密集型的数据处理时，大量的CPU时间是空余的，系统方法最直接的情况当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般情况一个进程的线程池一般会受到限制也不建议过多申请，而在有限的系统资源下，要提高性能，可以使用有了New IO技术，也就是NIO技术。新版的里面又有了AIO技术，NIO只能算是异步IO处理技术，但是在中间读写过程仍然是阻塞的，还未做到真正的异步IO，在监听数据连接的时候他是不需要很多线程参与的，有单独需求的线程去处理，连接也又传统的socket变成了selector。对于不需要进行数据处理的是无需分配线程。AIO不同于NIO技术，它通过回调注册来方式对数据进行处理，当会调的时候会才去申请线程，目前还不是很成熟的技术，相信随着技术发展完善，AIO必然会超越NIO。目前谷歌V8虚拟机引擎所驱动的node.js就是类似AIO的模式，有关这种技术是本文不进行更详细的说明。 　　结合上述两种情况就是要解决大数据处理，还要并发综合考虑，比较简单的方法是将数据文件进行可能小的分割处理，8K这个大小是经过验证网络传稳定的容量。本地进行数据处理不需要处理的这么小，可以选择一定程度的本地缓存，将多个请求的一样的数据文件，缓存数据在内存或分布式缓存中，不用将整个文件调入在内存中，缓存调用几秒左右即可，也可采用一些算法配合缓存，减少数据处理时系统资源的压力。迅雷下载的断点续传中处理下载数据的时候未必是连续的，只要下载完成后可以将数据文件合成即可。在服务器端数据处理方式相反， 那里需要系统资源可以用NIO后，这样能支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时发送数据连接请求一个线程的服务器，正常的数据相应是按照顺序来完成，一个一个排队