API каталога клея AWS: поле параметров в метаданных различных структур - PullRequest
Новая
       112

API каталога клея AWS: поле параметров в метаданных различных структур

0 голосов
/ 26 сентября 2019

Каталог данных клея AWS состоит из различных структур, например, База данных , Таблица , Раздел , Столбец и т. Д.просмотрел каждое из них, но кажется, что Parameters поля (массив карт пар ключ-значение) присутствуют во всех них.Я заметил, что если таблица была создана сканером 1011 *, то мы можем увидеть что-то вроде: 

{
    "CrawlerSchemaDeserializerVersion": "1.0",
    "CrawlerSchemaSerializerVersion": "1.0",
    "UPDATED_BY_CRAWLER": "some-crawler-name",
    "averageRecordSize": "12",
    "classification": "parquet",
    "compressionType": "none",
    "objectCount": "123",
    "recordCount": "1234567",
    "sizeKey": "1234567890",
    "typeOfData": "file"
}

для Table["Parameters"], а также Table["StorageDescriptor"]["Parameters"].Если в нашей таблице есть разделы, то каждый из них будет иметь один и тот же словарь, но с разными значениями для averageRecordSize , objectCount , recordCount , sizeKey.После их суммирования мы получим те же значения, что и в Table["Parameters"].Все это имеет смысл, и я думаю, что эти значения определяют логику сканеров, когда мы хотим перезапустить его по требованию или по расписанию.

Вместо использования сканеров, я вручную управляю несколькими каталогами клея AWS с boto3 и airflow .Например, я мог бы скопировать определение разделов из db_1.table_1 в каталоге 12345 в db_2.table_2 в каталоге 6789 или определить дополнительные мета-параметры в table_1.Однако это поле Parameters все еще остается для меня загадкой, и я не могу найти какую-либо документацию, связанную с ним.

Похоже, некоторые ключи, например recordCount, являютсязарезервировано для внутреннего использования в AWS Glue (хотя их можно определить вручную).

  1. Используют ли их и другие службы (особенно Athena)?
  2. Где я могу найти списоктакие ключи и их значение, чтобы мои ключи не мешали?

  3. В документах упоминается, что эти пары ключ-значение определяют свойства, связанные с таблицей, и некоторые ограничения:

    1. Каждый ключ - это строка Key, длиной не менее 1 или более 255 байт, соответствующая строковому шаблону из одной строки.
    2. Каждое значение представляет собой строку UTF-8, не более 512000 байтlong.

    Есть ли ограничения на количество ключей, которые может содержать поле Parameters?Влияет ли количество этих пар ключ-значение на производительность при запросе данных?

  4. Насколько важно синхронизировать поле Parameters для таблицы, раздела и дескрипторов их хранения

1 Ответ

0 голосов
/ 26 сентября 2019
  1. Да, например, спектр Redshift использует его для оптимизации плана запроса - https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_TABLE.html#r_CREATE_EXTERNAL_TABLE-parameters

  2. К сожалению, нет полного документа, объясняющего все TBLPROPERTIES.

    • Но в приведенной выше ссылке Rdshift Spectrum вы можете найти лишь несколько.
    • Вы можете запустить следующий sql-запрос в Афине, чтобы получить TBLPROPERTIES, используемый для данной таблицы: SHOW TBLPROPERTIES <table_name>
    • Вы также можете проверить документ HIVE, так как presto основан на HIVE - https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-ManagedandExternalTablesОбратите внимание, что не все свойства применимы в Афине.

  3. Я не думаю, что это отрицательно влияет на производительность.Внутренние свойства обычно используются для определенных действий, например, crawled_by используется Glue, numRows используется Athena / Redshift, has_encrypted_data используется для проверки, зашифрованы ли данные s3, и т. Д.

  4. Важно поддерживать синхронизацию, поскольку эти свойства используются для эффективного управления таблицей и запросами к ней.Некоторые свойства, например skip.header.line.count=2, могут пропускать первые две строки и не будут обрабатываться как строки данных.
...