flume写入hdfs文件碎片化的问题

上图可以看到hdfs的块大小是128M，但是实际文件却很小，这种方法肯定有问题。
查看flume的配置

agent1.sinks.sink1.type=hdfs  agent1.sinks.sink1.channel=channel1  agent1.sinks.sink1.hdfs.path=hdfs://dashuju174:9000/flume/%{application}/%{dir}/%Y%m%dagent1.sinks.sink1.hdfs.fileType=DataStream  agent1.sinks.sink1.hdfs.writeFormat=Text  agent1.sinks.sink1.hdfs.rollInterval=0  agent1.sinks.sink1.hdfs.rollSize=10240  agent1.sinks.sink1.hdfs.rollCount=0  agent1.sinks.sink1.hdfs.idleTimeout=60 

按照flume-ng 写入hdfs上后出现一个文件被分割了很多个小文件在hdfs上的进行操作，并没有解决我的问题。
翻阅《Flume构建高可用、可扩展的海量日志采集系统》中Sink章节，HDFS Sink支持三种方式，一种是基于时间分桶，一种是基于写入事件的数量，一种是基于文件中事件主题的总大小来滚动文件。
文章明确指出，当使用基于时间的分桶，有可能在某个固定的时间点之后，就不会有事件再写入到bucket。如果对于文件关闭了启动滚动间隔，这样的文件可能从不会被关闭，所以使用hdfs.idleTimeout，单位为s，它表示在最后一个事件写入文件之后关闭文件要等待的秒数值事件。
解决hdfs碎片化的问题，也就是屏蔽掉agent1.sinks.sink1.hdfs.idleTimeout=60这个配置就可以了。实测可行。
接下来的问题是 rollSize大小如何配置才合理，HDFS block size的大小是128MB，我上面做的配置是10M，那么两个配置数据调整多大才合适呢？网上和书上并没有对此直接的说明，直觉接近128M为宜。比如100M。
基于文件大小的方式，适合非实时的数据采集，比如系统操作日志之类，对时间要求不高的场景。
在实践过程中，例如flume的拓扑结构中操作flume的集群，发现一个问题，如果其中的一个flume节点宕机后，会产生新的tmp文件，那么如果去掉idleTimeout的配置项，那么这些文件就无法关闭掉了。
那么合理的配置又是什么呢？最终还是回归到根据时间来推算，这样比较方便。