Я подключил каталог Glue к Афине и экземпляру 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)
@PiotrFindeisen Я обнаружил исключение в режиме отладки для presto. Подробности добавлены выше. Не знаю, как исследовать отдельные файлы, так как в S3 большое количество паркетных файлов. Я не понимаю, почему Hive-sql может выдавать строки.
Попробуйте set session hive.parquet.use-column-names = true.
@PiotrFindeisen Я вижу эту ошибку при выполнении инструкции в presto cli. Query 20180917_103930_00031_4988g failed: line 1:29: mismatched input '-'. Expecting: '.', '='
set session hive.parquet_use_column_names=true работал.
Извините, я скопировал имя конфигурации вместо свойства сеанса. Рад, что тебе удалось это узнать. Я превращу это в ответ, чтобы ваш вопрос не остался без ответа.





Presto по умолчанию сопоставляет поля в Parquet со схемой таблицы в зависимости от положения. Если порядок ваших полей меняется (например, с течением времени они записывались по-другому), вам необходимо включить сопоставление по имени. Вы можете сделать это с помощью hive.properties:
hive.parquet.use-column-names = true
или на уровне сеанса:
установить сеанс hive.parquet_use_column_names = true;
Вот связанная проблема: https://github.com/prestodb/presto/issues/8911
Если вы изолировали проблему от
table1, сможете ли вы также упростить запрос, который воспроизводит вашу проблему? Вы пытались изучить форматtable1и отдельные файлы? Есть ли несоответствие между схемой файла и схемой таблицы? Можете ли вы выделить проблему в один файл?