大量csv数据的查询和计算的技术实现路径分析(2)-HDFS存储查询探讨2
上一篇讲了java split的使用弊端，虽是字符串处理中一个很小的操作，不过却避不开。接下来，主要探讨HDFS存储查询方面的问题和解决思路。
随着每天的业务运作，每天会生成很多csv文件，目前csv文件存储在hdfs文件系统里面。在使用csv文件数据时，遇到一个问题:
如何高效查询HDFS中的csv数据？
基于HDFS文件系统的特性，笔者经由以前的探讨和一些资料，作了一些思考，如图：
首先，这是一个复杂的问题。以笔者的能力水平，不能完全吃透它。那么，在笔者能实现的前提下，来分析一下哪些可以重点分析的。
第一，HDFS的配置优化。这个网络上相关的资料很多，hadoop官网上也有相关文档。所以，这里不提。
第二，网络IO，磁盘IO是比较关键的指标，HDFS的读写好坏是依赖于磁盘性能的，而且，hadoop通信，数据传输，网络IO第一关注点。具体的优化同上条，网络上有很多资料的。
第三，变量还是很多的。比如文件数量，文件平均大小，读写并发量等等。作为分布式存储系统，文件数量肯定很多。所以这里不提。实际上，根据笔者的看法，这里要分析的优化项有3点：
- 如何处理随机查询？
- 文件读取效率优化
- 缓存的优化
不同于互联网日志、流式数据，csv文件更像大块头。这些文件大小不一，范围在几十M到上千M。这也不能算是小文件，照搬类似于互联网数据的处理策略，效果可能会差很多。
之前的可能处理思路中，有这么几种：
（1）文件路径等信息存数据库。
（2）规避查一次，读一次文件，做了一个临时缓存。
（3）每生成一个csv文件，将csv数据全部存进hbase。
（4）使用多线程缓解多人相近时间点请求的问题。
（5）使用spark dataFrame列式读取。
一个csv本来就具有几十M大小，估算下，大概有几万行记录，如果就这样存进hbase，显然不合适；存进临时缓存，相信也放不了几个。所以缓存放csv的索引信息比较合适。对于用户请求的一般习惯，最近的数据请求频率相对比较大，所以可以把最近1-3个月的csv索引信息放进缓存；除了时间上，还有用户查询频次上，对于某些类型的文件查询频次比较高的特点，这些文件信息也要放进缓存。
spark dataFrame读写很方便，代码量也比较少。可是在与web平台对接时，环境不一样，不方便对接。使用http方式会很慢。
虽然最后使用了一些类似上面的方法，也取得了一些效果，可笔者认为，还有优化空间。
首先，hdfs读写文件的架构：
从图上，可以比较明显看出：
（1）Name Node 在Data Node上进行Block操作，每个block默认大小是64M。
（2）Client可跨机架读写Data Node，操作可以是同步的。
（3）Client和Name Node交互是通过Meta Data 操作。
了解了这些对象的交互流程，针对性的减少Block操作次数；减少Client读写Data Node 数量；减少Client和Name Node交互频率，均可以提高读写效率。
结合以上提出的思路和实践，笔者认为以下几种步骤可以明显提高读写效率。
步骤1（写数据）：
步骤2（读数据）：
虽然理论讲了这么多，得要实践看看实际效果。
实践部分