超全的数据库建表/SQL/索引规范

我们在集群中引入了一个ResourceManager的模块用于从所有的Coordinator收集所有租户的资源使用信息，ResourceManager把收集到的资源使用信息跟我们预设的计算力的阈值进行对比，计算出哪些租户应该被惩罚，然后把这个惩罚信息通知到所有的Worker。Worker在进行调度的时候会参照ResourceManager通知过来的惩罚信息决定哪些租户的查询得到调度，哪些租户的查询不进行调度。这样不同的租户之间算力就会得到隔离，我们测试了如果有一个租户过量使用资源，它会在最长1.3秒之内得到惩罚，从而释放资源给其它租户，而社区默认版本的“惩罚”要等到租户所有的查询执行完成才会到来。只有元数据和计算力得到隔离，我们才能放心用一个集群来服务我们所有的用户。

2 Multi-Coordinator技术

社区版本的Presto里面，Coordinator是一个单点，它会带来两个方面的问题：

• 可用性隐患: 一旦Coordinator宕机、整个集群将不可用达5到10分钟。
• 无法实现无缝升级，升级过程中影响所有用户的查询使用。

我们采取了如下的架构方案：
 

我们在核心的PrestoDB集群周边建设了诸如接入层、统一元数据等等服务来使得用户可以用得稳定、用得便利，下面我们将在多租户隔离技术和多Coordinator技术的介绍中详细剖析。

1 多租户隔离技术

PrestoDB原生是有资源组的支持，它可以支持在不同资源组间做一定程度的CPU、内存的限制，但是它有一些问题使得我们无法基于它来实现计算力的隔离：

• 全局调度层面：即使一个租户使用了过多的计算力资源也不会及时被惩罚，只有新查询会被Block。
• Worker调度层面：所有租户的Split是在同一个队列里面进行调度，一个租户如果有过多Split会影响其它租户。

我们的计算力多租户方案如下：
 

SparkUI服务是DLA平台自研的多租户UI服务，针对社区方案做了深度优化：

(1)去Eventlog

DLA Spark去掉了Eventlog依赖，在作业结束的时候，Spark Driver只是dump UI的Meta到OSS，保存作业结束前的页面元信息。这部分信息只是相对于Eventlog来说，会大大减少，即使非常复杂的作业也只有MB级别。UiServer读取OSS上的UI Meta，将其反序列化出来即可展示SparkUI页面。

(2)UIServer水平扩展

UIServer主要负责解析历史UI Meta和提供Stderr和Stdout日志服务，是轻量化，无状态的，可以实现水平扩展，进而支持万级别客户同时在线服务。UIServer URL采用加密token作为参数，token代表的用户身份，作业id，UIServer据此实现多租户服务化。

(3)本地日志自动滚动

对于长作业而言，Stderr或者Stdout信息会随着时间增加累积，最终甚至可能打爆磁盘。DLA Spark安全容器内置后台进程，实现日志滚动，保存最有价值的最近一段时间的日志。

五 Serverless SQL服务的技术挑战

DLA Serverless SQL是基于目前托管于Linux基金会之下的PrestoDB打造的云原生数据湖引擎，Alibaba同时也是Presto基金会成员之一，一直在贡献优化Presto。PrestoDB引擎本身具有优秀的特性：

• 全内存计算带来的极致速度。
• 支持完整SQL语义带来的强大表达力。
• 易用的插件机制使得我们可以对任何数据源进行关联查询。
• 强大的社区使得我们使用之后没有后顾之忧。

不过社区PrestoDB是单租户的一个引擎，它假定你是在一个公司内部使用，因此算力隔离、高可用等等方面没有过多投入，这使得要直接使用它来作为云原生服务的引擎存在几个问题：

• 一个用户如果提交大量大查询将可能占用集群所有资源，导致其它用户无法使用。
• 单Coordinator使得整个服务的可用性无法得到保证。

我们做了一系列的优化、改造使得它可以云原生的形态服务所有的用户，今天着重介绍多租户隔离技术以及多Coordinator两个主要的特性。

首先我们看一下DLA Serverless SQL的整体架构：

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!