Где хранится схема Avro, когда я создаю таблицу куста с предложением STORED AS AVRO?

Я решил опубликовать дополнительный ответ на ответы @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'

Давайте посмотрим, что происходит, когда мы создаем таблицу, содержащую ссылку на схему avro, хранящуюся в hdfs. Вот схема:

{
  "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):

+------------------------+-------------+-------------+-----------+
| 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.
Теперь мы обновляем свойство таблицы, указывающее на схему avro в hdfs:

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 просматривает хранилище метаданных.
Давайте проверим это, удалив свойство 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)

Describe показывает нам данные, хранящиеся в 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.

Приведенный выше пример показывает, что нам лучше избегать смешивания изменений схемы улья с эволюцией схемы avro, потому что в противном случае мы можем легко попасть в большой беспорядок и несогласованность между Hive Metastore и фактической схемой, которая используется при чтении и записи данных. Первое несоответствие возникает, когда мы изменяем определение схемы avro, обновляя свойство avro.schema.url, но мы можем смириться с этим, если знаем о стратегии Hive вывода схемы. Я не проверял в исходном коде Hive, верны ли мои подозрения относительно логики схемы, но приведенный выше пример убеждает меня в том, что происходит под ним.

Я расширил свой ответ, чтобы показать, что даже при конфликте между схемой Avro и данными Hive Metastore, которые соответствуют схеме Avro, можно прочитать. Пожалуйста, взгляните еще раз на мой пример выше. Наше определение таблицы указывает на схему avro с тремя полями:

id    int
name  string
email string

тогда как в Hive Metastore есть следующие столбцы:

id    int
name  string
phone string

электронная почта против телефона
Давайте создадим avro-файл, содержащий единственную запись пользователя, соответствующую схеме user_v2.avsc. Это его 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

Следующее относится к варианту использования, в котором не используется файл схемы

Схема хранится в 2 местах
1. Хранилище метаданных
2. Как часть файлов данных

Вся информация для команд DESC / SHOW берется из хранилища метаданных.
Каждое изменение DDL влияет только на хранилище метаданных.

Когда вы запрашиваете данные, соответствие между двумя схемами осуществляется по именам столбцов.
Если есть несоответствие в типах столбцов, вы получите сообщение об ошибке.

Демо

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 |
+-------+----------+------------+

Хранилище метаданных

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 |
+--------+----------+------------+-------+

Хранилище метаданных

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

avro-tools
(та же схема, что и исходная)

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
  } ]
}

Любая работа с этой таблицей выполняется на основе метаданных, хранящихся в хранилище метаданных.
При запросе таблицы используются дополнительные метаданные, которые являются метаданными, хранящимися в файле данных.
Структура результатов запроса создается из хранилища метаданных (в моем примере показано, что 4 столбца возвращаются после изменения таблицы).
Возвращаемые данные зависят от обоих схемы - поле с определенным именем в схеме файла будет сопоставлено столбцу с тем же именем в схеме Metastore.
Если имена совпадают, а типы данных - нет, возникнет ошибка.
A поля из файла данных, у которого нет соответствующего имени столбца в хранилище метаданных, не будут представлены.
Столбец в хранилище метаданных без соответствующего поля в схеме файла данных будет содержать значения NULL.