Presto ne parvient pas à interroger la table hive

Question

Sur EMR, j'ai créé un jeu de données dans le parquet en utilisant spark et en le stockant sur S3. Je suis actuellement capable de créer une table externe et l'interroger en utilisant la ruche mais quand j'essaye d'exécuter la même requête en utilisant presto j'obtiens une erreur (la partie référée change à chaque exécution).

2016-11-13T13:11:15.165Z  ERROR remote-task-callback-36 com.facebook.presto.execution.StageStateMachine Stage 20161113_131114_00004_yp8y5.1 failed 
com.facebook.presto.spi.PrestoException: Error opening Hive split s3://my_bucket/my_table/part-r-00013-b17b4495-f407-49e0-9d15-41bb0b68c605.snappy.parquet (offset=1100508800, length=68781800): null 
     at com.facebook.presto.hive.parquet.ParquetHiveRecordCursor.createParquetRecordReader(ParquetHiveRecordCursor.java:475) 
    at com.facebook.presto.hive.parquet.ParquetHiveRecordCursor.<init>(ParquetHiveRecordCursor.java:247) 
    at com.facebook.presto.hive.parquet.ParquetRecordCursorProvider.createHiveRecordCursor(ParquetRecordCursorProvider.java:96) 
    at com.facebook.presto.hive.HivePageSourceProvider.getHiveRecordCursor(HivePageSourceProvider.java:129) 
    at com.facebook.presto.hive.HivePageSourceProvider.createPageSource(HivePageSourceProvider.java:107) 
    at com.facebook.presto.spi.connector.classloader.ClassLoaderSafeConnectorPageSourceProvider.createPageSource(ClassLoaderSafeConnectorPageSourceProvider.java:44) 
    at com.facebook.presto.split.PageSourceManager.createPageSource(PageSourceManager.java:48) 
    at com.facebook.presto.operator.TableScanOperator.createSourceIfNecessary(TableScanOperator.java:268) 
    at com.facebook.presto.operator.TableScanOperator.isFinished(TableScanOperator.java:210) 
    at com.facebook.presto.operator.Driver.processInternal(Driver.java:375) 
    at com.facebook.presto.operator.Driver.processFor(Driver.java:301) 
    at com.facebook.presto.execution.SqlTaskExecution$DriverSplitRunner.processFor(SqlTaskExecution.java:622) 
    at com.facebook.presto.execution.TaskExecutor$PrioritizedSplitRunner.process(TaskExecutor.java:529) 
    at com.facebook.presto.execution.TaskExecutor$Runner.run(TaskExecutor.java:665) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
    at java.lang.Thread.run(Thread.java:745) 
Caused by: java.io.EOFException 
    at java.io.DataInputStream.readFully(DataInputStream.java:197) 
    at java.io.DataInputStream.readFully(DataInputStream.java:169) 
    at parquet.hadoop.ParquetFileReader.readFooter(ParquetFileReader.java:420) 
    at parquet.hadoop.ParquetFileReader.readFooter(ParquetFileReader.java:385) 
    at com.facebook.presto.hive.parquet.ParquetHiveRecordCursor.lambda$createParquetRecordReader$0(ParquetHiveRecordCursor.java:416) 
    at com.facebook.presto.hive.authentication.NoHdfsAuthentication.doAs(NoHdfsAuthentication.java:23) 
    at com.facebook.presto.hive.HdfsEnvironment.doAs(HdfsEnvironment.java:76) 
    at com.facebook.presto.hive.parquet.ParquetHiveRecordCursor.createParquetRecordReader(ParquetHiveRecordCursor.java:416) 
    ... 16 more 

L'emplacement du parquet est constitué par 128 parties - les données sont stockées sur S3 et cryptées avec le cryptage côté client avec KMS. Presto utilise un fournisseur de chiffrement de matériaux personnalisé (spécifié en utilisant presto.s3.encryption-materials-provider) qui renvoie simplement un objet KMSEncryptionMaterials initialisé avec ma clé principale. J'utilise EMR 5.1.0 (Hive 2.1.0, Spark 2.0.1, Presto 0.152.3).

Answer 1

Cette surface est-elle désactivée lorsque le cryptage est désactivé?

Il y avait un rapport de bogue qui a fait surface sur le client ASF s3a (pas le EMR), où les choses se brisaient quand la longueur du système de fichiers était indiquée! = Longueur réelle du fichier. C'est-à-dire: à cause du cryptage, la longueur du fichier dans une liste était> la longueur d'une lecture. Nous ne pouvions pas le reprocher dans nos tests, et notre conclusion était de toute façon "les systèmes de fichiers ne doivent pas faire cela" (en effet, c'est une exigence fondamentale de la spécification Hadoop FS: la longueur listée doit être égale à la longueur réelle). Si le code EMR se trompe, c'est quelque chose dans leur pilote que le code aval ne peut pas gérer