视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒

频道:小编推荐 日期: 浏览:184
导读:长久以来,对 SQL 和权限的支撑一票预安直是 Druid 的软肋。尽管社区早在 0.9 和 0.12 版别就别离添加了对 SQL 和 Security 的支撑,但依据咱们了解,考虑到功用的成熟度和安稳性,真实把 SQL 和 Security 用起来的用户是比较少的。本次共享将介绍社区 SQL 和 Security 计划的原理,以及美团点评在落地这两个功用的进程中所遇到的问题、做出的改善、和终究获得的作用。下面开端今日的共享:

我今日的共享内容包括四部分。首要,和咱们介绍一下美团对 Druid 的运用现状,以及咱们在构建 Druid 渠道的进程中遇到的应战。第二部分,介绍 Druid SQL 的基本原理和运用办法,以及咱们在运用 Druid SQL 的进程中遇到的问题和做的一些改善。第三部分,介绍 Druid 在数据安全上供给的支撑,以及咱们结合本身事务需求在 Druid Security 上的实践阅历。终究,对今日的共享内容做一个总结。


一、Druid 在美团的现状和应战

1.1 Druid 运用现状

美团从 16 年开端运用 Druid,集群版别从 0.8 开展到现在的 0.12 版别。线上有两个 Druid 集群, 一共大概有 70 多个数据节点。

数据规划上,现在有 500 多张表,100TB 的存储,最大的表每天从 Kaf新凤霞ka 摄入的音讯量在百亿等级。查询方面,每天的查询量有 1700 多万次,这儿包括了一些程序守时主张的查询,比方风控场景中守时触发的多维查询。功用方面,不同的运用场景会有不同的要求,但全体上 TP99 呼应时刻在一秒内的表占了 80%,这和咱们对 Druid 的定位——秒级实时 OLAP 引擎是共同的。


1.2 Druid 渠道化应战

把 Druid 作为一个服务供给给事务运用的进程中,咱们首要遇到了易用性、安全性、安稳性三方面的应战。

易用性:事务会关怀 Druid 的学习和运用本钱有多高,是否能很快接入。咱们知道,Druid 本身对数据写入和查询只供给了依据 JSON 的 API 接口,你需求去学习接口的运用办法,了解各种字段的意义,使动脉硬化用本钱是很高的。这是咱们期望经过渠道化去处理的问题。

安全性:数据是许多事务的中心财物之一,事务十分关怀 Druid 服务能否保证他们的数据安全。Druid 较早的版别对安全的支撑较弱,因而这一块也是咱们上一年重点建造的部分。

安稳性:一方面需求处理开源体系落地进程中呈现的各种安稳性问题,另一方面,如安在查询逻辑不可控的状况下,在一个多租户的环境中定位和处理问题,也是很大的应战。


二、Druid SQL 的运用和改善

在 Druid SQL 呈现之前,Druid 查询经过依据 JSON 的 DSL 来早年有座灵剑山小说表达(下图)。这种查询言语首要学习本钱很高,用户需求知道 Druid 供给了哪些 queryType,每种 queryType 需求传哪些参数,怎么挑选适宜的 queryType 等。其次是运用本钱高,运用需求完成 JSON 恳求的生成逻辑和呼应 JSON 的解析逻辑。


经过 Druid SQL,你可以将上面的杂乱 JSON 写成下面的规范 SQL。SQL 带来的便利是清楚明了的,一方面关于程序员和数据剖析师没有额定的学习本钱,另一方面可以运用相似 JDBC 的规范接口,大大下降了门槛。


2.1 Druid SQL 简介

下面我简略地介绍一下 Druid SQL。


首安信信任先,Druid SQL 是 0.10 版别新增的一个中心模块,由 Druid 社区供给继续的支撑和优化,因而不管是安稳性仍是完善性,都会比其他给 Druid 添加 SQL 方言的项目更好。

从原理上看,Druid SQL 首要完成了从 SQL 到原生 JSON 查询言语的翻译层。由于仅仅做了一层言语的翻译,优点是 Druid SQL 对集群的安稳性和功用不会有很大影响,缺陷是受限于原生 JSON 查询的才干,Druid SQL 只完成了 SQL 功用的一个子集。

调用办法上,Druid SQL 供给了 HTTP 和 JDBC 两种办法来满意不同运用的需求。终究表达力上,Druid SQL 简直能表达一切 JSON 查询能完成的逻辑,而且它能主动帮你挑选最适宜的 queryType。

下面是三个 Druid SQL 的比方。


第一个比方是近似 TopN 查询。关于依据某个方针剖析单个维度 TopN 值的需视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒求,原生的 JSON 查询供给了一种近似 TopN 算法的完成。Druid SQL 可以识别出这种办法,生成对应的近似 TopN 查询。

第二个比方是半视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒衔接。咱们知道 Druid 是不支撑灵敏 JOIN 的,但事务常常会有这样的需求,便是以第一个查询的成果作为第二个查询的过滤条件,用 SQL 表达的话便是 in subquery,或许半衔接。Druid SQL 对这种场景做了特别支撑,用户不需求在运用层主张多个查询,而是写成 in subquery 的办法就行了。Druid SQL 会先履行子查询,将成果物化成外层查询过滤条件,然后再履行外层的查询。

