这类SQL引擎的另一个重要进步是对诸如ORC/Parquet等列式文件格式的支持，这对于分析工作是有着显著好处的。例如，连接两个有Avro记录的Kafka主题将比连接两个通过ORC/Parquet文件格式存储的Hive/Spark的表的开销大得多。这是因为，对于Avro记录来说，你最终要反序列化整个记录，而列式文件中只需要读取在记录中会被查询所用到的列。如果我们简单地从一条编码的Kafka Avro事件中的1000个字段中投影出10个字段，我们仍然需要为所有字段花费CPU和I/O的开销。列式文件格式通常可以更为“聪明”地投影到存储层。
图三：Kafka事件和HDFS上列式文件，将10个字段从1000个字段中投影出来的CPU和I/O开销的对比。由Vinoth Chandar提供
较少的运动部件
现在被广泛实现的Lambda架构（一个基于MapReduce 和 Storm 构建的流式处理的应用架构）有两个模块：速度层和批处理层。它们通常由两个独立的实现（从代码到基础设施）来管理。例如，Storm是速度层上的一个热门选项，而MapReduce可以作为批处理层来提供服务。实际上，人们经常依赖速度层来提供更新的结果（可能并不准确），而一旦数据被认为是完整了之后，通过批处理层在稍后的时候里来纠正速度层的结果。随着增量处理的使用，我们有机会以统一的方式在代码层面和基础设施层面来实现Lambda架构。