告别“纷纷扰扰”—小米OLAP服务架构演进

1,840 阅读7分钟

                                                      背景

>>>>

What’s OLAP?

如果你是一名数据分析师,或者是一位经常和 SQL 打交道的研发工程师,那么 OLAP这个词对你一定不陌生。你或许听说过 OLAP、OLTP 技术,但是今天文章的主角OLAP 是由云技术平台提供的一款分布式数据分析服务,下面先简单介绍一下它。
小米 OLAP 是集存储计算于一体的分布式数据分析型数据库服务,通过 Kudu 实现“热数据”的实时写入和更新,通过自定义窗口定期迁移“冷数据”到HDFS,并以Parquet 格式存储,实现了冷热数据分离的架构,最终通过 SparkSQL 引擎提供同时对实时数据和历史数据进行分析的能力。
>>>>

OldArchitecture & Drawbacks

                                      图1. OLAP 1.0元数据与权限管理

过去究竟有哪些“纷纷扰扰”呢,让我们先从 OLAP1.0 版本的元数据与权限管理图说起。可以看到,在旧版的架构中,Kudu表相关的权限和元数据与Hive表相关的权限和元数据,无论在实现上还是底层存储上都是分离的。前者通过我们自己实现的Metadata Cache 和 Privilege Cache 与 OLAP 服务的组件 Metastore Manager 及SparkSQL 引擎进行交互,数据存储在 Kudu 上;后者则使用了独立的服务 Hive Metastore(HMS) 和 Sentry 分别进行元数据与权限的管理,底层数据存储在 MySQL 数据库。了解完旧版本的架构,就可以更彻底地了解这样的架构带来了的问题:

1、用户角度:

(1)用户使用 OLAP 服务时,如果要访问 Kudu 表,需要对 SparkSQL队列进行特殊配置,以开启对 Kudu 数据源的支持。

(2)虽然早期架构在代码层对meta 做了合并,但是并未从根本上解决权限分离的情况。比如用户通过 Hive 授权的某个数据库A,通过 OLAP 系统授权了某个数据库B,在 OLAP 系统是无法看到数据库A的相关表信息的。还会出现用户有Kudu表权限但没有 Hive 表权限的情况。上述情况不利于用户数据的打通,还会让用户在使用过程中产生疑惑。同时,用户需要切换队列配置重启服务,使用上也不够友好。

2、开发角度:

Metadata Cache 和 Privilege Cache 在实现上存在冗余,其和底层元数据的交互在两个组件都存在。其维护和开发成本比较高,没有统一入口和规范。同时,底层分离的元数据和权限并不利于后续统一的 SQL Proxy 的开发。

可以看到,无论从用户的角度,还是开发者的角度,进行底层元数据和权限的架构整合都非常必要。

                                           和“纷纷扰扰”说再见

介绍完了过往的“纷纷扰扰”,让我们看看如何和“纷纷扰扰”说再见。从图1可以看出,解决这种分离的最简单方法就是复用现有的 HMS 和 Sentry 组件,将原有的元数据和权限数据迁移到 MySQL 数据库,同时更改上层组件的在元数据和权限部分的交互方法,包括 SparkSQL 层和 OLAP 服务端组件(OLAP Server、Metastore Manager 和 Dynamic Manager)。
图2. OLAP 2.0元数据与权限管理
更改后的元数据与权限管理图如上所示。下面我们分为两部分来介绍相关的工作。
>>>>

MetadataFederation

元数据整合方面,我们引入了 Kudu Storage Handler,其实现了 Hive Meta Hook的接口,继承了 DefaultStorageHandler 类,可以与 HMS 进行交互,完成了对 Kudu meta 的相关操作。在原版的基础上,我们补充了分区和表的相关操作,以及一些必要的rollup操作来保证 meta 的一致性。
在 SparkSQL 层,对 Kudu meta 的调用方式转化为了直接使用 Kudu Storage Handler,原有的 Kudu 相关模块的功能直接整合进 Hive 模块,包括了查询、建表、删除表、修改表、展示建表语句等操作。我们大体兼容了旧版本的 DML 语法,并通过 tblproperties 来传递各种 Kudu 相关的信息,比如表名、range 分区信息、hash分区信息等,同时,我们自定义的信息和数据流部分信息也存在表属性里,供上层程序使用,比如是否 OLAP 表、OLAP 窗口值等。
在 OLAP 服务端,我们对所有元数据相关的部分做了重构。原有的 Metadata Cache被移除,有关的元数据的操作通过调用 HMS Client 提供的 API 来实现。同时,我们把系统相关的数据从 Kudu 迁移到 MySQL 数据库,使整个服务端不再对 Kudu Client有直接的依赖。
经过上述整合,所有的meta操作统一到了 Hive MetastoreClient 层,通过 Kudu Storage Handler 实现,数据存储在 MySQL,和对 Hive meta 的操作一致。对于开发者,这种架构整体上更为清晰,在修改和维护上也更方便。对于用户来说,通过beeline 去操作 Kudu 表和 Hive 表除了在建表语法上不同,其他基本操作和 Hive 没有区别,用户在建表后基本不需要关心底层存储介质,体验上更加一致。
>>>>

PrivilegeFederation

权限整合的前提是 Kudu 相关元数据已经整合到了 HMS 中,这样才能借助 Sentry 进行权限管理。基于此,我们需要实现鉴权和授权两条通路。
在 SparkSQL 层,由于本身 Hive 模块就已经集合了 Sentry 用来做权限鉴定,所以元数据迁移过来以后,beeline 的操作都会通过 Sentry 进行鉴权,而授权部分目前SparkSQL 的语法还不支持。
在 OLAP 服务端,我们对原有权限相关的操作进行了重构。原有的 Privilege Cache 被移除,所有权限相关的操作通过调用 Sentry Client API 实现,包括鉴权、授权、移除权限和权限展示。在权限展示方面,由于 Sentry 本身的模型限制,提供的 AP I无法满足需求,我们根据自身需要进行了定制化开发,如增加了相应的 API 实现基于用户角色的权限获取等。
经过权限上的整合,Kudu 和 Hive 的所有权限就打通了,并可以通过 Sentry 统一提供权限相关的服务。

                                                   总结与展望

>>>>

小结

经过元数据与权限的整合,OLAP 服务的元数据范围和权限范围都扩大了,同时意味着查询的范围也扩大了。新的架构如下图所示,meta 相关的服务最终都由 Hive Metastore 来提供,权限相关的服务最终都由 Sentry 来提供,我们只需要在各层通过客户端接口进行调用即可。
New Architecture
图3. OLAP 2.0架构图
>>>>

展望

基于整合后的架构,未来我们可以提供更多的能力,比如基于HMS的元数据服务,基于Sentry的权限服务。未来,我们计划支持更多的数据源,比如MySQL数据源,整合更多的SQL引擎,比如 Hive、Kylin 致力于打造统一的SQL引擎服务。