终究是一个嵌套 GroupBy 的比方。Druid SQL 可以识别出这种多层的 GroupBy 结构,生成对应的原生嵌套 GroupBy JSON 。

2.2 Druid SQL 架构


下面介绍 Druid SQL 的全体架构。

Druid SQL 是在查询署理节点 Broker 中完成的功用,首要包括 Server 和 SQL Layer 两个模块。

Server 模块担任接纳和解析恳求,包括 HTTP 和 JDBC 两类 。关于一般的 HTTP 恳求,新增相应的 REST Endpoint 即可。关于 JDBC,Druid 复用了 Avatica 项目的 JDBC Driver 和 RPC 界说,因而只需求完成 Avatica 的 SPI 视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒就行了。由于 Avatica 的 RPC 也是依据 HTTP 的,因而两者可以运用同一个 Jetty Server。

SQL Layer 担任将 SQL 翻荣耀帝国译成原生的 JSON 查询,是依据 Calcite 项目完成的。Calcite 是一个通用的 SQL 优化器结构,可以将规范 SQL 解析、剖析、优化成详细的履行计划,在大数据范畴得到了广泛的运用。图中浅绿色的组件是 Calcite 供给的,浅蓝色的组件是 Druid 完成的,首要包括三个。

首要,DruidSchema 组件为 Calcite 供给查询解析和验证需求的元数据,例如集群中包括哪些表,每张表各个字段的称号和类型等信息。RulesSet 组件界说了优化器运用的转换规矩。由于 Druid SQL 只做言语翻译,因而这儿都是一些逻辑优化规矩(例如投影消除、常量折叠等),不包括物理优化。经过 RulesSet,Calcite 会将逻辑计划转成 DruidRel 节点,DruidRel 包括了查询的一切信息。终究,QueryMaker 组件会测验将 DruidRel 转成一个或多个原生 JSON 查询,这些 JSON 查询终究提交到 Druid 的 QueryExecution 模块履行。

2.3 API 挑选: HTTP or JDBC

Druid SQL 供给了 HTTP 和 JDBC 两种接口,我应该用哪个?咱们的阅历是,HTTP 适用于一切编程言语,Broker 无状况,运维较简略;缺陷是客户端处理逻辑相对较多。JDBC 关于 Java 运用更友爱,可是会导致 Broker 变成有状况节点,这点在做杂乱均衡时需求分外留心。别的 JDBC 还有一些没有处理的 BUG,假如你运用 JDBC 接口,需求额定重视。


2.4 改善

下面介绍咱们对 Druid SQL 做的月饼歌一些改善。

第一个改善是关于 Schema 推导的功用优化。咱们知道 Druid 是一个 schema-less 体系,它不要求一切的数据的 schema 相同,那怎么界说 Druid 表的 schema 呢?社区的完成办法是:先经过 SegmentMetadataQuery 核算每个 segment 的 schema,然后兼并 segment schema 得到表的 segment,终究在 segment 发生变化时从头核算整个表的 schema。

社区的完成在咱们的场景下遇到了三个问题。第一是 Broker 发动时刻过长。咱们一个集群有 60 万个 segment,测验发现光核算这些 segment 的 schema 就需求半小时。这会导致 Broker 发动后,需求等半个小时才干供给服务。第二个问题是 Broker 需求在内存中缓存一切 Segment 的元数据,导致常驻内存添加,别的 schema 刷新会带来很大的 GC 压力。第三个问题是,社区计划提交的元数据查询量级与 Broker 和 Segment 个数的乘积成正比的,因而扩展性欠好。


针对这个问题,咱们剖析事务需求和用法后发共和国之辉现:首要 schema 变更是一个相对低频的操作,也便是说大部分 segment 的 schema 是相同的,不需求去重磷火角财富走运哪里多复核算。别的,绝大数状况事务都只需求用最新的 schema 来查询。因而,咱们的处理计划是,只运用最近一段时刻,而不是一切的 segment 来推导 schema。改造后,broker 核算 schema 的时刻从半小时下降到了 20 秒,GC 压力也明显下降了。


第二个优化是关于日志和监控。恳求日志和监控方针是咱们在运维进程中重度依靠的两个东西,比方慢查询的定位、SLA 方针的核算、流量回放测验等都依靠日志和监控。可是 0.12 版别的 SQL 既没有恳求日志,也没有监控方针,这是在上线前必需求处理的问题。咱们的方针有两个:首要能记载一切 SQL 恳求的基本信息,例如恳求时刻、用户、SQL 内容,耗时等;其次能将 SQL 恳求和原生的 JSON 查询相关起来。由于履行层面的方针都是 JSON 查询粒度的,咱们三轮车需求中药找到 JSON 查询对应的原始 SQL 查询。


咱们的处理计划现已兼并到 0.14 版别。首要,咱们会给每个 SQL 恳求分配仅有的 sqlQueryId。然后咱们扩展了 RequestLogger 接口,添加了输出 SQL 日志的办法。下图是一个比方,关于每个 SQL 恳求,除了输出 SQL 内容外,也会输出它的 sqlQueryId,可以用来与客户端的日志做相关。还会输出 SQL 对应的每个 JSON 查询的 queryId,可以用来和 JSON 查询做相关剖析。


