Разница в результатах запроса между EMR-Presto и Athena

Я подключил каталог Glue к Athena и экземпляр EMR (с установленным presto). Я попытался выполнить один и тот же запрос на обоих, но получаю разные результаты. EMR дает 0 строк, но Афина дает 43 строки. Запрос довольно простой с left join, group by и count distinct. Запрос выглядит так:

select
  t1.customer_id as id,
  t2.purchase_date as purchase_date,
  count(distinct t1.purchase_id) as item_count
from 
  table1 t1
left join
  table2 as t2
  on t2.purchase_id=t1.purchase_id
where 
  t1.item_type='ABC' 
  and t1.purchase_status='CONFIRMED' 
  and t1.region_id in ('A','B','C')
  and t2.status='Dispatched'
  and t2.purchase_date between date_add('day',-50,date('2018-09-13')) and date('2018-09-13')
  and t1.created_at between date_add('day',-60,date('2018-09-13')) and date('2018-09-13')
  and t1.updated_at between date_add('day',-60,date('2018-09-13')) and date('2018-09-13')
group by
  t1.customer_id,t2.purchase_date;

Я пробовал другие запросы, но результаты полностью совпадают. Не уверен, что не так с этим запросом.

EMR Version: 5.17.0
Presto Version: 0.206

РЕДАКТИРОВАТЬ: Я понял, что проблема в самой первой таблице. По какой-то причине Presto-EMR не может найти строки в table1. Не знаю, почему это произошло, поскольку и Presto-EMR, и Athena используют один и тот же каталог Glue. Я также пробовал Hive в том же экземпляре EMR, и он может находить строки в table1.

select * from table1 limit 10;

Приведенный выше оператор дает 10 строк с hive-sql, но ноль строк с presto-sql. Я вижу следующее исключение в режиме отладки:

Query 20180917_075536_00023_4988g failed: com.facebook.presto.spi.type.TimestampType
java.lang.UnsupportedOperationException: com.facebook.presto.spi.type.TimestampType
    at com.facebook.presto.spi.type.AbstractType.writeSlice(AbstractType.java:135)
    at com.facebook.presto.hive.parquet.reader.ParquetBinaryColumnReader.readValue(ParquetBinaryColumnReader.java:55)
    at com.facebook.presto.hive.parquet.reader.ParquetPrimitiveColumnReader.lambda$readValues$1(ParquetPrimitiveColumnReader.java:184)
    at com.facebook.presto.hive.parquet.reader.ParquetPrimitiveColumnReader.processValues(ParquetPrimitiveColumnReader.java:204)
    at com.facebook.presto.hive.parquet.reader.ParquetPrimitiveColumnReader.readValues(ParquetPrimitiveColumnReader.java:183)
    at com.facebook.presto.hive.parquet.reader.ParquetPrimitiveColumnReader.readPrimitive(ParquetPrimitiveColumnReader.java:171)
    at com.facebook.presto.hive.parquet.reader.ParquetReader.readPrimitive(ParquetReader.java:208)
    at com.facebook.presto.hive.parquet.reader.ParquetReader.readColumnChunk(ParquetReader.java:258)
    at com.facebook.presto.hive.parquet.reader.ParquetReader.readBlock(ParquetReader.java:241)
    at com.facebook.presto.hive.parquet.ParquetPageSource$ParquetBlockLoader.load(ParquetPageSource.java:244)
    at com.facebook.presto.hive.parquet.ParquetPageSource$ParquetBlockLoader.load(ParquetPageSource.java:222)
    at com.facebook.presto.spi.block.LazyBlock.assureLoaded(LazyBlock.java:262)
    at com.facebook.presto.spi.block.LazyBlock.getLoadedBlock(LazyBlock.java:253)
    at com.facebook.presto.spi.Page.getLoadedPage(Page.java:247)
    at com.facebook.presto.operator.TableScanOperator.getOutput(TableScanOperator.java:245)
    at com.facebook.presto.operator.Driver.processInternal(Driver.java:373)
    at com.facebook.presto.operator.Driver.lambda$processFor$8(Driver.java:282)
    at com.facebook.presto.operator.Driver.tryWithLock(Driver.java:672)
    at com.facebook.presto.operator.Driver.processFor(Driver.java:276)
    at com.facebook.presto.execution.SqlTaskExecution$DriverSplitRunner.processFor(SqlTaskExecution.java:973)
    at com.facebook.presto.execution.executor.PrioritizedSplitRunner.process(PrioritizedSplitRunner.java:162)
    at com.facebook.presto.execution.executor.TaskExecutor$TaskRunner.run(TaskExecutor.java:477)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

person ishan3243    schedule 16.09.2018    source источник
comment
Если вы изолировали проблему от table1, сможете ли вы также упростить запрос, который воспроизводит вашу проблему? Вы пытались изучить table1 формат и отдельные файлы? Есть ли несоответствие между схемой файла и схемой таблицы? Можете ли вы выделить проблему в один файл?   -  person Piotr Findeisen    schedule 16.09.2018
comment
@PiotrFindeisen Я обнаружил исключение в режиме отладки для presto. Подробности добавлены выше. Не знаю, как исследовать отдельные файлы, так как в S3 большое количество паркетных файлов. Я не понимаю, почему Hive-sql может выдавать строки.   -  person ishan3243    schedule 17.09.2018
comment
Попробуйте set session hive.parquet.use-column-names = true.   -  person Piotr Findeisen    schedule 17.09.2018
comment
@PiotrFindeisen Я вижу эту ошибку при выполнении инструкции в presto cli. Query 20180917_103930_00031_4988g failed: line 1:29: mismatched input '-'. Expecting: '.', '='   -  person ishan3243    schedule 17.09.2018
comment
set session hive.parquet_use_column_names=true работал.   -  person ishan3243    schedule 17.09.2018
comment
Извините, я скопировал имя конфигурации вместо свойства сеанса. Рад, что тебе удалось это узнать. Я превращу это в ответ, чтобы ваш вопрос не остался без ответа.   -  person Piotr Findeisen    schedule 17.09.2018


Ответы (1)


Presto по умолчанию сопоставляет поля в Parquet со схемой таблицы в зависимости от положения. Если порядок ваших полей меняется (например, с течением времени они записывались по-другому), вам необходимо включить сопоставление по имени. Вы можете сделать это с помощью hive.properties:

hive.parquet.use-column-names = true

или на уровне сеанса:

установить сеанс hive.parquet_use_column_names = true;

Вот связанная проблема: https://github.com/prestodb/presto/issues/8911 < / а>

person Piotr Findeisen    schedule 17.09.2018