深度剖析! 广发证券 Apache Kyuubi 构建“提效可控”大数据赋能层
The following article is from Apache Kyuubi Author 梁博文
导读 广发证券于 2023 年 11 月成为通过中国首个数据管理领域国家标准 DCMM 数据管理能力成熟度评估获得管理量化级（四级）的首批券商之一，目前上万个 Kyuubi 作业已成为广发数据综合治理和关键数据体系的核心部分。
本文作者为广发证券大数据平台架构师梁博文，参与了 Apache Kyuubi 项目孵化并成为 PMC 成员。本文主要介绍和讨论了广发证券大数据平台围绕数智中台战略和敏态数据时代挑战为切入，重点围绕“提效可控”四大关键转型目标，基于 Apache Kyuubi 构建大数据赋能层及一体化权控思路的架构分析、落地策略、全链路效益提升。同时作为 Apache Kyuubi 的使用者和贡献参与者，在业界与社区共建未来探索进行展望与预期。
分享嘉宾｜梁博文 广发证券 大数据平台架构师
出品社区｜DataFun & Apache Kyuubi
对广发证券大数据平台而言，我们希望在理解自身使命和对架构的预期基础上，跟踪大数据生态技术，进而确定数据赋能转型方向并确定大数据赋能层的目标、收益与决断点。
在考虑以数据赋能转型前的方向，先来回顾一下当前整体大数据平台的现状与潜在瓶颈。
统一的大数据平台底座核心首先包括了 Hadoop 底座以及 Hive Metastore 服务，其中 Hadoop 提供的 HDFS/YARN 持续提供可靠的分布式计算存储能力，是整体对接大数据生态的基础。而 Hive Metastore 则是作为统一的大数据数仓标准，为对接各项引擎提供数仓信息，是所有数据场景的基础。我们在各时期此基础上引入了三种引擎，分别是 Hive MR、Trino、Spark 各自承担不同的作用，首先 HiveMR 是提供最终的查询、加工的分布式执行方案，也统一使用 HiveSQL 作为逻辑界面。其次是为了解决查询场景对速度的诉求，引入了 Trino/PrestoSQL 作为 Adhoc 和 BI 的 OLAP 查询引擎，因其可能存在单点的架构局限和曾遇到 0day 计算错误而仅用作查询，且 Trino 独立的语法会成为独立于 HiveSQL 的资产包袱。同时在部分场景引入了 Spark 引擎作为兼容 HiveSQL 的 ETL 计算引擎，但 SparkSQL 迟迟没有合适的方案而无法成规模作为类似 HiveServer 的方式进行规模化使用。
1. 查询与加工的引擎界面不一致。由于 Trino 在数据探索时候性能提升巨大，数据开发往往先用 Trino 进行数据探索，而 Trino 语法与 HiveSQL 语法不兼容，导致需要改写并验证一次再次组装成数据加工逻辑。往返周折费时费力。
2. 依赖组件细节接入方而言过于繁复。数据研发上在对接大数据平台时，开发一个大数据作业需要考虑多种因素，从技术栈版本到配置通路细节，包括数仓元数据服务 HMS、引擎（Spark 等）、存储格式、表格式等。造成开发、调试、运行的一系列成本而人效大幅降低，无法专注于完成业务数据逻辑。
3. 大数据平台无法整体演进服务组件版本。当作业具体决定了组件的搭配与细节，意味着大数据平台更多是作为资源底层提供服务，而无法按最新的评估和业务需求，统一遮蔽和演进引擎版本、引入新的协调服务、管控底层资源等。
4. 权限在特定渠道控制，无法作为通用服务开放赋能，只能在局限于特定的应用层服务。金融行业强监管需求导致必须在特定平台的特定场景下，来满足列表权限检查、涉密内容过滤 SQL 改写、集中化审计等要求。应用层如数据门户等的改写可以满足上述需要，但显著约束了大数据平台在通用场景下的对接可能性。
大数据赋能层的目标定位，除了回顾现状和历史演进包袱，我们还需从一个更远的视角来理解整体挑战，才能保障我们的演进方向和方式。
从宏观挑战上说，一体化数据中台带来数据生命周期在各个阶段带来的全方位挑战，必须在大数据赋能层统一满足：
1. In 数据摄入：具备从多源异构数据摄入到数据湖的能力，包括流式、批式、结构化、非常结构化等多种形态数据来源，需要具备多 catalog 能力。
2. Out 数据输出：推送有效的数据资产到场景直接形成具体数据支撑能力，适应不同的 schema 统一而后转化。
3. With 协同计算：已逻辑数据湖的方式，将不同 catalog 和异构数据源参与到现场的计算，已计算通达部分取代传统采数，同样是异构数据源的读写能力，同时要求统一的逻辑视图。
4. Over 复杂关联：满足即席查询和数据探索，具备多层次的复杂关联计算能力，同时在面对海量数据充分发挥 CBO、RBO 尽量提升查询响应效能，具备结果直出到 BI、AdHoc 等场景。
5. Of 数据治理：数据综合治理对元数据和血缘关系提出了全新的要求，需要数据中台和大数据平台对数据生命周期尤其是数据加工，能够主动感知数据变动的流向和细粒度关系，同时进一步沉淀数据治理的结果运用在全生命周期之中。
从微观挑战上说，数据的加工方式和输出形态也发生了很大的变化，统一底座需要满足这些指标化/标签化、混合形态、弹性场景带来的新要求：
1. 指标化/标签化：数据输出方式从单一传统宽表进行指标输出，更多以逻辑形态结合复杂关联在运行时动态组合进行输出。这要求我们必须在行过滤上具备能力，进行数据管控与执行计划优化。同时满足多层次窄表与复杂宽表形态支持。同时指标化标签化的数据加工也会要求对同一资源领域进行多点分散并行加工的并发能力。
2. 混合形态：以一体化解决方案，解决多种存储架构，包括逻辑数据湖和异构存储带来的挑战，具备多 Catalog 协同计算能力，同时满足仓表、流表、维表等各种逻辑和存储形态的参与计算的资源实体。
因此综合来看，无论从宏观还是微观，以传统大数据 4V 特性即规模性（Volume）、多样性（Varity）、高速性（Velocity）和价值性（Value）来面对当前的挑战已经不再完全适合。
“敏态数据” Agile Data 是广发证券大数据平台对全新数据时代的理解和抽象。敏态数据要求以数据赋能的方式构建数据中台，以更积极的数据活性和更有效的数据成熟度，将数据自身浅出深入场景中，更广泛地被运用和支撑大小形态的数据场景中，同时内部以多种混合数据形态来响应在计算和存储上的挑战。
敏态数据 AgileData 的四大特征可归纳为“HEAD”，即混合形态 Hybrid、数据成熟度 Enabling、数据活性 Active、弹性算力 Dynamic。
1. 混合的数据形态 Hybrid：向上提供统一的接入形态，向下综合运用多种数据形态，包括湖仓一体、流批一体、异构多Catalog等手段，将数据已开放式的形态统一进行处理，不追求单一引擎上的特性，而作为通用要求来对数据和引擎进行综合考察和纳管。
2. 有效的数据成熟度 Enabling：以成熟有效的数据驱动数据场景，经过良好的数据治理和数据管控，并达到可靠的数据质量满足数据规范。数据平台本身要使能这些过程所需的要素，更重要的是通过持续迭代数据成熟度，数据平台与数据业务相互成就价值。
3. 就绪的数据活性 Active：数据产品、指标化、标签化，逻辑/物理灵活形态输入输出，即时、就绪、有效
4. 弹性的数据算力 Dynamic：细粒度动态伸缩的算力平台，全域集成的适应性数据引擎，大规模算力与多租户。
结合以上分析和基于数据中台战略为背景，整体数据平台可向敏态数据平台转型，以主动赋能的形态将大数据平台的数据能力对外输出。
以往，大数据平台自身就是数据赋能的瓶颈，上下游对接方都会成为赋能上有更多无法响应的诉求。数据开发在面对各种数据场景缺少对平台能力进行体系化分析手段，只能更多给大数据平台提出更垂直化数据链路诉求，再用最小路径以散乱的技术方式组合满足。而运维管理作为运行时的资源管控和系统管理，对大数据平台提出了资源、权限、可用性、稳定性等各个诉求，大数据平台在切入数据生命周期之中疲于奔命，只能以更低的保障手段满足，同时舍弃演进的可能和路径。
转型后，大数据赋能层自身通过低成本的统一接入手段、统一的高性能弹性算力引擎、统一的数仓管理和统一的资源权控等管控措施，同时还在底层具备与数据治理和数据管控双向对齐元数据、规则、标准等的内在成熟度提升手段。此时，数据开发可以灵活以标准化的能力按需投入到各个数据应用场景，从要求海量计算能力的数据加工场景到复杂逻辑关联且时效要求高的数据展示和指标输出。同时，运维管理的诉求和管控直接落地到大数据赋能层，对数据开发进行在权限、存储、计算等进行精细化的赋能和管控。大数据平台架构本身也得以专注摄入更多符合敏态数据场景的技术并统一到数据中台之中。
控：可控是金融场景的生命线，对数据权限、资源配额、审计、监控上全方位的满足。通过细粒度数据管控能力，为精细化数据管控提供可能，兼容多域异构数据源管控，并以此作为数据可控开放的前提。在资源管控上可以精细化区分各数据线各终端用户在资源、权限上的管控与差异，精细化管控运行时调优参数。提供一体化的审计收集与管控，并提升服务运行与查询定位能力。 可：可持续迭代、可持续演进、可用性。在统一的计算接入界面下，底座持续提升引擎版本和总体大数据技术栈，兼容多域异构数据源和存储底层细节，充分发挥业界在 CBO、RBO、RBO 等方面的成果持续提升执行计划中的优化，达到对存量数据和存量计算作业的迭代优化。可持续演进即是可扩展可扩充更多大数据技术和关键生命周期协调服务，以更具弹性的能力对外集成化标准化数据及服务。可用性即在原有分布式的存算能力基础上，进一步巩固全层次包括引擎层和执行层的高可用能力，赋予数据场景可靠的运行能力和算力保证能力。 效：全生命周期提效，覆盖数据对接和数据赋能的事前（接入准备等）、事中（运行效率、权限管控和行过滤实现）、事后（审计、收集血缘、补充元数据信息等）。提升执行效率，在同一份数据和逻辑的情况持续体现执行计划优化而带来的收益。提升数据开发按人力效率，统一以 SQL 抽象方式聚焦数据逻辑对数据完成查询机加工，显著降低接入环境要求和条件准备。 提：兼顾存量数据资产和数据作业为基准，降低破坏性变更对已有数据资产的影响，同时大幅提升其数据响应性及数据效率。统一低成本的 SQL 接入方式和编程界面，遮蔽底座基础设施细节对接入的数据作业要求，提供轻量化接入方式，并尽量降低语言环境要求。统一不同用途场景下的对接方式，以统一精细化调优令全场景收益。
在“提效可控”大数据赋能层的总体目标之下，Apache Kyuubi 进入我们的架构评估视野。Apache Kyuubi常被首先作为 SparkSQL 服务网关层的可选服务，Spark 及 Spark SQL 作为成熟稳定且持续演进的计算引擎在不同数据范围都有良好的表现与演进能力。但 Apache Kyuubi 总体定位作为分布式多租户 serverless 的湖仓数据网关门户，赋予了他更大的使命可可能性。
在数据中台中构建大数据赋能层，将服务和能力以交钥匙的方式提供给上下游，通过合理的架构搭配实现平台与数据业务互相成就。结合 Kyuubi 作为大数据赋能层的统一架构方案之一，我们将预期与目标在架构上对接：
1. 统一接入：标准化以 Hive Thrift 协议使用 JDBC Driver，兼顾多语言环境低成本接入。同时通过 namespace 选用合适的服务并通过 JDBC Driver 上提供服务发现满足高可用支持，无须使用方额外实现。
2. 统一 SQL 能力：以 SparkSQL 对外，兼容 HiveSQL 语法为已有数据作业和资产平滑过渡提供可能，并通过额外特性语法并结合 Iceberg 数据湖格式提供 update/delete/merge 等关键的数据延展加工能力。底层集中化按场景需要优化读写配置、特性开关、启用 AQE 等。
3. 遮蔽底层细节：1 无感兼容使用 Iceberg 表，满足 CRUD 操作。2 按平台需要引入和演进底座引擎版本，1 是当前 Spark 最新稳定发行版 3.3，2 是可以继续纳管 Flink 及 Trino 引擎。
4. 权限控制：全面覆盖认证与鉴权的需要。用户认证在 server 层连接点为终端用户的接入进行，灵活组合 JDBC、token 校验等方式。而鉴权则是深入到执行引擎内部，提供 Spark 对接 Ranger 权限控制，感知细粒度库表列权限、行过滤、列遮蔽等规则，并在执行计划中直接拦截或生效。
5. 全生命周期支持：细粒度的计算资源控制及统一的参数调优。按用户随时调整作业资源上限。支持提取列级的血缘关系深入引擎中执行计划向数据综合治理对齐。数据生命周期上覆盖取数方案场景的必要组件，并统一控制关键流程，如写入小文件优化、读取数量限定等。
以 Apache Kyuubi 为统一的 SQL 服务网关层，我们终于可以全面拥抱一系列长久以来看到的 Spark3 上关键特性演进，以标准化的方式向用户默认开启并优化调参，赋能所有对接的数据场景，以此收拢核心能力对齐大数据赋能层的各向要求。其中包括：
Adapative Query Execution 动态查询执行： 从 Spark2.4 以来 AQE 是最受关注的特性之一，也是 Spark3 最受瞩目的关键特性。通过上 Spark3.3 我们得益默认开启（Spark3.2+）这项重要能力。 数据倾斜和不均衡的情况是数据的常态，而 AQE 显著提升此情况下的运行表现，在执行时动态决定分区数量重新综合处理能力和数据分布状况 令数据查询和数据加工真正可以做到聚焦业务逻辑，而减少传统上任务粒度调优的额时间成本 WholeStage CodeGen 全阶段运行时代码生成： 通过 CodeGen 方式运行时深入执行细节和执行现场统计信息生成最具效率的运行代码，令同一份数据资产、同一份查询加工逻辑，持续得益于引擎优化提升运行效能缩短执行时间。 Dynamic Resource Allocation 动态资源分配： 运行阶段在可控数量范围下动态申请和销毁 executor 实例，令分布式运行资源得到最大化的运用。全面兼顾了 Adhoc 场景对常驻服务结合弹性伸缩资源的迫切诉求，也兼顾了数据加工下运行时资源的动态释放。显著提升了总体的可用度和资源可控程度。 DRA with Shuffle Tracking 不依赖 ESS 的动态资源分配： 使用 ShuffleTracking 避免使用 ESS（External Shuffle Service）。而长久以来 DRA 要求以 ESS 来满足 executor 重分布的需求，这要求每个分布式集群中每个执行节点上必须安装独立的 ESS 服务和暴露端口进行通讯，这极大增加了运维成本和限制版本演进的可能。 统一使用 ShuffleTracking 不需要独立部署服务，并且动态依赖作业和引擎的版本，使用足迹和运维成本明显减少。此为 Spark3.2+ 提供的实验性特性。
使用 Kyuubi 作为大数据赋能层的另一个重要原因是，其在同一外观即通过 server 暴露服务的前提下，仍然保留了多样化的前端协议与后端服务的灵活组合，使其在不同对接需求可以选用合适的前端协议，同时保留了增加其他不同类型不同原理的引擎成为可能。
当前 Apache Kyuubi 已经成功实现了这一架构思路，具体而言：
前端协议支持包括，HiveThrift 协议、REST HTTP 接口协议、Mysql 协议（实验性）、FlightSQL（原型论证中），而后端服务已经深入支持 Spark3.0+（各组件兼容覆盖 3.0~3.3 的所有主线版本）、Flink、Trino、Doris（从 1.6 起）等，并开始深入提供 Spark 等引擎下对接其他底层湖仓的连接器，如 Spark DSV2 Hive connector 等。
Kyuubi 大数据赋能层的落地策略与场景构建
因此，我们采取了四个层面来推进 Apache Kyuubi 落地，遵循从易到难，从读到写，从封闭到开放的原则，在每个关键阶段设置明确的目标和验证点。
1. 平替孵化：即席查询，只读查询。优先在可控应用层区域下，引入 Kyuubi 作为查询引擎，将 SparkSQL 作为只读查询引擎赋能与数据探索场景。并且重点验证多租户场景在 SERVER 全局共享模式可行性与 Spark 动态资源伸缩 DRA 的有效性。
2. 试点构建：试水用于只读型的数据跑批作业，验证系统对接特性，例如试点用于数据质量跑批。检验对存量 HiveSQL 语法数据加工作业对接 Kyuubi 按 SparkSQL 兼容解析执行的能力。
3. 成熟落地：进一步推广到用于写入数据的大规模数据加工作业。全面启用所有预期的底座架构组合，包括 Kyuubi、Spark3.3、Iceberg 等全体系基准能力，并验证USER、CONNECTION 级别在数据加工场景下的细粒度资源隔离与配置控制。
在架构调研和落地过程中，我们意识到，大数据赋能层各方面的统一要求及 Apache Kyuubi 的单一选型并不意味着必须以同一套服务同一个端口对外，而是应该灵活按场景需要组合来达到资源与隔离之间的平衡。充分发挥各共享模式下，用于减少启停时间，综合 engine 上 Kyuubi UI 定位问题，充分满足资源隔离配置隔离等的需要。其中 Apache Kyuubi 中不同的共享模式我们要按实际需要划分和使用，例如：
即席查询、BI 工具等场景，考虑使用 SERVER 模式，避免重复提交 engine 作业所需要的传包、启停、资源分配等往返操作，同时在此模式下保持对终端用户的身份认证与数据鉴权能力。 数据加工、ETL、采数推数场景：考虑按用户和会话划分所用 engine 实例，分别使用 USER 模式和 CONNECTION 模式。
在数据加工作业场景下，大数据赋能层通过 Kyuubi 首先转变了数据加工开发对接能力的思路和方式。数据开发人效可预期提升超过 100%，开发一种新类型的数据作业从数周的周期压缩到数天内完成，最快可以在 1 天内完成准备，一周内完整全链路开发与验证。
在数据探索 Adhoc query 及自助查询场景下，再作为非首选引擎引擎的前提下，约 20% 的 HiveSQL 查询主动向 Kyuubi （SparkSQL） 进行使用。
具体效益而言，在零额外使用成本的前提下下，多层次的经验与资产得以平滑演进和增效，包括：复用已有产品化的 HiveSQL 场景查询，复用 Hive UDF，复用数据开发在 HiveSQL 上的能力与经验，复用原有 Hive 数仓资产与能力等。并且数据探索与数据开发都得以继续使用 HiveSQL 同一套语法完成，大大避免了 Tinro/Hive-Hive 往返人工转换语法的耗时。
对于常见的外部作业数据加工和取数的场景，我们继续围绕 Kyuubi 作为统一的数仓读写入口，这里以 PySpark/Spark 作为链接客户端为例。
接入方式 PySpark，补充实现了 Spark Hive Dialect 插件解决 SparkSQL 列名方言与 HiveSQL 风格不一致的问题，解决 JDBC RDD 转换问题。 数据准备和数据加工的 SQL 通过 JDBC 提交给 Kyuubi 在数仓内统一进行加工。 数据提取走 JDBC 提取需要解决性能与中间结果堆积的问题，SparkRDD 将操作尽可能下推到 Kyuubi 在 Spark 上执行，运行结果集通过 Resultset 微批方式顺序获取，而为了避免 Kyuubi 下 Spark 在 Driver 上堆积全部数据结果，开启 incremental_collection 开关分散压力，逐批获取结果中的分区数据。 所有数据连接均在用户认证加数据权限校验下进行，数据权限从 Ranger 服务感知鉴权规则，与数据综合治理和数据管控对齐。 作为使用方 PySpark/Spark 保持分布式执行能力，可以使用自建 standalone 的 spark 集群也可以在可控前提下与 YARN 混布。
总体而言，我们通过 Apache Kyuubi 构建大数据赋能层，在开发效率、运行效率、管控程度都有了显著的提升：
作为金融行业成员，无论是监管要求还是业务隔离需要，数据权限管控都是数据赋能和数据开放的先决条件。因此数据中台战略要求实施一体化权限管控：
1. 以数据权限作为切面，同一份策略必须能够对接大数据赋能层中各种引擎，如 Spark、Trino 等。
2. 能够对数据进行不同维度不同粒度的授权，库表列级别权限管控到位。
3. 能够有效响应精细化数据管控需求，其中包括表内数据行过滤、列遮蔽等。
4. 能够充分对接数据治理的沉淀结果，包括分类分级定义、数据标准等进行数据管控。
1. 依托统一的大数据权限服务统一管控不同场景的权限规则，例如Ranger服务。
2. 管控与审计在一体化权控服务集中进行。
3. 保持低成本的接入前提下，有效对用户进行按不同场景和不同方式的身份认证。
4. 数据赋能层中的各项引擎使用针对性对接插件，能够对接数据权限规则，在数据鉴权、数据执行计划中的应用规则和拦截越权操作。
5. 数据赋能层需要有能力满足列级血缘提取、元数据感知等，为数据综合治理提供数仓元数据变化感知信息。
在当前大数据体系生态中，Apache Ranger 可能是唯一持续迭代的大数据权限控制服务，尤其是在 Apache Sentry 项目 2018 后停止维护的背景下。而 Apache Ranger 项目中提供对接各种引擎并不包含对Spark引擎的支持和对应的规则定义体系。
Apache Kyuubi Authz 插件是 Spark 生态下对接 Apache Ranger 权控策略的唯一选择。其规则定义遵循了 Ranger 中 Hive 规则风格，完整支持 Ranger 各项关键特性，覆盖库表列权限、行过滤、列遮蔽等管控规则。
● 其他有关临时/永久视图、临时/永久函数的鉴权处理
一体化数据权控的关键始终在于，“统一数仓、统一权控”。前者要求统一底座和数仓元数据，而后者要求数据权限规则可以落地到不同的赋能层数据引擎中，并抚平差异。
同一份数据权限控制策略，在所有引擎生效，我们通过综合手段在不同引擎去满足。首先 HiveServer2 继续作为可用数据引擎，使用 Ranger 提供的 Hive 插件，通过 HiveAuthorizer 进行权限干预。其次，对 Kyuubi 在 Spark 引擎使用 Kyuubi Authz 插件对接。继而，保留 Trino 引擎继续支持存量 Trino 语法的查询，在使用 Ranger 提供的 Trino 插件基础上，进行二次开发，对特定 catalog 改用与 Hive、Spark 中使用的同一份权限策略控制。对于统一数仓中的流式存储部分，我们对 Ranger 的 Kafka 进行了一定适配以满足 SASL/SCRAM 连接和认证的要求。
至此，一体化权控体系在对接。
如前所述，Ranger 服务本身并没有提供 Spark 插件对接数据权限。此前 Kent Yao 在 Apache Submarine 中提供了 Spark 对接 Ranger 安全插件，在其开源 Apache Kyuubi 后重构并放到此项项目中。
1. 通过 Spark 的 SQL 插件机制启用 Authz 插件，并注入各类权控优化器，包括 RuleAuthorization 等
2. 对 SparkSQL 命令及其执行计划进行特征映射与资源提取，在 PrivilegeBuilder 内完成对 V1、V2 等命令的解析与权限请求构建
3. Authz 插件内部集成了 Ranger 客户端的核心组件 RangerBasePlugin，得益于此，可以从 Ranger Admin 后台 REST 接口定时拉取权控规则策略及用户信息的拉取等，并加载到内存中备用，同时缓存本地保证服务持续性
就具体而言，一个 Ranger 数据规则是通过三大核心要素完成对 RBAC 基于用户和角色的权限控制的。一条 Ranger 权控规则是面向资源按用户/角色赋予特定权限的。
1. 资源：通过规范维度，在库、表、列三个维度定义资源，支持模糊匹配，在此框架下，纳管包括数据库、数据表、数据列、UDF 等
2. 用户及角色：定义用户、角色、用户组，并绑定相互关系，进而可选定范围按不同粒度进行授权。其中用户与角色、用户组及用户角色、用户角色与用户角色之间可以是一对多的关系。用户组与用户角色的区别在于用户组可有自己的属性，且用户组不可以绑定到自身。
Ranger 对以上三类规则，进行了进一步的抽象，进一步赋予了有效期、是否启用、描述等通用能力。Access 规则授予对应资源的各项操作权限，例如库表权限的 SELECT/UPDATE 等。Row-level filtering 规则定义数据行过滤规则，可以按不同授权对象指定不同过滤规则，并可以使用 UDF 等。而 DataMasking 对指定列进行数据遮蔽。
在大数据赋能层中，我们要求能够满足以不同的“认证-鉴权”组合来应对不同场景。
首先是应对不同的用户，例如终端用户采用账号 +token，通过 JDBC 或 LDAP 完成用户认证；而同时对跑批用户采用账号密码等，通过 JDBC 方式认证。
其次是在不同场景使用区别的权控策略，在自助查询面向终端用户的场景使用最细粒度的规则来管控用户行为，而在跑批场景下对跑数用户按数据加工需要以颗粒度授权，降低规则数量的压力，减少运行时占用的内存和鉴权耗时。
Apache Ranger 2.3 中一项关键的新特性，行过滤条件新增支持宏对用户属性进行动态匹配，尤为具有价值。此项特性能大幅降低行过滤规则数量，对用户属性等进行高效复用，并保留对不同粒度用户范围的授权能力。
在 Row-level filtering 中，以往的版本只能针对每个授权指定单独的完整过滤规则，例如，按用户指定多个不同指标 ID 对数据表进行过滤，需要逐一写入，如 index_id in ("1","7","9"......) 等。而此时每个人或每个角色稍有条件细节上的差异，就必须重复定义多个不同的行过滤规则而无法复用。
而有了 RANGER-3605 及 RANGER-3550 的支持后，可以运用此特性，将行过滤条件定性为 index_id in ${{USER.allowIndexIds}}，即可解耦行过滤规则与授权，并将具体属性值放在用户属性下进行复用。
Apache Ranger 2.3 中与上述能力紧密关联的是，新引入了 UserStore 接口和特性，覆盖包括用户属性拉取、用户-用户组关系等。与此相关的收益是，可以对用户组进行授权，大幅降低权限规则数量，同时因用户组可以有自带属性定义能力，结合行过滤宏能力相得益彰。
我们将相关能力的开关以提交到 Kyuubi 文档中方便参考。
05
展望与后续工作
Apache Kyuubi 作为快速完成孵化的顶级大数据生态开源项目，精准定位大数据生态位和架构融合性，具有良好和持续的技术演进和业务价值。
Apache Kyuubi 持续在各领域深入发展，目前已顺利落地数十家互联网及 IT 厂商、券商行业，包括广发证券及华泰证券等。在参与 Apache Kyuubi 的贡献当中，我们广发证券立足于自身场景与数据战略愿景，提交我们所推动和参与的贡献与修正，积极与社区交流合作，期间得到了 committer 和 contributor 以及使用者的大量的帮助、指导与支持。
分享嘉宾
INTRODUCTION
梁博文
广发证券 信息技术部
大数据平台架构师
曼彻斯特大学硕士，曾在阿里巴巴移动事业群参与亿级服务开发，在金融和游戏行业持续参与大数据研发，在广发证券设计构建构建新一代大数据平台和实时流式作业平台，参与Apache Kyuubi代码贡献。
往期推荐
点个在看你最好看