关于Delta File Format运行机制与特性实现的技术问询

1. Delta是否像HDFS那样存在常驻服务进程响应请求？
   不存在。Delta Lake 不像HDFS那样有独立的常驻服务进程，它本质是一套基于文件的存储格式，依赖与之交互的计算引擎（如Spark、Trino等）来处理所有请求。所有Delta相关的逻辑都运行在计算引擎的进程内部，而非单独的守护进程。

2. 其ACID、更新/删除、数据治理等特性由什么负责实现？
   这些特性由集成在计算引擎中的Delta Lake 库实现，核心组件包括：

   • ACID合规性：通过事务日志（以JSON文件形式存储）跟踪所有表变更，确保操作的原子性、一致性、隔离性和持久性。
   • 更新/删除操作：利用事务日志记录操作，计算引擎会根据需要通过优化的合并（merge）等操作重写数据文件。
   • 数据治理：模式校验、时间旅行、访问控制等功能由Delta库配合计算引擎及底层存储的安全机制共同实现。

3. 当DBT等工具与Delta交互时，由哪个进程提供上述特性？
   当DBT这类工具与Delta Lake交互时，计算引擎进程（通常是Spark，因为DBT底层依赖Spark处理Delta操作）会运行Delta Lake库的代码来实现这些特性。DBT仅作为编排工具，将SQL指令发送给计算引擎，由计算引擎在自身进程空间内执行Delta相关的逻辑。

4. Delta仅支持表结构，是否属于RDBMS产品？
   不属于。Delta Lake 是面向数据湖的事务性存储层/文件格式，而非关系型数据库管理系统（RDBMS）。它没有自己的查询引擎、事务协调器或持久化服务器，依赖外部计算引擎处理查询和事务；同时它针对数据湖的大规模非结构化/半结构化数据场景设计，而非RDBMS擅长的OLTP事务工作负载。

5. Delta的运行层级如何界定？
   Delta Lake 处于存储抽象层，介于计算引擎和底层存储系统（如S3、HDFS、ADLS）之间。它本身不属于计算层，而是为存储层扩展了事务能力。当计算引擎（如Spark）读写Delta表时，会通过Delta库与存储交互，在底层存储的原始文件之上应用事务逻辑。

内容的提问来源于stack exchange，提问作者user3103957