当我用'stored as avro'子句创建配置单元表时，avro模式存储在哪里？

5ssjco0h  于 2021-06-26  发布在  Hive
关注(0)|答案(2)|浏览(478)

至少有两种不同的方法可以创建以avro数据为备份的配置单元表：
1） 基于avro模式创建表（在本例中存储在hdfs中）：

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

2） 通过使用显式指定配置单元列来创建表 STORED AS AVRO 条款：

  1. CREATE TABLE users_stored_as_avro(
  2.   id INT,
  3.   name STRING
  4. ) STORED AS AVRO;

在元数据的第一种情况下，我说的对吗 users_from_avro_schema 表不是存储在配置单元元存储中，而是从读取avro模式文件的serde类推断出来的？或者表元数据存储在metastore中，在创建表时添加，但是同步配置单元元数据和avro模式的策略是什么？我指的是两种情况：更新表元数据（添加/删除列）和通过更改 avro.schema.url 财产。
第二种情况是我打电话的时候 DESCRIBE FORMATTED users_stored_as_avro 根本没有 avro.schema.* 属性定义，所以我不知道哪个avro模式用于读/写数据，它是基于存储在metastore中的表元数据动态生成的吗？
编程hive手册的这个片段说的是从serde类推断关于列的信息，但另一方面hive-4703删除了这个 from deserializer 信息表单列注解。如何检查给定表的列类型源（metastore或avro模式）？

Hiveavroschemametastore

2条答案

按热度按时间
zvokhttg

zvokhttg1#

以下是不涉及模式文件的用例
架构存储在两个位置
1.元商店
2.作为数据文件的一部分
desc/show命令的所有信息都来自metastore。
每个ddl更改只影响元存储。
当您查询数据时，两个模式之间的匹配由列名称完成。
如果列类型不匹配，则会出现错误。

演示

  1. create table mytable 
  2. stored as avro 
  3. as 
  4. select  1               as myint
  5.        ,'Hello'         as mystring
  6.        ,current_date    as mydate
  7. ;
  1. select * from mytable
  2. ;
  1. +-------+----------+------------+
  2. | myint | mystring |   mydate   |
  3. +-------+----------+------------+
  4. |     1 | Hello    | 2017-05-30 |
  5. +-------+----------+------------+

元存储

  1. select      c.column_name
  2.            ,c.integer_idx
  3.            ,c.type_name
  5. from                metastore.DBS        as d
  6.             join    metastore.TBLS       as t on t.db_id = d.db_id
  7.             join    metastore.SDS        as s on s.sd_id = t.sd_id
  8.             join    metastore.COLUMNS_V2 as c on c.cd_id = s.cd_id
  10. where       d.name     = 'local_db'
  11.         and t.tbl_name = 'mytable'
  13. order by    integer_idx
  1. +-------------+-------------+-----------+
  2. | column_name | integer_idx | type_name |
  3. +-------------+-------------+-----------+
  4. | myint       |           0 | int       |
  5. | mystring    |           1 | string    |
  6. | mydate      |           2 | date      |
  7. +-------------+-------------+-----------+

avro工具

  1. bash-4.1$ avro-tools getschema 000000_0 
  3. {
  4.   "type" : "record",
  5.   "name" : "mytable",
  6.   "namespace" : "local_db",
  7.   "fields" : [ {
  8.     "name" : "myint",
  9.     "type" : [ "null", "int" ],
  10.     "default" : null
  11.   }, {
  12.     "name" : "mystring",
  13.     "type" : [ "null", "string" ],
  14.     "default" : null
  15.   }, {
  16.     "name" : "mydate",
  17.     "type" : [ "null", {
  18.       "type" : "int",
  19.       "logicalType" : "date"
  20.     } ],
  21.     "default" : null
  22.   } ]
  23. }
  1. alter table mytable change myint dummy1 int;
  1. select * from mytable;
  1. +--------+----------+------------+
  2. | dummy1 | mystring |   mydate   |
  3. +--------+----------+------------+
  4. | (null) | Hello    | 2017-05-30 |
  5. +--------+----------+------------+
  1. alter table mytable add columns (myint int);
  1. select * from mytable;
  1. +--------+----------+------------+-------+
  2. | dummy1 | mystring |   mydate   | myint |
  3. +--------+----------+------------+-------+
  4. | (null) | Hello    | 2017-05-30 |     1 |
  5. +--------+----------+------------+-------+

元存储

  1. +-------------+-------------+-----------+
  2. | column_name | integer_idx | type_name |
  3. +-------------+-------------+-----------+
  4. | dummy1      |           0 | int       |
  5. | mystring    |           1 | string    |
  6. | mydate      |           2 | date      |
  7. | myint       |           3 | int       |
  8. +-------------+-------------+-----------+

avro工具
（与原方案相同）

  1. bash-4.1$ avro-tools getschema 000000_0 
  3. {
  4.   "type" : "record",
  5.   "name" : "mytable",
  6.   "namespace" : "local_db",
  7.   "fields" : [ {
  8.     "name" : "myint",
  9.     "type" : [ "null", "int" ],
  10.     "default" : null
  11.   }, {
  12.     "name" : "mystring",
  13.     "type" : [ "null", "string" ],
  14.     "default" : null
  15.   }, {
  16.     "name" : "mydate",
  17.     "type" : [ "null", {
  18.       "type" : "int",
  19.       "logicalType" : "date"
  20.     } ],
  21.     "default" : null
  22.   } ]
  23. }

