数据之眼 | 数据探查服务的设计

点击上方蓝色字体，选择“设为星标”

回复”资源“获取更多资源本文作者：林意群
原文地址：http://suo.im/5Xcmci

大数据技术与架构点击右侧关注，大数据开发领域最强公众号！

暴走大数据点击右侧关注，暴走大数据！

前言

在大规模量级的分布式存储系统中，很多时候管理员以及用户都有特定条件的查询需求：比如用户哪个目录文件数据量是最多的？还有对于管理员的需求：哪个节点上存储的文件数量最多，又或者是否存在损坏数据块文件类似种种的问题。因此在大型分布式存储系统中，我们需要有一个能够快速透视，探查里面数据的工具。当然它的功能要远远大于目前文件系统提供的fsck这样的工具命令。对于这种工具，我们可以怎样对其进行设计呢？本文，笔者结合Hadoop Ozone Recon服务，来聊聊里面的一些相关设计思想。

数据探查服务的初始点：元数据的同步

这里需要大家明白一个关键的点，数据探查服务并不是要针对所有的物理数据进行一个个的扫描统计，而只是需要对中心控制节点的核心元数据进行探查分析即可。比如HDFS，那我们专门分析的对象就是FSImage文件。

为了避免对实际生产系统造成影响，我们一般的做法是会从一个Standby的元数据文件进行定期同步，然后对这个同步而来的文件再进行二次分析。当然，有时我们可以做的更高级一些，只有首次同步时进行元数据文件的同步，后面只同步WAL的更新操作，相当于这是Standby的Follower。因为数据探查服务不会对元数据文件进行写操作，所以我们可以让这个文件变为read-only模式的。

对于数据探查的定位，在这里它是一个服务，所以上述的行为应该被纳入到这个服务当中。

数据探查服务的分析：索引结构的重新构建

有时候，针对不同的查询分析需求，如果按照原来元数据文件内的索引构建方式，会导致非常低的效率（比如遍历完全统计），此时我们可以在服务中进行一定结构的转换。比如一种常见的方式：倒排索引的构建，或者带上前缀匹配的支持。或者构建出不同Key对应的不同Value的含义，只要Value是我们所需要的就行。

这里的索引结构的重构建可以和上面元数据的定期同步行为的速率保持一致，以达到准实时更新的效果。

数据探查服务的结果：汇聚表DB的存储

上述各个索引结构都构建完成后，我们可以做一些常规的汇总统计的操作，然后将这些结果存储到一张汇聚表中。然后用户可以通过这张汇聚表的数据来进行他们希望的查询请求。

比如举个例子，我们存储了一张Container–>Blocks数的表数据，定义如下：

CREATE TABLE `num_blocks_per_container` (
`container_id` BIGINT,
`num_blocks` INT,
 PRIMARY KEY (`container_id`)
);

和上述的步骤类似，这里的汇聚结果表也是需要被定期更新的，这样的话，用户就能够查询到近实时的结果。

数据探查服务的额外功能：节点级别的统计

---

数据探查服务不仅支持细粒度层面的元数据分析，当然它也应该包含节点层面的统计，诸如以下类似指标：

• 节点磁盘使用空间

• 节点总blocks数量

• …

这些节点层面的统计需要由数据探查服务定期对这些节点做一次查询操作，然后也将结果保存到上面的汇聚表中。这类结果数据对于系统管理员来说将会相当有用，比如说利用这些数据我们可以知道节点使用空间的趋势变化情况等等。

数据探查服务的外部展现：用户控制台

数据探查服务作为一项完整的数据分析服务，它不应该直接暴露给使用者。对于使用者来说，我们需要给他们提供一个Console的东西，用户看到的可以是直接提供好的用户命令，不同身份的用户能够使用的执行命令也是有所区分的。而Console里面的Console Server是数据探查服务的一个代理。

在这个Console Server的服务里，我们可以进一步完善Security的功能，加入一些authentication，或者更方便用户进行查询使用的一些Feature，比如浏览器直接浏览查询功能。

以上所有的设计参考自Hadoop Ozone Recon服务的设计，此服务的设计结构图如下，大家可以参考上面描述的进行比较。

Ozone数据探查服务：Recon Server

---

