hadoop文件系统为什么不支持随机写

1:hadoop设计的初衷是大规模数据的计算和olap分析, 应用场景区别与数据库,所以在HDFS设计时候就侧重在一次写入多次读取

2: 假设现在我们在HDFS中加入了随机写.那么为了正确性我们需要保障的东西有哪些?

• 鉴于hadoop设计之初是想在廉价硬件上执行大规模的数据计算,HDFS是设计的必须支持CAP理论之分区容错性(partition tolerance)来抵消不可靠硬件随时会宕机的风险,那么在修改的时候,我们也是需要去namenode查询重新得到需要改写的文件的HDFS数据块的其他备份来修改以保证数据备份的一致性,中间过程增加了文件io和不同数据块备份间的网络io开销,并且在修改的过程中,还需要考虑修改完一个block之后,然后在修改备份block时候的各种异常回退的操作.
• 如果上一条的操作效率跟HDFS写入类似的话,那么在修改数据块数据时,如何保证不被其他试图修改同一个块的用户修改而被迫加锁的性能的损耗,将是一个新增的性能消耗点.这没有删除一个数据,然后重新写入的效率高
• 如果现在数据a在修改过程中(三个备份分别在datanode1,datanode2,datanode3),datanode1上的数据a已经修改成功,datanode2和datanode3还在同步的过程中,如果此时一个读请求由于网络路径比较短选择在datanode3上读取数据a, 此时你是要加锁不让读呢还是提供一个脏读数据呢?如果是第一种情况加速不让读提供强一致性分布式事务,不仅大大降低HDFS性能而且违背hadoop设计的初衷. 如果提供一个脏读数据,为什么不直接删除数据a然后重新插入修改后数据a,让用户有个正确的读取操作呢?

 综上,首先hadoop初衷不是为了修改数据而是侧重查询,其次就是确实是可以实现HDFS修改,但是同时也要付出系统复杂性和性能的代价.这是一个trade-off的选择