Согласно этому сообщению Cloudera, Snappy IS является разделяемым.
Для MapReduce, если вам нужно, чтобы ваши сжатые данные были разделяемыми, форматы BZip2, LZO и Snappy являются разделяемыми, а GZip — нет. Разделяемость не имеет отношения к данным HBase.
Но из полного руководства по Hadoop следует, что Snappy НЕ разделяется. 
В сети также есть некоторая противоречивая информация. Кто-то говорит, что можно разделить, кто-то что нет.
Оба правильны, но на разных уровнях.
Согласно блогу Cloudera http://blog.cloudera.com/blog/2011/09/snappy-and-hadoop/
Следует отметить, что Snappy предназначен для использования с контейнерным форматом
, таким как Sequence Files или Avro Data Files, а не для использования непосредственно с обычным текстом, например, поскольку последний не является разделяемым и не может обрабатываться параллельно с помощью MapReduce. Это отличается от LZO, где можно индексировать сжатые файлы LZO для определения точек разделения, чтобы файлы LZO можно было эффективно обрабатывать при последующей обработке.
Это означает, что если весь текстовый файл сжимается с помощью Snappy, то файл НЕ разделяется. Но если каждая запись внутри файла сжата с помощью Snappy, то файл может быть разделен, например, в файлах последовательности с блочным сжатием.
Чтобы быть более ясным, это не то же самое:
<START-FILE>
<START-SNAPPY-BLOCK>
FULL CONTENT
<END-SNAPPY-BLOCK>
<END-FILE>
чем
<START-FILE>
<START-SNAPPY-BLOCK1>
RECORD1
<END-SNAPPY-BLOCK1>
<START-SNAPPY-BLOCK2>
RECORD2
<END-SNAPPY-BLOCK2>
<START-SNAPPY-BLOCK3>
RECORD3
<END-SNAPPY-BLOCK3>
<END-FILE>
Блоки Snappy НЕ разбиваются, но файлы с блоками Snappy являются разделяемыми.
Все разделяемые кодеки в Hadoop должны реализовывать org.apache.hadoop.io.compress.SplittableCompressionCodec. Глядя на исходный код Hadoop версии 2.7, мы видим, что org.apache.hadoop.io.compress.SnappyCodec не реализует этот интерфейс, поэтому мы знаем, что он не разделяемый.
Я только что протестировал Spark 1.6.2 на HDFS для того же количества рабочих/процессоров между простым файлом JSON и сжатым с помощью snappy:
Файл Snappy создается следующим образом: .saveAsTextFile("/user/qwant/benchmark_file_format/json_snappy", classOf[org.apache.hadoop.io.compress.SnappyCodec])
Таким образом, Snappy нельзя разделить с помощью Spark для JSON.
Но, если вы используете формат файла parquet (или ORC) вместо JSON, он будет разделяемым (даже с помощью gzip).
Snappy на самом деле не является разделяемым, как bzip, но при использовании с такими форматами файлов, как паркет или Avro, вместо сжатия всего файла блоки внутри формата файла сжимаются с помощью snappy.
Чтобы понять, что происходит, когда вы сжимаете файл паркета с быстрым сжатием, проверьте структуру файла паркета [источник ссылка]
Внутри файла паркета записи разбиты на группы строк [в основном подмножество строк из исходного файла], и каждая группа строк состоит из страниц данных [фрагменты столбцов на изображении], каждый фрагмент столбца состоит из многих страниц. где фактические записи хранятся в закодированном формате [столбец] с метаданными. когда вы включаете быстрое сжатие, он сжимает целые страницы! не весь файл. в основном вы получаете расщепляемый паркет с быстрым сжатием.
Преимущество snappy в том, что это кодек с очень легким взвешенным сжатием.
Примечание. Существует ограничение размера по умолчанию для блоков строк и столбцов, 128 МБ и 1 МБ соответственно [вы можете изменить эти настройки по умолчанию], вы можете использовать другой кодек сжатия с паркетом, например. gzip
