MyBatis实现动态SQ相当于利用泛型函数保存了类型信息L更新

概要

开篇很明确的表明了为什么要做Delta lake这样一个产品. Databricks尝试将数据仓库直接架在云上对象存储之上, 这种尝试的过程中遇到了对象存储的一些问题, 为了解决这些问题, 提出了Delta lake这套技术方案.

对象存储的优势

• 性价比高, pay-as-you-go 用多少付多少
• 能快速扩缩容
• 存算分离, 使得用户可以单独去调整存储或计算资源

对象存储的问题

• 对象存储只提供了类似 kv 的api , 每一个路径就是一个key , 很难做到跨key 对象之间的事务保障. 在更新某张表的时候, 可能会导致其他客户端读取到中间数据. 甚至在更新过程中的意外退出可能会导致损坏的数据
• 元数据操作性能特别差, 特别是list 操作, 例如S3 每次只能返回1000个对象, 每次执行需要花费上百ms.
• 由于云上读取数据会有初始的latency(慢启动), 所以要想利用在parquet文件的footer中保存的min/max的statistics信息, 就需要频繁去读取每个文件的footer, 来进行谓词下推, 这个过程反而可能会因为"慢启动" 的问题导致这种 "skipping check" 反而比原始query 还要慢.

Delta Lake设计思路

因此, 为了解决这些对象存储的问题提出了Delta Lake, an ACID table storage layer over cloud object stores的架构设计.
他这里也对比了其他几种解决的思路
比如通过数据分区, 或者像snowflake那样通过一个集中式的元数据服务, 这个劣势就是需要单独维护一个元数据服务, 并且这个服务很容易成为瓶颈, 因为所有的操作都需要经过这个服务.
Delta lake的思路就是直接将元数据保存在object store之上, 并通过WAL日志实现事务保障.

可以看到分区目录下是数据文件, _dalta_log 目录中就记录的是transaction log.
这些日志中记录了, 哪些文件被添加了, 哪些文件被删除了, 元数据的操作, schema变更, statistics信息.

这样读取的时候需要遍历delta log 来确定所需要读取的文件列表, 那么为了避免每次读取需要查所有的json文件, 会定期的checkpoint, 将多个json文件合并成一个.parquet文件, 并在_last_checkpoint中记录最新的checkpoint id.
这样读取数据的流程就是查询checkpoint文件找到这些文件的列表, 然后可以根据元数据中的statistics 过滤掉不相关的文件, 然后直接读取这些datafile, 相比原来的操作list + 读取文件的 footer 要快很多.

读取协议

• 读取last_checkpoint id
• 使用list操作 找到 checkpoint 及他之后的json列表. 这样就可以构建出某个时间点表的视图. 这里有个点需要注意 设计中还存在对云存储最终一致性的兼容

• 根据这个元数据的文件列表进行数据读取

写入协议

• 在写完一个data object后, 需要更新元数据到delta_log目录中
• 找到要新写入的