背景
若是你是一名数据分析师，或者是一位常常和 SQL 打交道的研发工程师，那么 OLAP这个词对你必定不陌生。你或许据说过 OLAP、OLTP 技术，可是今天文章的主角OLAP 是由云技术平台提供的一款分布式数据分析服务，下面先简单介绍一下它。
小米 OLAP 是集存储计算于一体的分布式数据分析型数据库服务，经过 Kudu 实现“热数据”的实时写入和更新，经过自定义窗口按期迁移“冷数据”到HDFS，并以Parquet 格式存储，实现了冷热数据分离的架构，最终经过 SparkSQL 引擎提供同时对实时数据和历史数据进行分析的能力。
>>>>
OldArchitecture & Drawbacks架构
过去究竟有哪些“纷纷扰扰”呢，让咱们先从 OLAP1.0 版本的元数据与权限管理图提及。能够看到，在旧版的架构中，Kudu表相关的权限和元数据与Hive表相关的权限和元数据，不管在实现上仍是底层存储上都是分离的。前者经过咱们本身实现的Metadata Cache 和 Privilege Cache 与 OLAP 服务的组件 Metastore Manager 及SparkSQL 引擎进行交互，数据存储在 Kudu 上；后者则使用了独立的服务 Hive Metastore(HMS) 和 Sentry 分别进行元数据与权限的管理，底层数据存储在 MySQL 数据库。了解完旧版本的架构，就能够更完全地了解这样的架构带来了的问题：分布式
一、用户角度：post
（1）用户使用 OLAP 服务时，若是要访问 Kudu 表，须要对 SparkSQL队列进行特殊配置，以开启对 Kudu 数据源的支持。spa
（2）虽然早期架构在代码层对meta 作了合并，可是并未从根本上解决权限分离的状况。好比用户经过 Hive 受权的某个数据库A，经过 OLAP 系统受权了某个数据库B，在 OLAP 系统是没法看到数据库A的相关表信息的。还会出现用户有Kudu表权限但没有 Hive 表权限的状况。上述状况不利于用户数据的打通，还会让用户在使用过程当中产生疑惑。同时，用户须要切换队列配置重启服务，使用上也不够友好。.net
二、开发角度：blog
Metadata Cache 和 Privilege Cache 在实现上存在冗余，其和底层元数据的交互在两个组件都存在。其维护和开发成本比较高，没有统一入口和规范。同时，底层分离的元数据和权限并不利于后续统一的 SQL Proxy 的开发。继承
能够看到，不管从用户的角度，仍是开发者的角度，进行底层元数据和权限的架构整合都很是必要。接口
和“纷纷扰扰”说再见
介绍完了过往的“纷纷扰扰”，让咱们看看如何和“纷纷扰扰”说再见。从图1能够看出，解决这种分离的最简单方法就是复用现有的 HMS 和 Sentry 组件，将原有的元数据和权限数据迁移到 MySQL 数据库，同时更改上层组件的在元数据和权限部分的交互方法，包括 SparkSQL 层和 OLAP 服务端组件(OLAP Server、Metastore Manager 和 Dynamic Manager)。
更改后的元数据与权限管理图如上所示。下面咱们分为两部分来介绍相关的工做。
元数据整合方面，咱们引入了 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 没有区别，用户在建表后基本不须要关心底层存储介质，体验上更加一致。
权限整合的前提是 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
基于整合后的架构，将来咱们能够提供更多的能力，好比基于HMS的元数据服务，基于Sentry的权限服务。将来，咱们计划
支持更多的数据源，好比MySQL数据源，
整合更多的SQL引擎，好比 Hive、Kylin 致力于打造统一的SQL引擎服务。
