Гусеничный склеиватель AWS странно разбирает график работы паркета - PullRequest
2 голосов
/ 07 июля 2019

база
Я загружаю журнал с python каждый день (cronjob, используя ipython).
Сервер загрузки - CENTOS7, Dockerized Ubuntu

(base) root@:/# uname -a
Linux f5210d345285 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 GNU/Linux

для сервера DateTime установлено значение utc

cron Процесс
1. Скачать с Афины
2. Создайте pandas датафрейм
3. Получить данные агрегации с сервера MySQL (onpremise)
4. Присоединение и агрегация
5. Сделать окончательный кадр данных
6. Загрузить на s3

final_df.to_parquet(temp_filename, compression=None, engine='fastparquet')
FH = open(temp_filename, 'rb')
data_bytes = FH.read()
FH.close()
os.remove(filename)
boto3.session.resource('s3').Object(bucketname, s3pathname).put(Body=data_bytes)
  1. Работа с клеем-гусеницей
  2. Получите данные из Афины и используйте их (как таблица)

проблема
1. Проблема в столбце даты и времени.
2. Имя столбца datetime - «reg_date», и оно взято из столбца «mariadb», тип «datetime»
3. Когда я отображаю фрейм данных и работаю с ним, 'reg_date' работает нормально.
4. Если я запускаю следующий код, он тоже работает правильно.

final_df.to_parquet(temp_filename, compression=None, engine='fastparquet')
read_df = pd.read_parquet(temp_filename)
display(read_df)
  1. И когда я проверяю файл s3 parquet в веб-браузере консоли AWS с помощью s3, он не показывает никаких проблем. (Я нажимаю s3 -> ведро -> путь -> файл -> выбрать источник -> предварительный просмотр)
    [
    {
        "id": "1251616",
        "press": "8",
        "reg_date": "2019-05-22T14:06:25.000Z", #this line
        "scenario_id": 5072,
        "scheduletype": "1",
        "url": "some url string",
        "user_id": "some id string",
        "writer": "some writer name string",
        "deleted": "0",
        "display": "1",
        "keyword": "some keyword string",
        "modifier": "some modifier string",
        "scenario_reg_date": "2019-05-15 15:04:24",
        "sentence": "some long string..",
        "standby_transmission": "1",
        "subject": "some long string..",
        "scenario_user_id": "some user id string",
        "press_name": "some string",
        "press_url": "some url string",
        "press_host": "some url string",
        "gaid": "some string",
        "article_number": 233235,
        "article_uid": "some string",
        "ga:adsenseadsclicks": 0,
        "ga:adsenseadsviewed": 11,
        "ga:adsensectr": 0,
        "ga:adsenseecpm": 0,
        "ga:adsenserevenue": 0,
        "ga:adsenseviewableimpressionpercent": 0,
        "ga:contentgroup1": "some string",
        "ga:contentgroup2": "some string",
        "ga:date": 20190704,
        "ga:hostname": "some string",
        "ga:hour": 12,
        "ga:keyword": "some string",
        "ga:pagepath": "some string",
        "ga:pagetitle": "some string",
        "ga:pageviews": 1,
        "ga:sessions": 1,
        "ga:source": "some string",
        "host": "some string",
        "adsenseattached": 1,
        "eventtime": "2019-07-04T12:00:00.000Z"
    },
    {
        "id": "1251616",
        "press": "8",
        "reg_date": "2019-05-22T14:06:25.000Z",  #and .. this line also
        "scenario_id": 5072,
        "scheduletype": "1",
    ....
    ....
  1. Я думаю, что столбец reg_date совершенно нормален.
  2. Но когда я запускаю сканер клея и выполняю предпросмотр с помощью athena, получается странно.
#in athena
SELECT "id","reg_date","scenario_reg_date" FROM "catalog-name"."table_name" limit 10

результат

idx|id     |reg_date                 |scenario_reg_date
1  |1251616|+51357-12-22 18:56:40.000|2019-05-15 15:04:24
2  |1361993|+51390-05-01 13:36:40.000|2019-05-15 15:04:24
3  |1461362|+51417-09-19 00:53:20.000|2019-05-15 15:04:24
4  |1461362|+51417-09-19 00:53:20.000|2019-05-15 15:04:24
5  |1461362|+51417-09-19 00:53:20.000|2019-05-15 15:04:24
  1. Столбец 'reg_date' становится странным!
  2. Сканер клея настроен на все основные, только набор iam, имя каталога данных, источник s3, и они являются базовой категорией настройки

Тип вещей следующий:

type(result_df['reg_date'][0])
#pandas._libs.tslibs.timestamps.Timestamp

type(result_df['scenario_reg_date'][0])
#str

Я пробовал следующие вещи.

  1. dataframe.to_parquet (двигатель = 'pyarrow')
    это сохраняет метку времени для типа bigint. так что гусеничный сканер распознает и его тип bigint. и запрос Афины также показывает его тип bigint.

  2. dataframe ['reg_date'] = dataframe ['reg_date']. Apply (лямбда-x: x.to_pydatetime (). Strftime ("% Y-% m-% dT% H:% M:% S .% FZ ")
    в этом случае консоль s3 показывает это нормально, но сканер клея распознал его как строковый тип ... и Афина тоже.

Я думаю, что у формата паркета есть какой-то секрет, чтобы сохранить его схему.

Я ожидаю ...

Приклейте гусеничный инструмент для анализа даты и времени по обычному времени.
не + 51357-12-22 18: 56: 40.000 , просто 2019-05-22 14: 06: 25.000 как script_reg_date столбец.

И я хочу знать, почему возникает эта проблема.

Я пробурил в нем более 5 часов, и он испортил весь мой день.

Как мне решить эту проблему?

1 Ответ

0 голосов
/ 08 июля 2019

Афина требует формат Java TIMESTAMP: YYYY-MM-DD HH:MM:SS.fffffffff.Вам необходимо настроить значение в соответствии с этим форматом. Источник здесь

Обратите внимание, что сканеры Glue часто не могут обнаружить столбцы меток времени и классифицировать их как строки (например, scenario_reg_date).Поэтому, если вы захотите использовать функциональность даты позже в этих столбцах, вам нужно взять DDL таблицы> вручную преобразовать типы данных> удалить и заново создать таблицу.

...