撸论文系列——F1 Query

今天参加了PingCAP举办的Infra Meetup，主要介绍和解读了F1 Query：Declarative Querying at Scale这篇论文，演讲嘉宾是PingCAP CTO—黄东旭老师。

整个过程很融洽，最后的QA环节现场的小伙伴也提出了很多宝贵和有价值的问题。下面结合今天听讲的内容对这篇论文的几个重要的点进行详细的论述。

首先讨论下为什么提出F1 Query。目前Google在处理海量数据的查询时遇到几个问题：一是多种异构的存储平台（Bigtable,Spanner,Google Spreadsheets等）共存，二是不同存储平台上的计算不统一，三是复杂的商业逻辑开始需要实时的分析和数据处理（HTAP）。

那么什么是F1 Query呢？

它具备几大特征：第一，它是独立计算层，底层对接了不同的数据源；第二，它试图统一OLTP、OLAP和ETL的Workload；第二，它也是一个完整的ETL平台；第四，它推出了几种访问数据的新形式，UDF、UDA和TVF SQL；第五，Shading-nothing，这个之后会详细介绍。

下面开始详细介绍F1 Query几个比较重要的设计点。

一、面向多数据中心的高可用设计

F1 Master服务器是数据中心中的一个特殊的结点，它负责查询执行和所有F1服务器的运行时监控。小型的查询和事务在紧邻的F1服务器上执行并接收请求。通过从工作池中动态提供执行线程，F1可以分布地执行大型的查询计划。而大型的查询计划都是使用MapReduce框架在可靠的批量执行模式上运行。最后的结果收集在F1服务器中并返回给客户端。F1服务器和workers都是无状态的，允许客户端无时无刻地和特定的F1服务器通信。由于F1服务器和workers不存储数据，所有增加新的F1服务器和workers不会触发数据的重新分布。

F1服务器发送查询到客户端，携带优化查询的可用数据中心簇。

F1 Query的设计并不太关心Data locality，这决定大大降低了计算和存储耦合度。另外决定性的因素是：google的数据中心网络能提供至少10Gb/s的带宽，以及几乎无穷大的计算能力。

二、多数据源环境下的优化器和执行器设计

由于不同数据源的行为不一致，包括是否支持partition，是否支持逻辑下推，是否支持索引以及是否支持多种扫描模式。导致设计这样的优化器和执行器不是特别简单。

三、不同的查询交互模式

F1 Query支持查询嵌套结构数据支持标准的SQL特性，包含left/right/full outer joins,aggregation,table和expression子查询，WITH从句和分析窗口函数。

交互式查询，面向实时场景。其中包含两种执行模式：Central和Distributed。这些都是优化器分析查询之后决定的。

Central执行模式

单机单线程一行行拉取数据。如果优化器发现可能SCAN的数据比较小，则可能会生成这类的单机执行计划。

Distributed执行模式

同一个Fragment可以由多个F1 Worker并行执行一个或多个算子。这种情况下，查询执行计划分割为不同的query fragments，每个fragment都会在一组F1 worker节点上执行。fragment并行执行包含pipelining和parallelism。

每个单独的算子对于从不同worker种分布的输入数据是有要求的。如果存在，这种需求一般是hash到一个字段的序列中。比如grouping或者hash join。对数据分布有共同需求的算子，数据是否按照某个字段进行分片。

hash分区保重了每个key都仅仅分布在一个节点上，但是对于一个数据源来讲，这种访问模式看起来仍然像是随机访问。一个更出色的基于range策略名为dynamic range reparation是在独立的range partitioning函数上基于本地的分布式信息计算出来的。

四、可扩展性

最后要讲的是扩展性。很多复杂的业务逻辑由于无法用简单的SQL表达，所以这里使用了三个更合适的函数。

UDF：标量函数

UDA：自定义聚合函数

TVF：表转化函数

UDF服务器是无状态的，每个F1服务器并行地分发请求到许多UDF服务器进程。

执行器通过RPC调用远程的UDF函数，通过Batch/流水线/异步化将远程调用的延迟抹平。

UDA则是自定义的聚合函数，需要实现Initialized/Accumulate/Finalize三个函数。另外，可以定义Partial Aggregation行为，实现Reaccumulate，用于实现多个UDA子聚合结果的再聚合。

TVF函数通过表转化，将输入表转化为输出表，给数据库和DM、ML以及AL training都提供了新的互相调用思路。

最后，介绍相关的谷歌新技术。

Spanner SQL和F1 Query有相似的共同点，但是他们在一个重要的领域中是不同的。前者是单个聚焦的SQL系统操作事务核心。另外Spanner SQL也提供了非常友好的查询重启策略。

BigQuery是Google云数据仓库。查询使用Dremel，一个在广告分析中广泛使用的查询引擎。它又花了查询分析数据，并且可以扩展聚合和join。F1 Query支持许多使用场景，并提供额外的对于OLTP风格的查询提供支持。

PowerDrill是用于谷歌内部交互式数据分析和搜索的查询引擎。它是一个严格的系统可以预处理数据来分割查询类型。相反地，F1 Query有一个更加广阔的使用范围，但是还不能有一个等价级别的对于数据搜索场景的优化。