内容来自官方文档，介绍了一些关于dremio 的数据语义层的玩法
原则
- 分层
通过分层可以确保安全，性能以及可用性，dremio 提供了一个对于语义层的最佳实践 - 数据集的注释增强发现以及可理解性
可以通过tag 以及文档（wiki）进行数据的描述
最佳实践
- 使用1:1 的预处理层
此层的数据接近原始数据源，可以用来对于按需数据的组织，而不是所有的数据，这一层那个view 会映射到原始数据源中的数据
同时没有join 操作其他view - 使用业务层进行数据集的逻辑join
这层的数据的做法
- 查询预处理层的资源，应该选择所有预处理层的列数据，典型是一个1:1 的映射
- 查询其他同一业务层的资源，当查询的时候应该以来业务层的数据，而不是预处理层的，这样可以缺少数据join 可以进行方便的传播
应该使用通用的术语进行业务实体的描述，同时也可以在此层中创建子层，那个包含特定主题数据，这些是可复用的，应该在业务线中是可复用的组件
典型的不应该在此层进行filter （包含行以及列数据），应该推迟到应用层
此层可以提升产品以及分析的主动权，最大化的减少重复，可以对于数据工程师提供自服务模型，可以方便的在数据消费者中进行共享，减少数据到业务线的服务交付
- 使用业务层对于数据消费进行组织
应该层view 主要是为了数据洗消费者进行组织,典型的场景包括数据分析，数据科学，如果应该层要提供一个dremio 语义服务的自服务访问，应该使用最小原则
如果此层不做为自服务提供，但是是对于特定应用的，此层应该依赖在应用层中的其他自服务视图，同时添加特定的应用业务逻辑，应该层可以基于应用进行row 的过滤
同时列的数据也可以进行减少 - 利用tag 进行可搜索性的增强
比如对于不同的业务组，同时也可以进行多个tag 的添加 - 使用wiki 内容进行数据集的装饰
wiki 可以方便人员对于数据的理解 - 使用数据血缘理解对象的关系
此功能实际上属于企业版的，可以方便知道数据的资源关系
说明
同时官方还有一个独立的关于语义层的最佳实践说明，很值得看看
参考资料
https://docs.dremio.com/current/help-support/lakehouse-arch/semantic
https://docs.dremio.com/current/help-support/best-practices/semantic_layer