DBT踩坑第二弹

        总结下dbt-spark踩到的坑,连接方式采用的是thrift连接 + Kerberos认证。考虑到开源组件Kyuubi也是基于Hiveserver2,使用的thrift协议,所以采用Kyuubi执行SparkSQL。

        官方文档给出的Thrift方式连接示例真的是简单,但是真是用起来真是一言难尽:

DBT踩坑第二弹_第1张图片

      

dbt-spark 连接踩坑历程:

        首先就是dbt-spark,这个python包是不带Kerberos包的,得手动自己再下载下!

        schema没啥问题,直接填Hive数据库的名称就好了,比如 dafault。

        host就有问题了,普通的spark thrift server是不支持HA的,但是Kyuubi是支持HA的,但是dbt-spark不支持配置HA方式的Kyuubi ! 所以Kyuubi HA的方式在这里算是废了,这里的host直接填Kyuubi 主节点的地址。Kyuubi HA模式下,host 和 port 是注册在ZK上的,可以使用ZK的命令查出来。Kyuubi 一般不适用ssl,所以顺带 use_ssl 配置为false。

        然后就来到了当时折磨人的 Kerberos 认证配置环节,各种配置发现都不行,dbt给出来的错误信息也很少。翻看了下dbt-spark底层的源码,发现它底层是通过pyHive库去连接Hive的,所以此时强烈建议自己写一个PyHive进行Kerberos认证连接Hive的demo!一下子就能看出来报错Yarn队列没有配置!

        最终配置如下:

my_spark_profile:
target: dev
outputs:
dev:
type: spark
method: thrift
schema: default
host: you-kyuubi-host
port: 10009
auth: KERBEROS
kerberos_service_name: hive
use_ssl: false
server_side_parameters:
"mapreduce.job.queuename": "you-yarn-queue-fullname"
"spark.yarn.queue": "you-yarn-queue-fullname"
"hive.exec.dynamici.partition": "true"
"hive.exec.dynamic.partition.mode": "nonstrict"

        使用如下命令执行kinit -kt /home/***/you_kerberos.keytab you_kerberos.princal && dbt run 

dbt-spark 执行踩坑历程:

        如果你的Hive库下挂载了kudu或者HBase外部表,这个时候就会报错:

org.apache.hadoop.hive.ql.metadata.HiveException: Error in loading storage handler.org.apache.hadoop.hive.kudu.KuduStorageHandler

        因为dbt底层会执行sql:show table extends in you-database like '*',全库扫描获取所有表的元数据信息,kudu表的元数据据信息识别会报错。有两种解决思路:

        1. 往spark lib 下把spark-kudu jar加入,但是我们因为怕影响到其他人的作业,没有采用这种方法...

        2. 修改dbt-spark源码。害,虽然有点麻烦,最终还是通过这种方式解决的

        如下是dbt-spark源码,上面标红的地方是dbt默认获取表元数据信息的方式 show table extends 。下面标红的框是为iceber定制的获取元数据的方式,先通过show tables 获取所有的表信息,然后再通过describe table 获取表的information信息。

        so,有一个简单粗暴的方案就是把下面的代码提上来,但是性能并不会太好,hhh。还有一种方式是想办法把待执行的模型名称传入,把sql修改为 show table extends *** like 'you_table_name',这种方式的话性能能有个好几倍的提升!还是看个人的业务适合使用哪种方式把。

DBT踩坑第二弹_第2张图片

你可能感兴趣的:(DBT,数据库)