一、背景介绍
1.1 什么样的客户需要数据湖
在数据处理领域，数据湖相对来说是一个比较新的概念，它的提出可以很好地帮助企业应对当前数据场景越来越多、数据结构越来越复杂、数据处理的需求越来越多样化的问题。传统的单机数据库技术倾向于大一统，一个数据库可以解决数据存储、在线交易、在线分析、离线报表等功能，好处是简单，数据只有一份，缺点是各个功能都做了取舍，很难解决规模的问题。为了突破数据规模的瓶颈，大数据技术更倾向于针对单独领域做深度定制，比如海量文件存储使用HDFS、海量对象存储使用OSS/S3、宽表存储使用BigTable/HBase、嵌套数据使用MongoDB、大规模TP数据使用PolarDB、大规模AP数据使用ADB/Clickhouse、日志数据使用LogService等等。
在很多企业里面，不同的部门业务不同，采用的数据方案也不同。在企业发展的前期，更多是靠业务模式驱动、流量驱动，数据复杂度的问题还不明显，后期则需要精细化运营、向数据要红利，数据管理的难度就成为企业的痛点。数据湖的出现可以很好地解决这个痛点，这也是为什么各个云厂商都推出了数据湖产品，数据湖产品和解决方案越来越得到客户的认可。Gartner 2020年发布的报告显示目前已经有39%的用户在使用数据湖，34%的用户考虑在1年内使用数据湖。
1.2 阿里云数据湖分析（DLA）整体方案
阿里云数据湖分析（DLA）产品提供了数据湖的一站式解决方案。OSS对象存储采用KV的技术架构，可以实现无限扩展，是公认的数据湖存储底座。用户可以通过离线ETL和在线增量ETL将在线数据和实时增量数据，同步到OSS中，然后对数据做深度的计算和分析。用户也可以直接访问这些在线库，做在线的联邦分析。为了方便用户管理数据湖中的数据，我们提供了统一的数据湖管理方案。数据湖管理可以统一存储数据湖中数据的元信息给计算引擎使用，另外还提供元数据动态爬取功能，可以动态解析OSS数据目录结构和数据格式，省去了用户手动创建表和分区的工作。同时，DLA跟DMS和QuickBI进行了深度集成，方便用户实现更丰富的开发和管理逻辑。
DLA同时提供了SQL和Spark两个引擎，SQL基于Presto实现，可以实现高效的在线分析，主要面向用户探索式分析、报表以及轻量ETL的场景；Spark可以实现用户自定义代码和复杂计算逻辑以及超大规模ETL的场景。本文主要介绍DLA SQL(兼容Presto)，关于DLA Spark的介绍可以阅读: 阿里云云原生数据湖分析DLA Serverless Spark重磅发布，助力企业低成本挖掘OSS数据价值
二、DLA SQL（兼容Presto）架构解析
2.1 Presto简介
DLA SQL是基于开源的Presto引擎打造的交互式分析引擎，Presto是Facebook开源出来的、初衷就是为了解决使用Hive来进行在线分析速度太慢的问题，它采用全内存流水线化的执行引擎, 相较于其它引擎会把中间数据落盘的执行方式，Presto在执行速度上有很大的优势，特别适合用来做在线数据分析。
其次跟很多分析引擎只实现了部分SQL语义不同(比如Clickhouse为了单表查询的性能做优化，不支持多表JOIN这种常见的SQL场景)，而Presto则是实现完整的SQL语义，你不用担心你有什么SQL语义是Presto不支持的。
再者Presto另一个令人瞩目的特性是多数据源联合查询，一个公司的数据根据业务的特点可能散落在很多地方比如MySQL, OSS, HDFS, TableStore等等, Presto内置的Connector机制使得我们可以对这些不同数据源的数据关联查询，而不用事先把这些数据挪到同一个存储介质，特别适合数据湖场景这种数据源多种多样的场景。
最后Presto有一个非常棒的社区，国内外的大公司比如Facebook、Twitter、Amazon Athena、阿里巴巴、京东、头条等等都在用，你不用担心用了Presto之后会碰到社区解决不了的问题。
总结来说Presto是一款全内存流水线化执行的、支持通过Connector机制查询各种异构数据源、完整实现了SQL语义的这么一款数据分析引擎。因为它的这些优异的特性国内外的大公司包括我们DLA SQL都采用Presto来进行大数据的分析。
2.2 使用开源Presto自建的挑战
由于上述Presto各种优异的特点各个公司都纷纷采用Presto来进行在线的数据的分析，但是使用开源Presto自建会缺失一些企业级的特性。
首先是运营维护成本高。开源自建意味着需要手动搭建Presto集群，对Presto的各项配置参数进行调优，碰到各种性能使用问题需要从头研究；Presto原生对于库表列权限的支持很弱，需要配套搭建比如Ranger之类的另外一个系统来进行权限的管理；由于直接支持Presto协议的云服务不多，周边的调度、BI等配套软件都得自建。这样第一次上手时间很长，从数天到数周不等；另外后续这一整套软件栈的维护也是成本很高的。
其次是使用门槛比较高。比如如果我们要新添加一个数据源来进行分析，我们必须要修改整个集群的配置，然后对Presto集群进行重启才能生效，这个至少会导致5分钟左右的不可用，而如果中间有任何配置错误，要进行调试时间就更长了；再比如由于Presto不是一个完全自包含的系统，对于权限控制之类的可能要依赖Ranger之类的系统，因此你对Presto使用可能还要跨越到另外一个系统去做一些配置，无法做到一站式；再一个使用门槛高的点在于它的SQL是要求严格类型匹配的，比如下面这样的SQL直接运行在Presto里面会报错的：
SELECT *FROM TBLWHERE date_col < '2020-05-30'; -- date_col是date类型的
报错的原因在于 date_col 的类型是date, 而 '2020-05-30' 的类型是string，类型不匹配，无法进行查询，这会使得习惯于使用MySQL等数据库的分析师非常不适应。
缺乏对云上数据源的原生支持。我们越来越多的业务会基于云上服务来搭建，会使用很多云上的数据源比如阿里云的AnalyticDB, TableStore等等，要分析这些数据源，Presto是没有自带Connector的，当然用户可以自己基于Connector机制来实现，但是要实现一个稳定高效的Connector也是很有挑战的一件事情，不是每个公司都愿意投资人力资源来做。
最后Presto的Coordinator在架构上是个单点。当集群运行的SQL很多，或者整个集群很大，Coordinator解析调度查询的压力、Coordinator与Worke之间同步任务信息的压力会很大，Coordinator会有宕机的风险，一旦宕机整个集群会不可用，这对于一个要在生产环境使用的服务来说是不可接受的。
2.3 DLA SQL（兼容Presto）的架构
DLA SQL(兼容Presto)的目标是提供比开源自建更高的性价比、开箱即用的体验、方便的数据摄入、MySQL生态的简单易用、内置各种优化的Presto分析计算服务。下面我们来介绍一下为了达到这个目标我们采用的架构。
我们整个架构的核心是中间的Presto集群，跟开源的Presto不同的是，我们做了大量的优化，首先我们内置了多Coordinator的方案，去除了这个架构上的单点，并且这个多Coordinator的方案可以横向扩展，以应对负载的上升。
其次我们对整个集群元数据这块进行了抽象整理，跟开源版本依赖各个Connector提供元数据信息不同的是，DLA SQL有统一的元数据中心。这使得我们对新的数据源的支持从部署期(依赖类似mysql.properties)移到了运行期, 使得我们可以动态增添各种数据源。统一的元数据也使得我们可以方便地内置支持库表列方面的权限授权体系，帮助企业守好数据权限这一关。
在整个Presto集群的最前面是我们的FrontNode节点，这个节点的作用是向用户提供MySQL协议的接口，用户通过MySQL协议提交查询到FrontNode, FrontNode把查询转换成Presto风格的SQL提交给后端的Presto集群，然后监控Presto集群上任务的状态并且把最终的结果返回给用户；FrontNode的另外一个职责是对请求进行分发，因为我们同时支持Serverless和CU版本，FrontNode会根据用户购买的服务形态对用户的请求进行分发，分发对对应的Presto集群。
DLA SQL目前支持两种售卖形态Serverless和独享版，Serverless的版本针对小客户、对资源隔离要求不是那么高的用户、低频偶发查询类的用户；独享版针对对于资源隔离要求比较高、或者是查询非常高频的场景。
三、DLA SQL（兼容Presto）VS开源自建Presto
基于上述DLA SQL的架构我们来对比一下DLA SQL相比开源自建Presto的优势：
超高性价比：相比用户自建Presto提高2到10倍
开箱即用
方便上手的SQL体验
方便的数据摄入
高可用: 内置Coordinator HA
连接器的优化
MySQL生态支持
内置完善的权限控制体系
3.1 超高性价比：相比用户自建Presto提高1到72倍
用户自建Presto集群一般会有两种使用模式，一种是偶尔查查问题的时候才用，这种使用频率很低，一天可能都查不了几十条SQL，但是还是要维护一个集群，非常不划算；另外一种是高频使用场景，白天上班时间段全负载使用、晚上下班之后集群还是空闲下来，从整体成本来看仍然不是最优的。
为此DLA提供了两种计费模式，一种是按照扫描量计费，执行一条SQL收一条SQL的钱，适用于低频使用场景；另外一种是按照CU(Compute Unit)计费，适用于高频使用场景。
我们做了一个实验，以用户自建两台4C16G机器组成的一个小集群为例，当用户是低频访问的时候采用DLA的扫描量版本，DLA的性价比是用户自建的72倍；当用户是高频访问的时候采用DLA的CU版本 + 弹性，性价比仍然要高于用户自建。整体来看DLA的性价比能够做到用户自建的1到72倍。
总之不管你什么使用场景，什么使用频率，我们总有一个计费模式适合你。
3.2 开箱即用
对于用户自建Presto，从搭建集群开始，到最终完成一个最简单的报表大概的步骤如下：
取决于你搭建Presto集群的方式，是完全手动搭建，还是基于Docker之类的服务，整个过程可能在30分钟到5小时之间；搭建完成之后为了运行一条Presto SQL，你需要通过命令行登陆到你的ECS服务器上去，然后利用Presto提供的命令行工具来进行数据的查询；或者再搭建一个hue之类的系统，并且做好对接，也可以进行数据的查询；然后由于Presto对于BI报表的兼容性不是那么的广泛，你需要去下载/搭建自己的BI报表系统、任务定时调度系统，这个时间在几个小时左右；因此为了通过自建的Presto来完成一个最简单的BI报表您需要的时间在几小时到几天之间。
而如果使用DLA SQL，整个过程是这样的：
首先在“搭建Presto”的环节与自建不同，用户只需要在DLA页面点击开通即可；然后进行数据查询，直接在DLA控制台就可以查询，或者任何支持MySQL协议的客户端都可以查询；最后因为DLA SQL支持了MySQL协议，云上有现成的BI服务：QuickBI，有现成的调度服务阿里云DMS, 阿里云DataWorks等等，因此BI报表展示以及任务的定时调度均可以在5分钟内完成；整个过程可以在30分钟内完成，真正做到开箱即用，而且这种方便、省时间不只是节省你第一次搭建集群时候的时间，因为所有的相关配套都有现成服务提供，你不需要维护任何东西，在整个大数据分析的生命周期内都会节省时间，真正做到开箱即用、全托管。
3.3 方便上手的SQL体验
相比开源自建Presto，DLA SQL在SQL体验方面做了很多优化，方便数据分析师们使用。首先我们内置了类型的隐式转换，比如分析师可以直接把一个date类型与一个string类型进行比较，忽略了这些类型转换的细节，节省下来的时候可以专注于做更重要的数据探查。
其次我们所有的元数据是由我们统一元数据服务来管理，而不像开源Presto是由各个Connector单独提供，这样用户要新添加一个数据源只要使用我们的 CREATE SCHEMA 语句来对元数据进行操作就好了，不涉及任何集群的运维操作。比如要添加一个mysql数据源，我们执行如下的命令即可：
CREATE SCHEMA db001 WITH DBPROPERTIES (
CATALOG = 'mysql',
LOCATION = 'jdbc:mysql://xxx.rds.aliyuncs.com:3306/db',
USER = 'user',
PASSWORD = 'pass',
INSTANCE_ID = 'inst001',
VPC_ID = 'vpc001'
);
更少的运维操作意味着整个服务更高的可用性，更平滑的使用体验。
3.4 方便的数据摄入
一个引擎要能分析数据，你首先得知道数据在哪里，在云上目前很大一部分数据是保存在对象存储比如阿里云OSS里面的，OSS的特点是便宜，可以以比较低的成本存储海量的数据。而OSS上数据的上传与后续的分析往往的脱节的，通常不是同一个人完成，对于分析的人来说OSS上到底有哪些数据，它们的结构是怎么样的是个难题，DLA SQL在这一块提供了两个配套的服务: OSS元数据发现和一键建湖。
OSS元数据发现
OSS元数据发现的作用是自动扫描你OSS上的所有的数据文件，建立相应的库、表结构，这样在你需要分析的时候，所有的元数据都已经自动建立好了，省去你找数据、建库建表的繁琐。
一键建湖
一键建湖针对的场景是用户的数据在RDS里面的场景，它自动帮助你把RDS里面的数据同步到OSS上，每天在你设置的时间点自动同步一次，保持数据最新。并且自动建立好相应的库表结构，这样在你需要对数据进行分析的时候，你直接分析就好了，而且分析的数据是OSS上的，对您RDS不会有任何压力负载，做到真正的“敢分析”。关于数据摄入的详细介绍可以阅读: 阿里云云原生数据湖分析DLA重磅发布-数据湖管理，助力企业一站式管理OSS数据湖存储数据
3.5 高可用：内置Coordinator HA
在开源的Presto架构中Presto Coordinator是个单点，如果因为CPU/内存或者底层物理机的原因导致Coordinator不可用，会导致整个集群不可用，从而影响用户的使用，DLA SQL内置了多Coordinator HA，当一个Coordinator宕机，另外一个Coordinator会自动接管，保证整个集群的可用性：
3.6 连接器的优化
Presto本身支持了大量的Connector来连接各种数据源，但是云上的有些数据源还是没有覆盖到的，比如阿里云这边自研的MaxCompute和Tablestore服务，在用户中使用是很广泛的，DLA SQL对他们也进行了支持。
DLA SQL也针对一些数据源进行了性能和成本方面的优化，比如针对阿里云OSS进行数据分析的话会产生大量的OSS的调用，调用量也是有一些调用费用的，DLA SQL对这方面进行了优化，大幅降低了OSS的调用次数，降低用户在OSS上的调用成本，如下图：
再比如针对RDS类的数据源(MySQL/SQLServer/PostgreSQL/Oracle)，DLA SQL会自动探测底层的索引情况，然后选择合适的字段对TableScan的Split进行拆分，从而加大并发度。这个特性对于RDS数据量很大的时候非常有用。
3.7 MySQL生态的支持
Presto本身实现了自己的client-server端的交互协议，但是由于大量的外围客户端软件/BI软件/调度软件并不支持Presto的这种协议，使得用户在使用上可选择的软件比较受限，很多时候还需要用户自建一些服务。DLA SQL通过在Presto集群前端部署一个SQL接入层节点，并且在SQL接入层中实现了MySQL协议，把用户的MySQL协议过来的请求转给Presto集群，再把Presto集群返回来的数据返回给客户端，使得DLA SQL兼容了MySQL协议，可以使用MySQL生态庞大的周边软件设施，方便了用户，降低用户在这些周边软件上的投入。
3.8 内置完善的权限控制体系
开源Presto在权限控制方面支持的比较简单的(SystemAccessControl)，用户如果要实现完善的权限控制需要去配合另外的组件比如Ranger才能达到权限控制的目的，导致操作复杂无法做到一站式，很多企业因为这种复杂性就直接放弃了权限相关的控制，机密数据有暴露的风险。DLA SQL内置了用户熟悉了MySQL风格的权限控制机制, 你可以使用你熟悉的权限控制语句对权限进行控制，在DLA SQL内部一站式进行数据查询、权限管控的工作：
GRANT SELECT on db001.tbl001 to 'user001';
REVOKE SELECT on db001.tbl001 to 'user001';