为了使大家能够了解本文笔者将要阐述的，这里有必要提及Ozone数据探查服务Recon Server的服务设计架构，如上述图所示。

在早些时间，社区已经实现了从OM Follower到Recon Server的Checkpoint for bootstrap的分支。目前下面的分支apply WAL update也即将要实现，这个过程也是笔者本文将要阐述的主要内容：Recon Server基于RocksDB的WAL做Delta更新。

Recon Server基于Checkpoint获取定期DB Snapshot的弊端

在Recon Server最开始实现RocksDB同步的时候，一开始了采用的是周期性同步DB文件的办法。这个DB来自于Ozone OzoneManager Follower节点的RocksDB文件。相当于是去定期去拉去OM Follower节点DB的snapshot版本。而这个snapshot版本由RocksDB原生支持的Checkpoint行为产生。

这种方法虽然说比较简单，直接，但是它并不是最高效和完美的，至少它有以下一些问题：

• 无法做到准实时同步，数据的实效性完全取自于Recon Server服务配置的同步间隔时间。

• 如果为了增强数据的实时性，增大中期拉取快照频率，那RocksDB频繁的checkpoint行为势必会有一定的开销。而且Checkpoint出的文件在bootstrap过程中，会经过压缩、传输、再解压缩到Recon Server机器上。整个过程步骤繁多，解压缩文件的过程也将是一个耗时的操作。

因此在这里，一个更优的策略方式应该是：整体基于Delta的DB更新策略，Checkpoint文件做定期的整体数据校准。

RocksDB基于Update WAL的Delta更新

Ozone基于的是RocksDB做元数据DB的存储。那么我们不禁在想，在RocksDB中我们是否能够得到距离某次transaction提交后的增量更新呢？例如Update WAL这类的信息？答案是有的，RocksDB的内部API getUpdatesSince(final long sequenceNumber) 能够很好地帮助我们解决这个问题。

/**
   * <p>Returns an iterator that is positioned at a write-batch containing
   * seq_number. If the sequence number is non existent, it returns an iterator
   * at the first available seq_no after the requested seq_no.</p>
   *
   * <p>Must set WAL_ttl_seconds or WAL_size_limit_MB to large values to
   * use this api, else the WAL files will get
   * cleared aggressively and the iterator might keep getting invalid before
   * an update is read.</p>
   *
   * @param sequenceNumber sequence number offset
   *
   * @return {@link org.rocksdb.TransactionLogIterator} instance.
   *
   * @throws org.rocksdb.RocksDBException if iterator cannot be retrieved
   *     from native-side.
   */
public TransactionLogIterator getUpdatesSince(final long sequenceNumber)
throws RocksDBException {
return new TransactionLogIterator(
        getUpdatesSince(nativeHandle_, sequenceNumber));
  }

这里的参数sequenceNumber可以理解为是transaction id。Sequence number会在每次的RocksDB写记录中进行递增，不过它不是针对单独的一条写记录，而是一个批的写，在RocksDB中的概念叫做WriteBatch。一个WriteBatch中可能包含一条记录，也可能有多个记录包含在此批中，等待被写入。

在RocksDB的增量更新中，我们就能够有效地利用这个API。每次我们在apply完最新一批的transaction之后，更新当前同步的sequence number，以便下次查询时使用。

在拿到Update的WAL之后，Recon Server做了以下的更新事务的处理

1）对查询得到的byte数组数据进行transaction对象的转换，这里需要实现一个WriteBatch.Handler的子类来监听RocksDB的update event并执行处理逻辑。Recon在这里实现了对应的Handler实现类OMDBUpdatesHandler。

2）OMDBUpdatesHandler将解析完的OMDBUpdateEvent列表传入ReconDBUpdate task中进行处理。

3）ReconDBUpdate task内部根据transaction信息进行SQL汇聚表的结果更新。这里的Task能够选择针对特定表的事务更新。Task Update Task采用异步执行的方式运行于统一线程池内，中间如若出现部分Handler执行出错的情况，则进行重试执行。

上述过程的流程图如下所示：

以上就是Ozone数据探查服务Recon Server内部基于OM Follower DB的Delta更新过程了，相信能够给大家带来借鉴意义。

欢迎点赞+收藏+转发朋友圈素质三连

文章不错？点个【在看】吧！ 👇