Question

创建支持Avro数据的配置单元至少有两种不同的方法：

1）基于Avro架构创建表（在此示例中存储在hdfs中）：

CREATE TABLE users_from_avro_schema
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe'
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'
TBLPROPERTIES ('avro.schema.url'='hdfs:///user/root/avro/schema/user.avsc');

2）通过使用STORED AS AVRO子句明确指定配置单元列来创建表：

CREATE TABLE users_stored_as_avro(
  id INT,
  name STRING
) STORED AS AVRO;

我是否正确在第一种情况下，users_from_avro_schema表的元数据未存储在Hive Metastore中，而是从SERDE类中读取avro架构文件？或者表格元数据可以存储在Metastore中，添加在表格的创建上，但是什么是将Hive元数据与Avro架构同步的策略？我的意思是两种情况：更新表元数据（添加/删除列）并通过更改avro.schema.url属性来更新Avro架构。

在我调用DESCRIBE FORMATTED users_stored_as_avro的第二种情况下，没有定义avro.schema.*属性，因此我不知道哪个Avro架构用于读/写数据，是否是基于动态生成的在表格中存储在Metastore中的元数据？

此fragment编程Hive书中有关于推断SerDe类中列的信息，但另一方面HIVE-4703删除了此from deserializer信息表单列注释。我如何检查给定表（Metastore或Avro架构）的列类型的来源是什么？

Answer 1

我决定发布@DuduMarkovitz给出的补充答案。

为了使代码示例更简洁，让我们澄清STORED AS AVRO子句相当于这三行：

ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe'
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'

让我们看一下当我们创建一个表，该表提供对存储在hdfs中的avro模式的引用时会发生什么。这是架构：

{
  "namespace": "io.sqooba",
  "name": "user",
  "type": "record",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"}
  ]
}

我们使用以下命令创建表：

CREATE TABLE users_from_avro_schema
STORED AS AVRO
TBLPROPERTIES ('avro.schema.url'='hdfs:///user/tulinski/user.avsc');

Hive已正确推断出架构，我们可以通过调用来看到：

hive> DESCRIBE users_from_avro_schema;
OK
id                      int
name                    string

Hive Metastore向我们展示了相同的内容（我使用@ DuduMarkovitz＆＃39; s查询）：

+------------------------+-------------+-------------+-----------+
| tbl_name               | column_name | integer_idx | type_name |
+------------------------+-------------+-------------+-----------+
| users_from_avro_schema | id          |           0 | int       |
| users_from_avro_schema | name        |           1 | string    |
+------------------------+-------------+-------------+-----------+

到目前为止，这么好，一切都按照我们的预期运作。但是，让我们看看当我们更新avro.schema.url属性以指向我们的架构的下一个版本（users_v2.avsc）时会发生什么，如下所示：

{
  "namespace": "io.sqooba",
  "name": "user",
  "type": "record",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"},
    {"name": "email", "type": ["null", "string"], "default":null}
  ]
}

我们只是添加了另一个名为email的字段现在我们更新一个指向hdfs中的avro模式的表属性：

ALTER TABLE users_from_avro_schema SET TBLPROPERTIES('avro.schema.url'='hdfs:///user/tulinski/user_v2.avsc');

表元数据是否已更改？

hive> DESCRIBE users_from_avro_schema;
OK
id                      int
name                    string
email                   string

是的，很酷！但是你认为Hive Metastore包含这个额外的列吗？ 不幸的是，在Metastore中没有任何改变：

+------------------------+-------------+-------------+-----------+
| tbl_name               | column_name | integer_idx | type_name |
+------------------------+-------------+-------------+-----------+
| users_from_avro_schema | id          |           0 | int       |
| users_from_avro_schema | name        |           1 | string    |
+------------------------+-------------+-------------+-----------+

我怀疑Hive有以下推断模式的策略：它试图从为给定表指定的SerDe类中获取它。当SerDe无法提供架构时，Hive会查看Metastore 让我们通过删除avro.schema.url属性来检查：

hive> ALTER TABLE users_from_avro_schema UNSET TBLPROPERTIES ('avro.schema.url');
OK
Time taken: 0.33 seconds
hive> DESCRIBE users_from_avro_schema;
OK
id                      int
name                    string
Time taken: 0.363 seconds, Fetched: 2 row(s)

描述向我们展示存储在Metastore中的数据。让我们通过添加一列来修改它们：

ALTER TABLE users_from_avro_schema ADD COLUMNS (phone string);

它当然会改变Hive Metastore：

+------------------------+-------------+-------------+-----------+
| tbl_name               | column_name | integer_idx | type_name |
+------------------------+-------------+-------------+-----------+
| users_from_avro_schema | id          |           0 | int       |
| users_from_avro_schema | name        |           1 | string    |
| users_from_avro_schema | phone       |           2 | string    |
+------------------------+-------------+-------------+-----------+

但是当我们再次将avro.schema.url设置回user_v2.avsc时，Hive Metastore中的内容就不再重要了：

hive> ALTER TABLE users_from_avro_schema SET TBLPROPERTIES('avro.schema.url'='hdfs:///user/tulinski/user_v2.avsc');
OK
Time taken: 0.268 seconds
hive> DESCRIBE users_from_avro_schema;
OK
id                      int
name                    string
email                   string

Avro架构优先于Metastore。

