Wsparcie dla parkietu jako format wejścia/wyjścia podczas pracy z S3

Question

Widziałem kilka pytań opisujących problemy podczas pracy z S3 w Spark:

• Spark jobs finishes but application takes time to close
• spark-1.4.1 saveAsTextFile to S3 is very slow on emr-4.0.0
• Writing Spark checkpoints to S3 is too slow

wiele konkretnych opisów problemów z plikami parkietu:

• Slow or incomplete saveAsParquetFile from EMR Spark to S3
• Does Spark support Partition Pruning with Parquet Files
• is Parquet predicate pushdown works on S3 using Spark non EMR?
• Huge delays translating the DAG to tasks
• Fast Parquet row count in Spark

jak niektóre źródła zewnętrzne odnoszące się do innych kwestii związanych z Spark - kombinacje parkiet - S3. To sprawia, że ​​myślę, że albo S3 z Sparkiem, albo ta kompletna kombinacja może nie być najlepszym wyborem.

Czy jestem czymś tutaj? Czy ktoś może podać autorytatywną odpowiedź wyjaśniającą:

• Bieżący stan obsługi Parkietu z ustawieniem ostrości na S3.
• Czy Spark (SQL) może w pełni korzystać z funkcji Parkietu, takich jak przycinanie partycji, przesuwanie predykatów (w tym głęboko zagnieżdżone schematy) i metadane Parkietu. Wszystkie te funkcje działają zgodnie z oczekiwaniami na S3 (lub zgodnych rozwiązaniach pamięci masowej).
• Aktualne wydarzenia i otwarte bilety JIRA.
• Czy są jakieś opcje konfiguracji, które powinny być świadome podczas korzystania z tych trzech razem?

Answer 1

Wiele problemów nie ma charakteru parkietowego, ale S3 nie jest systemem plików, pomimo tego, że interfejsy API próbują to tak wyglądać. Wiele operacji o nominalnie niskim koszcie pobiera wiele żądań HTTPS, co powoduje opóźnienia.

Odnośnie JIRAs

• HADOOP-11694; S3A faza II - wszystko, co dostaniesz w Hadoop 2.8. Wiele z tego jest już w HDP2.5 i tak, ma znaczące zalety.
• HADOOP-13204: lista zadań do wykonania.
• Jeśli chodzi o iskrę (i ul, użycie rename() do popełnienia pracy to zabójca. Jest używany na końcu zadań i zadań oraz w punktach kontrolnych. Im więcej danych wyjściowych generujesz, tym dłużej zajmuje Ci ukończenie. s3guard work będzie zawierał program o zerowej zmianie nazwy, ale zajmie to dużo czasu i czasu, aby przenieść do niego elementy.

Parkiet? przesunięcie działa, ale jest kilka innych opcji, które przyspieszają działanie. Wymieniam je i inne w: http://www.slideshare.net/steve_l/apache-spark-and-object-stores