文章目录
前言
在大规模量级的分布式存储系统中,很多时候管理员以及用户都有特定条件的查询需求:比如用户哪个目录文件数据量是最多的?还有对于管理员的需求:哪个节点上存储的文件数量最多,又或者是否存在损坏数据块文件类似种种的问题。因此在大型分布式存储系统中,我们需要有一个能够快速透视,探查里面数据的工具。当然它的功能要远远大于目前文件系统提供的fsck这样的工具命令。对于这种工具,我们可以怎样对其进行设计呢?本文,笔者结合Hadoop Ozone Recon服务,来聊聊里面的一些相关设计思想。
数据探查服务的初始点:元数据的同步
这里需要大家明白一个关键的点,数据探查服务并不是要针对所有的物理数据进行一个个的扫描统计,而只是需要对中心控制节点的核心元数据进行探查分析即可。比如HDFS,那我们专门分析的对象就是FSImage文件。
为了避免对实际生产系统造成影响,我们一般的做法是会从一个Standby的元数据文件进行定期同步,然后对这个同步而来的文件再进行二次分析。当然,有时我们可以做的更高级一些,只有首次同步时进行元数据文件的同步,后面只同步WAL的更新操作,相当于这是Standby的Follower。因为数据探查服务不会对元数据文件进行写操作,所以我们可以让这个文件变为read-only模式的。
对于数据探查的定位,在这里它是一个服务,所以上述的行为应该被纳入到这个服务当中。
数据探查服务的分析:索引结构的重新构建
有时候,针对不同的查询分析需求,如果按照原来元数据文件内的索引构建方式,会导致非常低的效率(比如遍历完全统计),此时我们可以在服务中进行一定结构的转换。比如一种常见的方式:倒排索引的构建,或者带上前缀匹配的支持。或者构建出不同Key对应的不同Value的含义,只要Value是我们所需要的就行。
这里的索引结构的重构建可以和上面元数据的定期同步行为的速率保持一致,以达到准实时更新的效果。