上面的例子表明我们应该避免将hive架构更改与avro架构演变混合在一起，因为否则我们很容易陷入Hive Metastore与读取和写入数据时使用的实际架构之间的混乱和不一致。当我们通过更新avro.schema.url属性来更改我们的avro架构定义时，会出现第一个不一致，但如果我们知道推断架构的Hive策略，我们就可以使用它。我没有检查Hive的源代码是否我对模式逻辑的怀疑是正确的，但上面的例子让我相信下面会发生什么。

我扩展了我的答案，表明即使Avro架构和Hive Metastore之间存在冲突，也可以读取符合Avro架构的数据。请再看看我上面的例子。我们的表定义指向具有三个字段的avro模式：

id    int
name  string
email string

而在Hive Metastore中有以下列：

id    int
name  string
phone string

电子邮件与电话
让我们创建一个包含符合user_v2.avsc架构的单个用户记录的avro文件。这是它的json表示：

{
  "id": 123,
  "name": "Tomek",
  "email": {"string": "tomek@tomek"}
}

要创建avro文件，我们称之为：

java -jar avro-tools-1.8.2.jar fromjson --schema-file user_v2.avsc user_tomek_v2.json > user_tomek_v2.avro

我们能够查询我们的表格，尽管Hive Metastore不包含email列，而是包含phone列：

hive> set hive.cli.print.header=true;
hive> select * from users_from_avro_schema;
OK
users_from_avro_schema.id   users_from_avro_schema.name users_from_avro_schema.email
123 Tomek   tomek@tomek

Answer 2

以下是指未涉及架构文件的用例

架构存储在2个位置
1. Metastore
2.作为数据文件的一部分

DESC / SHOW命令的所有信息都来自Metastore 每个DDL变化仅影响Metastore。

当您查询数据时，2个模式之间的匹配由列名完成如果列类型不匹配，您将收到错误消息。

演示

create table mytable 
stored as avro 
as 
select  1               as myint
       ,'Hello'         as mystring
       ,current_date    as mydate
;

select * from mytable
;

+-------+----------+------------+
| myint | mystring |   mydate   |
+-------+----------+------------+
|     1 | Hello    | 2017-05-30 |
+-------+----------+------------+

<强> Metastore

select      c.column_name
           ,c.integer_idx
           ,c.type_name

from                metastore.DBS        as d
            join    metastore.TBLS       as t on t.db_id = d.db_id
            join    metastore.SDS        as s on s.sd_id = t.sd_id
            join    metastore.COLUMNS_V2 as c on c.cd_id = s.cd_id

where       d.name     = 'local_db'
        and t.tbl_name = 'mytable'

order by    integer_idx

+-------------+-------------+-----------+
| column_name | integer_idx | type_name |
+-------------+-------------+-----------+
| myint       |           0 | int       |
| mystring    |           1 | string    |
| mydate      |           2 | date      |
+-------------+-------------+-----------+

<强>阿夫罗-工具

bash-4.1$ avro-tools getschema 000000_0 

{
  "type" : "record",
  "name" : "mytable",
  "namespace" : "local_db",
  "fields" : [ {
    "name" : "myint",
    "type" : [ "null", "int" ],
    "default" : null
  }, {
    "name" : "mystring",
    "type" : [ "null", "string" ],
    "default" : null
  }, {
    "name" : "mydate",
    "type" : [ "null", {
      "type" : "int",
      "logicalType" : "date"
    } ],
    "default" : null
  } ]
}

alter table mytable change myint dummy1 int;

select * from mytable;

+--------+----------+------------+
| dummy1 | mystring |   mydate   |
+--------+----------+------------+
| (null) | Hello    | 2017-05-30 |
+--------+----------+------------+

alter table mytable add columns (myint int);

select * from mytable;

+--------+----------+------------+-------+
| dummy1 | mystring |   mydate   | myint |
+--------+----------+------------+-------+
| (null) | Hello    | 2017-05-30 |     1 |
+--------+----------+------------+-------+

<强> Metastore

+-------------+-------------+-----------+
| column_name | integer_idx | type_name |
+-------------+-------------+-----------+
| dummy1      |           0 | int       |
| mystring    |           1 | string    |
| mydate      |           2 | date      |
| myint       |           3 | int       |
+-------------+-------------+-----------+

<强>阿夫罗-工具
（与原始模式相同的模式）

bash-4.1$ avro-tools getschema 000000_0 

{
  "type" : "record",
  "name" : "mytable",
  "namespace" : "local_db",
  "fields" : [ {
    "name" : "myint",
    "type" : [ "null", "int" ],
    "default" : null
  }, {
    "name" : "mystring",
    "type" : [ "null", "string" ],
    "default" : null
  }, {
    "name" : "mydate",
    "type" : [ "null", {
      "type" : "int",
      "logicalType" : "date"
    } ],
    "default" : null
  } ]
}

针对该表的任何工作都是基于Metastore中存储的元数据完成的在查询表时，正在使用其他元数据，这是存储在数据文件中的元数据。
查询结果结构是从Metastore构建的（参见我的示例，在更改表后返回 4 列）。
返回的数据取决于两个方案 - 文件架构中具有特定名称的字段将映射到Metastore架构中具有相同名称的列。
如果名称匹配但数据类型不匹配，则会出现错误不会显示数据文件中Metastore中没有相应列名的字段 Metastore中没有数据文件架构中的相应字段的列将保留NULL值。

当我使用＆STANED AS AVRO＆＃39;创建一个配置单元表时，存储Avro架构的位置。条款？

2 个答案:

演示