告别“添麻烦”——小米OLAP服务架构演进--陈奇网络工作室

云计算

背景

what’solap？

如果你是数据分析师或经常与SQL交流的研发工程师，OLAP这个词你可能不熟悉。你可能听说过OLAP，OLTP技术，今天文章的主角OLAP是云技术平台提供的分布式数据分析服务。我先简单介绍一下那个。

小米OLAP是一种集存储于一身的分布式数据分析数据库服务，通过Kudu实现“热数据”的实时写入和更新，通过定制窗口定期将“冷数据”迁移到HDFS，parard

OldArchitecture Drawbacks

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

过去发生了什么“麻烦”，我们先从OLAP 1.0版的元数据和权限管理图开始。在旧版本的模式中，可以看到与Kudu表相关的权限以及与元数据和Hive表相关的权限和元数据在实现上和底层存储上都是分离的。前者通过我们自己实现的元数据缓存和权限缓存与作为OLAP服务组件的元数据管理器和SparkSQL引擎进行交互，数据保存在Kudu中；后者使用hivemetastore(HMS )和Sentry这两种独立的服务分别管理元数据和权限，底层数据存储在mysql数据库中。了解旧版本的体系结构后，就可以更透彻地理解这些体系结构带来的问题。

1、用户观点：

)1)如果用户使用OLAP服务，则必须专门配置SparkSQL队列才能访问Kudu表，以打开对Kudu数据源的支持。

)2)初始体系结构在代码级别合并了元，但没有从根本上解决权限分离的情况。例如，用户经Hive授权的某个数据库a、OLAP系统授权的数据库b在OLAP系统中不能看到关于数据库a的表信息。用户可能具有Kudu表权限，但没有Hive表权限。这种情况不利于用户数据的直通，用户在使用中也可能产生疑问。另外，用户需要切换队列并重新启动服务，使用起来也不方便。

2、开发角度：

元数据缓存和权限缓存在实现中具有冗馀性，并且与基础元数据的交互存在于这两个组件中。其维护和开发成本比较高，没有统一的入口和规范。另外，在较低级别分离的元数据和权限不利于之后统一的SQL Proxy的开发。

无论从用户的角度还是从开发人员的角度来看，都需要底层元数据和权限的体系结构集成。

说“一个接一个地给你添麻烦”再见

介绍完过去的“一个接一个的麻烦”后，看看如何说“一个接一个的麻烦”和再见。从图1可以看出，解决该隔离的最简单的方法是重用现有的HMS和Sentry组件，将现有的元数据和权限数据迁移到Mysql数据库，同时SparkSQL层和OLAP服务端组件更改顶级组件(如元数据管理器和动态管理器)在元数据和权限部分的交互方式

图2. OLAP 2.0元数据和权限管理

更改后的元数据和权限管理图如上。将相关工作分为两个部分进行介绍。

元数据联邦

在元数据集成方面，引入了Kudu Storage Handler，它实现了Hive Meta Hook的接口，继承了DefaultStorageHandler类，可以与HMS进行交互，完成了Kudu meta的相关操作在原始基础上，添加了分区和表操作，以及确保元完整性所需的rollup操作。

在SparkSQL层，对Kudu meta的调用方式转换为直接使用Kudu Storage Handler，现有Kudu相关模块的功能直接集成到Hive模块中，进行查询、表的创建、表的删除、表的修改、表的创建、成文它与早期版本的DML语法几乎兼容，通过tblproperties传递各种与Kudu相关的信息，包括表名、范围分区信息和散列分区信息，以及一些定制信息和数据流信息例如，OLAP表、OLAP窗口值等。

在OLAP服务器端，我们重建了元数据相关的所有部分。传统的元数据缓存被删除，相关的元数据操作通过调用HMS客户端提供的API来实现。同时，将系统相关数据从Kudu迁移到MYSQL数据库，使整个服务器不直接依赖于Kudu客户端。

经过上述集成，所有的元操作统一在Hive MetastoreClient层，通过Kudu Storage Handler实现，数据存储在MySQL中，与对Hive meta的操作一致。对于开发人员来说，该体系结构总体上是明确的，也便于修改和维护。对于用户来说，在beeline上操作Kudu表和Hive表，不仅是因为制作表的语法不同，其他的基本操作和Hive没有区别，用户在制作表之后，几乎不需要在意底层的存储介质，体验上更加一致。

权限联邦

权限合并的前提是与Kudu相关的元数据被集成到HMS中。这样，就可以使用Sentry进行权限管理。在此基础上，需要实现认证和授权两条路径。

在SparkSQL层，SparkSQL语法目前不支持beeline操作，因为它自己的Hive模块已经收集了Sentry用于权限验证，元数据迁移后将通过Sentry验证beeline操作

在OLAP服务器端，重建了与原始权限相关的操作。传统的权限缓存已被删除，所有与权限相关的操作(如身份验证、授权、删除权限和查看权限)都是通过调用Sentry Client API实现的。在权限的展示中，由于Sentry自身的模型限制，提供的AP I无法满足需求，添加合适的AP I实现基于用户角色的权限获取等，根据自己的需求进行了定制开发。

通过权限整合，Kudu和Hive的所有权限都相通了，可以在Sentry中统一提供与权限相关的服务。

总结与展望

总结

元数据和权限的集成扩大了OLAP服务器的元数据范围和权限范围，也扩大了查询的范围。新体系结构如下图所示，元相关服务最终由Hive Metastore提供，权限相关服务最终由Sentry提供。只需在每一层通过客户端接口调用。

新架构

图3. OLAP 2.0体系结构图

展望

基于统一的体系结构，将来可以提供更多功能，包括基于HMS的元数据服务、基于Sentry的权限服务等。未来，我们计划

支持更多数据源，例如MySQL数据源。

我们正在努力整合更多的SQL引擎，如Hive和Kylin，以构建统一的SQL引擎服务。

作者：小米云技术

链接： https://juejin.im/post/5d 679125 f 265 da 03 b 46 c01 b 3

来源：掘金

版权归作者所有。商业转载请联系作者取得许可。非商业转载请注明出处。

详情请访问云服务器、域名注册、虚拟主机的问题，请访问西部数码代理商官方网站： www.chenqinet.cn

相关推荐