dremio 一个元数据刷新问题
以前关于dremio 元数据刷新的也简单介绍过，最近发现dremio 新版本（从24.1 版本开始）有一些调整，废弃了，所有数据集的刷新配置
只支持基于查询的元数据刷新，一些关于此调整一些说明
好处
- 减少了元数据刷新的时间以及对于查询的影响，可以让查询阶段的元数据处理更快了（核心是减少查询处理）
- 减少了dremio 系统元数据处理的负载，因为我们很多时候添加的上游数据源，使用到的数据表会不太多
- 减少了kv存储以及读写处理（还是因为元数据处理少了）
- 对于dremio 系统元数据的列信息只会暴露按需的使用到的信息
缺点
- 对于希望基于dremio 进行全量信息查看的就不太方便的，尤其是基于api 集成的，就需要自己调整了（当然如果是基于api 还是可以通过接口配置全量元数据刷新的）
新版本调整的内部处理
dremio 对于元数据刷新有一个枚举类UpdateMode 如下，可以看到包含了不少模式，当前主要支持的也就PREFETCH 以及PREFETCH_QUERIED，PREFETCH 因为从界面上废弃了
public enum UpdateMode implements io.protostuff.EnumLite<UpdateMode>
{
UNKNOWN(0),
PREFETCH(1),
PREFETCH_QUERIED(2),
INLINE(3);
public final int number;
private UpdateMode (int number)
{
this.number = number;
}
public int getNumber()
{
return number;
}
public static UpdateMode valueOf(int number)
{
switch(number)
{
case 0: return UNKNOWN;
case 1: return PREFETCH;
case 2: return PREFETCH_QUERIED;
case 3: return INLINE;
default: return null;
}
}
}
- 刷新处理
内部元数据刷新还是以前的几个类SourceMetadataManager 以及MetadataSynchronizer，当我们添加了数据源之后表一般是会有的（文件系统类的可能会没有）但是表的字段信息就会和选择的策略有关系了
对于表已经存在的处理
private void tryHandleExistingDataset(NamespaceKey datasetKey, DatasetHandle datasetHandle)
throws NamespaceException, ConnectorException {
// invariant: only metadata attributes of currentConfig are overwritten, and then the same currentConfig is saved,
// so the rest of the attributes are as is; so CME is handled by retrying this entire block
final DatasetConfig currentConfig = systemNamespace.getDataset(datasetKey);
final boolean isExtended = currentConfig.getReadDefinition() != null;
// 结合配置的元数据刷新策略进行处理updateMode，如果是PREFETCH_QUERIED （新版本默认，同时还有一个扩展属性的信息）直接就返回了
if (updateMode == UpdateMode.PREFETCH_QUERIED && !isExtended) {
// this run only refreshes, and not create new entries
logger.trace("Dataset '{}' does not have extended attributes, skipping", datasetKey);
syncStatus.incrementShallowUnchanged();
return;
}
if (isExtended && sourceMetadata instanceof SupportsReadSignature) {
String user = SystemUser.SYSTEM_USERNAME;
if (options.datasetRefreshQuery().isPresent()) {
user = options.datasetRefreshQuery().get().getUser();
}
boolean supportsIcebergMetadata = (sourceMetadata instanceof SupportsUnlimitedSplits) &&
((SupportsUnlimitedSplits) sourceMetadata).allowUnlimitedSplits(datasetHandle, currentConfig, user);
final boolean isIcebergMetadata = currentConfig.getPhysicalDataset() != null &&
Boolean.TRUE.equals(currentConfig.getPhysicalDataset().getIcebergMetadataEnabled());
final boolean unlimitedSplitsSupportEnabled = MetadataRefreshUtils.unlimitedSplitsSupportEnabled(optionManager);
final boolean forceUpdateNotRequired = !supportsIcebergMetadata || isIcebergMetadata || !unlimitedSplitsSupportEnabled;
if (forceUpdateNotRequired) {
final SupportsReadSignature supportsReadSignature = (SupportsReadSignature) sourceMetadata;
final DatasetMetadata currentExtended = new DatasetMetadataAdapter(currentConfig);
final ByteString readSignature = currentConfig.getReadDefinition().getReadSignature();
final MetadataValidity metadataValidity = supportsReadSignature.validateMetadata(
readSignature==null || readSignature.size() == 0 ? BytesOutput.NONE:os -> ByteString.writeTo(os, readSignature),
datasetHandle, currentExtended);
if (metadataValidity==MetadataValidity.VALID) {
logger.trace("Dataset '{}' metadata is valid, skipping", datasetKey);
syncStatus.incrementExtendedUnchanged();
return;
}
}
}
// 调度datasetsaver 实现，里边会实际调用不同存储插件实现的表数据信息获取的处理，比如jdbc 是JdbcSchemaFetcherImpl.getTableMetadata
saver.save(currentConfig, datasetHandle, sourceMetadata, false, options);
logger.trace("Dataset '{}' metadata saved to namespace", datasetKey);
syncStatus.setRefreshed();
syncStatus.incrementExtendedChanged();
}
说明
以上是关于新版本元数据刷新的一个简单说明，新的变化有利于查询性能的提升，但是对于实际比较依赖information_schema.columns 的
会有一些问题，当然上边也说了解决方法很多，实际上还是不能让dremio 做太多的事情，确保系统指责的简单高效才是比较重要的，我们
一般使用dremio 核心是希望使用dremio 的虚拟查询以及虚拟表能力，直接使用虚拟表的模型也是我们关注的
参考资料
sabot/kernel/src/main/java/com/dremio/exec/catalog/SourceMetadataManager.java
sabot/kernel/src/main/java/com/dremio/exec/catalog/MetadataSynchronizer.java
