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

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

{
    "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, < strong> sizeKey. После их суммирования мы получаем те же значения, что и в Table["Parameters"]. Все это имеет смысл, и я предполагаю, что эти значения определяют логику поисковых роботов, когда мы хотим повторно запустить его по требованию или по расписанию.

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

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

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

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

    1. Each key is a Key string, not less than 1 or more than 255 bytes long, matching the Single-line string pattern.
    2. Каждое значение представляет собой строку UTF-8 длиной не более 512000 байт.

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

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

amazon-web-services aws-glue aws-glue-data-catalog
person Ilya Kisil    schedule 26.09.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

  2. К сожалению, нет полного документа, объясняющего все СВОЙСТВА TBL.

    • But you may find few in above Rdshift Spectrum link.
    • Вы можете запустить следующий sql-запрос в athena, чтобы получить 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 может пропустить первые две строки и не будет рассматриваться как строки данных.
person Sandeep Fatangare    schedule 26.09.2019