AWS Glue Crawler обновляет существующие таблицы каталогов (мучительно) медленно - PullRequest
Новая
       12

AWS Glue Crawler обновляет существующие таблицы каталогов (мучительно) медленно

1 голос
/ 12 марта 2020

Я постоянно получаю и сохраняю несколько каналов несжатых JSON объектов, разделенных в день, в разные места корзины Amazon S3 (стиль улья: s3://bucket/object=<object>/year=<year>/month=<month>/day=<day>/object_001.json) и планировал поэтапную пакетную загрузку и загрузку этих данных в озеро данных Parquet с помощью AWS Glue:

  • Искатели обновили бы созданные вручную таблицы Glue, по одной на канал объекта, для схемы и раздела (новые файлы) обновления;
  • Склейка ETL Jobs + закладка Job затем будет затем группировать и отображать все новые разделы для каждой подачи объекта в местоположение Parquet время от времени.

Этот шаблон проектирования & Архитектура казалась довольно безопасным подходом, поскольку ее поддерживали многие AWS блоги, здесь и там .

У меня сканер, настроенный так: 

{
  "Name": "my-json-crawler",
  "Targets": {
    "CatalogTargets": [
      {
        "DatabaseName": "my-json-db",
        "Tables": [
          "some-partitionned-json-in-s3-1",
          "some-partitionned-json-in-s3-2",
          ...
        ]
      }
    ]
  },
  "SchemaChangePolicy": {
    "UpdateBehavior": "UPDATE_IN_DATABASE",
    "DeleteBehavior": "LOG"
  },
  "Configuration": "{\"Version\":1.0,\"Grouping\":{\"TableGroupingPolicy\":\"CombineCompatibleSchemas\"}}"
}

И каждая таблица была «вручную» инициализирована следующим образом: 

{
  "Name": "some-partitionned-json-in-s3-1",
  "DatabaseName": "my-json-db",
  "StorageDescriptor": {
    "Columns": [] # i'd like the crawler to figure this out on his first crawl,
    "Location": "s3://bucket/object=some-partitionned-json-in-s3-1/",
    "PartitionKeys": [
      {
        "Name": "year",
        "Type": "string"
      },
      {
        "Name": "month",
        "Type": "string"
      },
      {
        "Name": "day",
        "Type": "string"
      }
    ],
    "TableType": "EXTERNAL_TABLE"
  }
}

Первый запуск сканера, как и ожидалось, длился час-я sh, но он успешно вычисляет таблицу Схема и существующие разделы. Однако с этого момента повторный запуск сканера занимает столько же времени, сколько и первый сканер, если не дольше; что заставляет меня поверить, что сканер не только сканирует новые файлы / разделы, но и каждый раз перечитывает все местоположения S3.

Обратите внимание, что дельта новых файлов между двумя обходами очень мала (мало новых файлы следует ожидать каждый раз).

AWS Документация предлагает запуск нескольких сканеров, но я не уверен, что это решит мою проблему в долгосрочной перспективе. Я также рассмотрел вопрос об обновлении шаблона исключения сканера после каждого запуска, но тогда я увидел бы слишком мало преимуществ использования сканеров по сравнению с ручным обновлением разделов таблиц через некоторые Lambda boto3 magi c.

Я что-то там упустил? Может быть, вариант, который я бы неправильно понял, касается сканеров, обновляющих существующие каталоги данных, а не сканирующих хранилища данных напрямую?

Есть предложения по улучшению моей каталогизации данных? Учитывая, что индексирование этих JSON файлов в таблицах Glue необходимо только мне, так как я хочу, чтобы моя Glue Job использовала закладки.

Спасибо!

...