Comments 14
Насколько parquet применим при отсутствии hadoop-common в classpath? У меня сложилось первое впечатление, что он довольно сильно завязан на куски хадупа.
К сожалению, точного ответа на этот вопрос у нас нет, так как непосредственно из java мы с parquet не работали, работаем только из Спарка. При этом parquet — это лишь формат, значит теоритически с ним можно работать и без единого пересечения с hadoop. Более того, существует реализация на c++ parquet-cpp для чтения файлов, что говорит о том, что hadoop не обязателен. Сама по себе конструкция этого формата хоть и разрабатывалась специально для hadoop но не предполагает его наличие, также надо понимать, что вся прелесть этого формата в том, что с ним легко работать через MapReduce и необходимо что-то похожее на hadoop, поэтому во многих библиотеках и примерах всегда присутствует импорт hadoop-библиотек.
почему? внутри трифт (https://github.com/Parquet/parquet-format) Ну и прямо из документации:
Thrift can be also code-genned into any other thrift-supported language., а питонячий пример подсмотреть например тут: https://github.com/jcrobak/parquet-python/tree/master/parquet
Расскажите, какое вы используете хранилище (насколько я понял, это не HDFS) в кластере.
На данный момент мы используем терабайтные SSD, примонтированные по NFS. Есть несколько нюансов: довольно неудобная масштабируемость и проблемы с маппингом данных за всю историю (приходится указывать разные пути). Пока мы не хотим использовать HFS, так как придется обязательно тащить hadoop и YARN. В данном случае для нас важно обеспечить максимально эффективное многократное чтение данных за большой период истории, поэтому сейчас мы рассматриваем GlusterFS в режиме Distributed. Striped режим мы считаем излишним, так как "паркет" уже разбит на куски, соответствующие MR порции — группы строк, как описывается в статье. Более того, наличие POSIX интерфейса довольно удобно для интеграции. В любом случае пока мы остановились только на parquet-файлах, их можно перенести в любое хранилище в дальнейшем, так что это дает нам возможность для экспериментов. Остальная часть инфраструктуры постоянно меняется, мы экспериментируем и постараемся рассказывать о результатах.
Кроме как в Spark, Parquet не всегда обладает нативной поддержкой в других продуктах.
можно подробней о каких продуктах идет речь? так как у нас математики без проблем читают паркет в питоновские датафреймы, impala & hive так вообще нативно подхватывают. Читать файлы из java тоже не составляет никакого труда.
Не поддерживаются транзакции, так как это обычные файлы а не БД.
он и не должен, это формат хранения ;) к тому же immutable
На данный момент мы используем терабайтные SSD, примонтированные по NFS
Пока мы не хотим использовать HFS, так как придется обязательно тащить hadoop и YARN
подозреваю хотели написать HDFS, но не суть
почему установка HDFS сразу же подразумевает установку YARN и остальных вещей? (у самого крутиться HDFS + HBase без какого-либо YARN). HDFS — распределенное хранилище, YARN — вычислительная платформа, они достаточно неплохо разделены. Поэтому от standalone spark кластера вас никто не заставляет отказываться, можете поднять hdfs + spark standalone, проблем никаких нету (подымал такую конфигурацию, от spark yarn отличий в разворачивании на клоудере вообще нету)
к тому же перейдя от NFS на HDFS вы получаете профит в виде локальности данных, ваши spark задачи будут отправляться на ноды на которых эти данные и лежат, а это сразу решает несколько проблем:
1) затыки на дисковом IO, ради чего вы и покупали ссд (все уйдет на локальные диски, которые в сумме выдадут за те же деньги в разы большую производительность)
2) затыки на сетевом интерфейсе (прокачать каких-то 1ТБ даже с 10Гбитной сеткой занимает существенное время, тут же будет независимое чтение с разных дисков и минимум нагрузка на сеть, если все-таки промахнемся с задачей)
HDFS ведь и придумывалось не только для распределенности, но и ради локальности данных (кстати это причина почему хадуп на SAN/NAS у меня вызывает улыбку) и GlusterFS в этом плане вам ничем не поможет, так как спарк не сможет получить распределение блоков.
Колончатый вид заставляет задумываться о схеме и типах данных.
в вашем примере я не понял как парсить и обрабатывать данный json с разной структурой? каждый раз проверяем наличие нужных полей и вложен или нет?
Эффективное хранение с точки зрения занимаемого места.
тут согласен, особенно если сверху еще какой dictionary encoding для строк пройдется, то зачастую вообще копейки на выходе
В общем spark на NFS имеет смысл там же где и GPU вычисления: входных-выходных данных мало, а вычислительной математики много
можно подробней о каких продуктах идет речь? так как у нас математики без проблем читают паркет в питоновские датафреймы, impala & hive так вообще нативно подхватывают. Читать файлы из java тоже не составляет никакого труда.
Да, parquet файлы доступны для чтения, но полная его поддержка с записью возможна только с помощью инструментов с java, с другими — будут проблемы.
подозреваю хотели написать HDFS, но не суть
почему установка HDFS сразу же подразумевает установку YARN и остальных вещей? (у самого крутиться HDFS + HBase без какого-либо YARN). HDFS — распределенное хранилище, YARN — вычислительная платформа, они достаточно неплохо разделены. Поэтому от standalone spark кластера вас никто не заставляет отказываться, можете поднять hdfs + spark standalone, проблем никаких нету (подымал такую конфигурацию, от spark yarn отличий в разворачивании на клоудере вообще нету)
к тому же перейдя от NFS на HDFS вы получаете профит в виде локальности данных, ваши spark задачи будут отправляться на ноды на которых эти данные и лежат, а это сразу решает несколько проблем:
1) затыки на дисковом IO, ради чего вы и покупали ссд (все уйдет на локальные диски, которые в сумме выдадут за те же деньги в разы большую производительность)
2) затыки на сетевом интерфейсе (прокачать каких-то 1ТБ даже с 10Гбитной сеткой занимает существенное время, тут же будет независимое чтение с разных дисков и минимум нагрузка на сеть, если все-таки промахнемся с задачей)
HDFS ведь и придумывалось не только для распределенности, но и ради локальности данных (кстати это причина почему хадуп на SAN/NAS у меня вызывает улыбку) и GlusterFS в этом плане вам ничем не поможет, так как спарк не сможет получить распределение блоков.
Да, имелся в виду HDFS.
GlusterFs мы выбрали, потому что неплохо знаем эту систему. Возможно, в будущем мы развернём HDFS, как только изучим его получше. Также, возможно, внедрим, POSIX интерфейс.
Нас заинтересовал прирост в скорости чтения glusterfs, так как операций чтения у нас намного больше, чем записи, и мы хотели поэкспериментировать с этим. (https://indico.cern.ch/event/214784/session/6/contribution/332/attachments/340854/475673/storage_donvito_chep_2013.pdf)
С другой стороны, локальность данных в HDFS — это сильный аргумент, мы упоминали это как плюс parquet, группы строк как раз и позволяют упростить этот процесс.
По поводу YARN: конечно, никто не запрещает поставить HDFS отдельно, но для него тоже надо выделять ресурсы, и это легче всего делать инструментом из инфраструктуры hadoop с помощью YARN.
в вашем примере я не понял как парсить и обрабатывать данный json с разной структурой? каждый раз проверяем наличие нужных полей и вложен или нет?
В данном случае мы предполагаем, что все значения — это строки, и мы просто пробегаемся по ключам json и всё, что является значением, кастуем в строку, даже если это вложенный объект. Разумеется, за исключением тех ключей, для которых мы определили схему. Это похоже на белый список, где мы только для известных и важных нам ключей указываем тип, будь это целочисленный или вложенный объект. Если мы помечаем ключ как содержащий вложенный объект, то применяем всю логику рекурсивно.
Когда мы встречаемся со смешением строк и вложенных объектов, как в примере, то добавляем логику, которая для конкретного ключа построит вложенный объект и в нем запишет это значение (например, с ключом "some_value"). Т.е., если опираться на пример, то первый случай, когда к нам пришла строка, выглядит так:
{
“event_name”: “event 1”,
“value”: {"some_key_name": “this is first value”},
}
Далее аналитик может разобрать не задекларированные ключи с помощью map функций.
По поводу YARN: конечно, никто не запрещает поставить HDFS отдельно, но для него тоже надо выделять ресурсы, и это легче всего делать инструментом из инфраструктуры hadoop с помощью YARN.
HDFS НЕЛЬЗЯ поставить через YARN =) у них разные задачи
с помощью yarn можно:
1) развернуть spark
2) запустить map-reduce задачу
3) с определенными костылями запустить hbase
но вот yarn сам использует для некоторых задач hdfs, поэтому можно рассматривать что yarn работает поверх hdfs.
Думаю вы видели данную картинку, на которой видно что HDFS без YARN нормально живет и кушать не просит.
Нас заинтересовал прирост в скорости чтения glusterfs, так как операций чтения у нас намного больше
Эти задачи как раз и решает локальность данных, хотя если у вас на вход одна партиция и пару гигабайт данных, то glusterfs может и выиграет, но если имеется 2-3ТБ данных и 20 партиций которые могут локально отфильтровать-сгруппировать данные, то вы сразу проседаете в разы и локальность становится задачей номер 1. Именно поэтому те кто хотел бы использовать glusterfs в качестве замены HDFS пилят glusterfs-hadoop плагины для реализации hdfs интерфейсов по получению метаданных о том где какой блок лежит. Если уж нужен POSIX для hdfs, то FUSE драйвера для него существуют.
Примеры насколько важна локальность данных. А в вашей ссылке проверяли линейное чтение, что конечно полезно когда у вас хранилище отдельно, а обработка отдельно, но в большинстве случаев BigData это не имеет смысла, особенно когда чтение превышает в разы запись.
Далее аналитик может разобрать не задекларированные ключи с помощью map функций.
по поводу хранения:
не оказывается ли в итоге, что основную часть времени вы занимаетесь парсингом?
исходя из своего опыта могу сказать, что иногда проще сделать выборку, распарсить и сохранить в другую parquet-табличку и уже по ней гонять запросы, начиная со 2-3 запроса это окупается. Так как в этом случае вы даже сможете нормально DataFrame использоваться с его поколоночным хранением и компрессией.
HDFS НЕЛЬЗЯ поставить через YARN =) у них разные задачи
с помощью yarn можно:
1) развернуть spark
2) запустить map-reduce задачу
3) с определенными костылями запустить hbase
но вот yarn сам использует для некоторых задач hdfs, поэтому можно рассматривать что yarn работает поверх hdfs
Спасибо за подсказку. Если HDFS можно поставить без остальной hadoop инфраструктуры и он будет вполне себе хорошо работать, то обязательно попробуем! :)
не оказывается ли в итоге, что основную часть времени вы занимаетесь парсингом?
Для большинства задач нам хватает тех полей, для которых схема определена, в остальных случаях, конечно, парсинг доставляет неудобства. Сейчас налаживается процесс, который позволяет аналитику один раз написать map-функцию для парсинга и с помощью неё автоматически создавать специальные обогащённые и чётко структурированные parquet файлы, по которым уже работают все остальные. Собственно, сейчас мы так и поступаем, как вы описали, и из частично структурированных parquet файлов формируем жестко структурированные
(подымал такую конфигурацию, от spark yarn отличий в разворачивании на клоудере вообще нету)в разворачивании может и нет, а шедулить джобы sparka все же лучше предоставить yarn`у, поэтому в _использовании_ разница как раз и проявляется.
в использовании действительно проявляется, в первую очередь на уровне изоляции ресурсов,
с другой стороны если у вас в кластере крутиться только spark для обработки и hive/map-reduce/etc отсутствуют, то yarn будет всего-лишь дополнительной прослойкой
говоря о плюсах-минусах YARN для SPARK мне кажется лишь стоит указать возможность использования кластера разными группами, так как YARN нам может дать гарантии по нарезанию ресурсов с лимитами и что dev задача не скушает весь prod. Но если у нас прод живет отдельно, то там YARN может оказаться оверхедом.
p.s. инструменты выбираются под задачу, а не задачи пытаются подтянуть под используемые инструменты, поэтому как и что гонять становится ясно только после полного изучения задачи и окружения ;)
с другой стороны если у вас в кластере крутиться только spark для обработки и hive/map-reduce/etc отсутствуют, то yarn будет всего-лишь дополнительной прослойкой
говоря о плюсах-минусах YARN для SPARK мне кажется лишь стоит указать возможность использования кластера разными группами, так как YARN нам может дать гарантии по нарезанию ресурсов с лимитами и что dev задача не скушает весь prod. Но если у нас прод живет отдельно, то там YARN может оказаться оверхедом.
p.s. инструменты выбираются под задачу, а не задачи пытаются подтянуть под используемые инструменты, поэтому как и что гонять становится ясно только после полного изучения задачи и окружения ;)
Спасибо за интересную статью!
Кстати, вот неплохое сравнение ряда других форматов\компрессии от Убера: https://eng.uber.com/trip-data-squeeze/
Кстати, вот неплохое сравнение ряда других форматов\компрессии от Убера: https://eng.uber.com/trip-data-squeeze/
Sign up to leave a comment.
Как использовать Parquet и не поскользнуться