Skip to main content

20 docs tagged with "bigdata"

View All Tags

hive metastore 元数据仓库 ranger 管控

之前讨论spark的ranger权限管控问题的时候, 就提到hive server2 ranger插件只对经过hive server2的请求生效, 如果spark等应用直接读取hive metatore, ranger hive插件那就无法管控到了. 业内有一些解法, 可以从组件自身的解析流程入手, 比如解析spark logical plan转化为对应的元数据操作权限请求, 也可以从hive metastore入手限制权限, 不过一直看到的讨论都是hive metastore的权限管控还不成熟. 这次看ranger官方文档, 发现在hive4版本之后, metastore算是正式支持鉴权了. 这时候有另一个问题, hive server2插件还有存在的必要吗?

hive 架构

ranger/airflow这类业务辅助型组件的源码还是比较容易看完的, 目标也明确, hive/spark这种正经大数据组件就不是一回事了. 开源社区多少人耕耘了多少年写出来的东西, 代码量和复杂度就不是一个层级的. 日常crud的业务代码, 在这种大规模组件的代码面前, 真是玩具. 多少做大数据治理的, 困于日常搬砖, 就没看过这些组件的源码, 只能滥竽充数的搬砖. 但是打工人也得衡量下, 是否真的有那么多奢侈的时间去把这些看完?

hive-hdfs-大数据领域鉴权问题

看了一圈各种大数据组件的鉴权方案, 就能意识到一个问题,大数据鉴权这个领域目前是没完没了, 没有完美方案能够覆盖各种大数据组件组合的场景. 主要的根源是大数据新组件的研发初衷, 一般都是为了提供更快的计算速度, 更多的分析功能, 就没听说为了提供更高安全性的. 设计前期基本上是不会考虑鉴权问题的, 如果提前考虑了用户的授权鉴权问题, 引入额外的业务逻辑代码, 反而会拖累整个组件的运算速度. 所以一般得等到新组件已经打出一片天地了, 有一堆公司在使用了, 才会来修修补补的考虑鉴权问题. 比如一开始的hdfs/hive就没有认证和鉴权, 后来认证通过kerberos补上了, 鉴权慢慢也由ranger/sentry/acl等补上了, 但是目前两者的搭配还是容易出现各种问题.

kerberos 概念与常用命令

如果只是使用被分配的keytab, 只会用到klist -kt 和kinit -kt命令的话, 对用户和密钥的管理没有接触, 对kerberos这套系统的认知还是迷迷糊糊. 就跟熟悉一个组件需要从安装开始, 熟悉kerberos也需要从kadmin.local开始, 用kadmin.local创建用户, 修改密码, 创建keytab, 查看用户列表, 执行完这些初始的管理操作, 基本上就知道怎么回事了, kerberos kdc 的迷雾也开始散开.

kyuubi 数据治理

spark 自身的thrift server据说不支持用户资源隔离(个人没有测试研究), 国内网易开源的 apache kyuubi 提供了租户隔离和资源隔离的解决方法. 看了下源码仓库, 还支持了ranger鉴权, spark血缘解析, 一套数据治理方案直接打包了. 如果kyuubi确实稳定可用, 可以省去很多使用spark的数据治理的麻烦.

presto/trino 入坑记

trino真是神奇, 实现了多个数据源实例之间直接读取关联查询, 这样不少场景就不需要etl什么事了, 再次体会到了所谓数据湖的概念.

ranger policy cache

ranger cache 缓存就是保存在大数据组件ranger plugin的服务器上, plugin鉴权不用再去访问ranger admin, 难怪速度可以满足要求.

ranger 数据库

看起来策略都保存在x_policy表中,所有信息都通过json序列化为text。

从堆栈学习源码

虽然还是有些囫囵吞枣, 但是从堆栈角度来学习真的是事半功倍, 直接看源码压根串不起来, 选择路径实在太多了.