对该表所做的任何工作都是基于存储在metastore中的元数据来完成的。
当查询表时，会使用其他元数据，即存储在数据文件中的元数据。
查询结果结构是从metastore构造的（在我的示例中，在表被修改后返回4列）。
返回的数据取决于这两种模式—文件模式中具有特定名称的字段将Map到元存储模式中具有相同名称的列。
如果名称匹配但数据类型不匹配，则会出现错误。
如果数据文件中的字段在元存储中没有相应的列名，则不会显示该字段。
metastore中的列如果在数据文件架构中没有相应的字段，则该列将包含空值。

展开查看全部
赞(0）分享  回复(0）举报  2021-06-26
biswetbf

biswetbf2#

我决定发表一个对@dudumarkovitz给出的答案的补充。
为了使代码示例更简洁，让我们澄清一下 STORED AS AVRO 子句相当于这三行：

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

让我们看看当我们创建一个表来引用存储在hdfs中的avro模式时会发生什么。以下是模式：

  1. {
  2.   "namespace": "io.sqooba",
  3.   "name": "user",
  4.   "type": "record",
  5.   "fields": [
  6.     {"name": "id", "type": "int"},
  7.     {"name": "name", "type": "string"}
  8.   ]
  9. }

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

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

hive正确地推断了模式，我们可以通过调用：

  1. hive> DESCRIBE users_from_avro_schema;
  2. OK
  3. id                      int
  4. name                    string

hive metastore向我们展示了相同的情况（我使用@dudumarkovitz的查询）：

  1. +------------------------+-------------+-------------+-----------+
  2. | tbl_name               | column_name | integer_idx | type_name |
  3. +------------------------+-------------+-------------+-----------+
  4. | users_from_avro_schema | id          |           0 | int       |
  5. | users_from_avro_schema | name        |           1 | string    |
  6. +------------------------+-------------+-------------+-----------+

到目前为止，一切正常，一切都如我们所料。但让我们看看更新后会发生什么 avro.schema.url 属性指向架构的下一个版本（users\ v2.avsc），如下所示：

  1. {
  2.   "namespace": "io.sqooba",
  3.   "name": "user",
  4.   "type": "record",
  5.   "fields": [
  6.     {"name": "id", "type": "int"},
  7.     {"name": "name", "type": "string"},
  8.     {"name": "email", "type": ["null", "string"], "default":null}
  9.   ]
  10. }

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

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

表元数据是否已更改？

  1. hive> DESCRIBE users_from_avro_schema;
  2. OK
  3. id                      int
  4. name                    string
  5. email                   string

是啊，酷！但是您是否希望配置单元元存储包含此附加列？
不幸的是，在metastore中没有任何更改：

  1. +------------------------+-------------+-------------+-----------+
  2. | tbl_name               | column_name | integer_idx | type_name |
  3. +------------------------+-------------+-------------+-----------+
  4. | users_from_avro_schema | id          |           0 | int       |
  5. | users_from_avro_schema | name        |           1 | string    |
  6. +------------------------+-------------+-------------+-----------+

我怀疑hive有以下推断模式的策略：它试图从为给定表指定的serde类中获取模式。当serde无法提供模式时，配置单元会查看元存储。
让我们通过移除 avro.schema.url 属性：

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

descripe向我们显示存储在metastore中的数据。让我们通过添加列来修改它们：

  1. ALTER TABLE users_from_avro_schema ADD COLUMNS (phone string);

它当然会改变配置单元元存储：

  1. +------------------------+-------------+-------------+-----------+
  2. | tbl_name               | column_name | integer_idx | type_name |
  3. +------------------------+-------------+-------------+-----------+
  4. | users_from_avro_schema | id          |           0 | int       |
  5. | users_from_avro_schema | name        |           1 | string    |
  6. | users_from_avro_schema | phone       |           2 | string    |
  7. +------------------------+-------------+-------------+-----------+

但是当我们出发的时候 avro.schema.url 再次回到 user_v2.avsc hive元存储中的内容不再重要：

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

avro模式优先于元存储。
上面的示例表明，我们应该避免将配置单元模式更改与avro模式演化混合在一起，因为否则我们很容易陷入配置单元元存储与读写数据时使用的实际模式之间的混乱和不一致。第一个不一致发生在我们通过更新来更改avro模式定义时 avro.schema.url 属性，但如果我们知道推断模式的配置单元策略，我们就可以接受它。我还没有在hive的源代码中检查我对模式逻辑的怀疑是否正确，但是上面的例子让我确信下面发生了什么。
我扩展了我的回答，以表明即使avro模式和符合avro模式的配置单元元存储数据之间存在冲突，也可以读取它们。请再看一下我上面的例子。我们的表定义指向具有三个字段的avro模式：

  1. id    int
  2. name  string
  3. email string

而在配置单元元存储中有以下列：

  1. id    int
  2. name  string
  3. phone string

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

  1. {
  2.   "id": 123,
  3.   "name": "Tomek",
  4.   "email": {"string": "tomek@tomek"}
  5. }

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

  1. 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 而不是列：

  1. hive> set hive.cli.print.header=true;
  2. hive> select * from users_from_avro_schema;
  3. OK
  4. users_from_avro_schema.id   users_from_avro_schema.name users_from_avro_schema.email
  5. 123 Tomek   tomek@tomek
展开查看全部
赞(0）分享  回复(0）举报  2021-06-26
我来回答

相关问题

    查看更多

    热门标签

    更多
    JavaquerypythonNode开发语言requestUtil数据库Table后端算法LoggerMessageElementParser

    最新问答

    更多
    • 蜀ICP备13028337号-1 大数据知识库 https://www.saoniuhuo.com © All rights reserved
    • 本站内容来源互联网,如果侵犯您的权益请联系我们删除, 联系方式：448109455@qq.com