第三个改善尽管比较小,可是对服务的安稳性很重要。咱们知道,JSON 查询要求用户指定查询的时刻规模,Druid 会运用这个规模去做分区裁剪,这对进步功用非豆贝教育网常重要。可是 Druid SQL 并没有这方面的约束。用户写 SQL 常常会忘掉加时刻规模的限制,然后导致全表扫描,占用很多的集群资源,是一个很大的危险。所以咱们添加了对 wh英国大学排名ere 条件的查看,假如用户没有视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒指守时刻戳字段的过滤条件,查询会直接报错。


三、Druid Security 的实践阅历

首要介绍咱们在数据安全上面对的问题。其时运用的是好男人影院 0.10 版别,这个版别在数据安全上没有任何的支撑,一切的 API 都没有拜访操控,任何人都能拜访乃至删去一切的数据,这对事务的数据安全来说是一个十分大的危险。

咱们期望完成的方针有五点:一切 API 都经过逍遥小神医金富有认证、完成 DB 粒度的权限操控、一切数据拜访都有审计日志、事务能滑润升级到安全集群、对代码的改动侵入性小。

为了完成这些方针,咱们首要调研了 Druid 在后续版别中新增的安全功用。


3.1 Druid Securit颜如玉y 功用和原理

0.11 版别支撑了端到端的传输层加密(T视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒LS),可以完成客户端到集群,以及集群各个节点之间的传输层安全。0.12 版视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒本引入了可扩展的认证和鉴权结构,而且依据这个结构,供给了 BA 和 Kerber视频解析,Druid SQL 和 Security 在美团点评的实践,亦舒os 等认证办法,以及一个依据人物的鉴权模块。


下面这张图介绍认证鉴权结构的原理和装备。



3.2 Druid Security 社区计划缺陷

社区计划能有道词典在线翻译满意咱们大部分的需求,但还存在一些问题。

第一个问题是咱们发现浏览器对 BA 认证的支撑很差。因而关于 Web 操控台,咱们期望走一致的 SSO 认证。

第二个问题是为了支撑事务滑润过渡到安全集群,上线初期有必要兼容非认证的恳求,其时咱们运用的 0.12 版别没有该功用。

第三个问题是社区依据人物的鉴权模块只供给了底层的办理 API,用户直接运用这些 API 十分不方便。

终究一个问题是社区还不支撑审计日志。


针对这些问题,咱们做了三个首要的改善。

3.3 改善

改善一:依据 DB 的拜访操控

首要,为了简化权限的办理,咱们引入了 DB 的概念,并完成了 DB 粒度的拜访操控。事务经过 DB 的读写账号拜访 DB 中的表。


改善二:主动办理权限 DB

经过使命接入渠道保护 DB 和 DataSource 的映射联系,并在 DB 和 DataSource 发生变化时,调用鉴权模块接口更新权限 DB。


改善三:支撑 SSO 认证和非认证拜访

自界说认证链条,经过 SSO 认证 Filter 完成 Web 操控台的 SSO 认证,经过非安全拜访 Filter 兜底,兼容非认证的恳求。


留心事项

  1. 运用 0.13 以上版别 (或许 cherrypick 高版别的 bugfix)
  2. 上线流程
  • 启用 basic-security 功用,用 卡盟刷钻渠道allowAll 兜底
  • 初始化权限 DB,创立匿名用户并授权
  • 将 allowAll 替换为 anonymous
  • 逐渐收回匿名用户的权限
  1. 上线次序:coordinator->overlord->broker->historical->middleManager

四、总结

4.1 关于 SQL

  1. 假如还在用原生的 JSON 查询言语,强烈主张试一试
  2. 社区在不断改善 SQL 模块,主张运用最新版别
  3. Druid SQL 本质上是一个言语翻译层
  • 对查询功用和安稳性没有太大影响
  • 受限于 Druid 本身的查询处理才干,支撑的 SQL 功用有限
  1. 要留心的坑
  • 大集群的 schema 推导功率
  • Broker 需求等 schema 初始化后再眼皮肿是怎么回事供给服务(#6742)

4.2 关于 Security

  1. Druid 包括一下 Security 特性,主张升级到最新版别运用
  • 传输层加密
  • 认证鉴权结构
  • BA 和 Kerberos 认证
  • RBAC 鉴权
  1. 认证鉴权结构满足灵敏,可依据本身需求扩展
  2. 阅历出产环境检测,完成度和安稳性满足好
  3. 上线前应充分考虑兼容性和节点更新次序

作者介绍:

高大月,Apache Kylin PMC 成员,Druid Commiter,开源和数据库技能爱好者,有多年的 SQL 引擎和大数据体系开发阅历。现在在美团点评担任 OLAP 引擎的内核开发、渠道化建造、事务落地等作业。

本文来自 高大月 在 DataFun 社区的讲演,由 DataFun 编辑整理。

热门
最新
推荐
标签