btw а кто-нибудь гонял уже дистрибутивы хадупа 3?

Вот на примере дропбокса https://blogs.dropbox.com/tech/2018/06/extending-magic-pocket-innovation-with-the-first-petabyte-scale-smr-drive-deployment/

спасибо, интересно

I have one auto incremental data table in mysql ,one historical table is there using confluent I created one source and in sink part I try to join this two tables based on column in spark streaming ? Can any one help me on this

I have one auto incremental data table in mysql ,one historical table is there using confluent I created one source and in sink part I try to join this two tables based on column in spark streaming ? Can any one help me on this

What is the problem here? You can operate this way but it could be bad from the arch view to join the stream with your history because of size and "cache" invalidation ?

На рбк выложили аналитику зарплат, в т.ч. для биг даты https://www.rbc.ru/own_business/24/09/2018/5ba4e1999a79475b1992df91?from=main

Приятно

Интересно как собирались эти данные =) Извините, профессиональное недоверие к процессу формирования отчетности...

Интересно как собирались эти данные =) Извините, профессиональное недоверие к процессу формирования отчетности...

через опросы у менеджмента на конфах)

На конфах по БихДате )

по HR)

ну тогда верю... для hr найти кого-то по тегу bigdata - еще та задача... сейчас компании чаще нанимают кого-то чтоб он/она уже нанял правильных людей под цели компании. "специалист по BigData" - это прям "меганиочем" профессия. как нанять на стройку дома "специалиста по стройке дома".

коллеги, добрый вечер. пока еще актуальна тема поиска для hr хотела проконсультироваться, если вам не трудно сможете подсказать, пожалуйста, что значит использование S3 в AWS? насколько часто этот инструмент используется? и для чего?

буду очень признательна)

коллеги, добрый вечер. пока еще актуальна тема поиска для hr хотела проконсультироваться, если вам не трудно сможете подсказать, пожалуйста, что значит использование S3 в AWS? насколько часто этот инструмент используется? и для чего?

https://en.wikipedia.org/wiki/Amazon_S3

можно как аналог хдфс рассматривать

насколько s3 популярен? уступает hdfs?

в целом сильно медленнее

в целом сильно медленнее

это что еще за авторитетное мнение?)

насколько s3 популярен? уступает hdfs?

популярен сильно, потому что сервис) уступает или не уступает это от юзкейсов зависит; все технологии так-то не идеальны

Привет) вопрос по спарку. Есть 12 нод, по ресурсам суммарно 1.3 ТБ памяти, 300 VCores. Есть данные в bzip на 30-40 гигов. Внутри json'ы в текстовых файликах. Json'ы с довольно большим набором полей, но их нужно по сути фильтровать по одному из полей и писать и в разные дирректории разные (небольшие) наборы полей. Собственно, сильно уперлись в производительность. Когда было около 5-10 гигов, все было ок. Сейчас отъедается много ресурсов и по несколько часов висят задачи на выполнении. Сделал динамическое выделение ресурсов, но все равно все очень плохо. Пробовал сделать что-то из вот этого цикла статей — тоже не помогло (http://www.treselle.com/blog/apache-spark-performance-tuning-degree-of-parallelism/) Не подскажете, куда копать?) Мб как-то делить данные и грузить кусочками или есть вариант загрузить все в датафрейм, а потом уже с ним работать?

Привет) вопрос по спарку. Есть 12 нод, по ресурсам суммарно 1.3 ТБ памяти, 300 VCores. Есть данные в bzip на 30-40 гигов. Внутри json'ы в текстовых файликах. Json'ы с довольно большим набором полей, но их нужно по сути фильтровать по одному из полей и писать и в разные дирректории разные (небольшие) наборы полей. Собственно, сильно уперлись в производительность. Когда было около 5-10 гигов, все было ок. Сейчас отъедается много ресурсов и по несколько часов висят задачи на выполнении. Сделал динамическое выделение ресурсов, но все равно все очень плохо. Пробовал сделать что-то из вот этого цикла статей — тоже не помогло (http://www.treselle.com/blog/apache-spark-performance-tuning-degree-of-parallelism/) Не подскажете, куда копать?) Мб как-то делить данные и грузить кусочками или есть вариант загрузить все в датафрейм, а потом уже с ним работать?

Схему ещё заранее определить можно

Схему ещё заранее определить можно

это сделал)

это что еще за авторитетное мнение?)

авторитеты вообще идут лесом со своим отлитым в чугуне мнением. практика рулит. ж)

авторитеты вообще идут лесом со своим отлитым в чугуне мнением. практика рулит. ж)

я про тебя говорил

самое долгое там - это метод write (собственно, когда все операции выполняются). Пробовал в промежуточных стадиях добавлсять .Show (как я понимаю, это из списка actions и должно приводить к выполнению очереди операций), но что-то тоже не алё

популярен сильно, потому что сервис) уступает или не уступает это от юзкейсов зависит; все технологии так-то не идеальны

ну такое что скажешь на "популярен ли кобол?"

ну такое что скажешь на "популярен ли кобол?"

попуряен

попуряен

самый популярный, но этого не видно потому что он в среде достаточно закрытой также бы я и не говорил про s3б потому что нет инфы про закрытые экосистемы

самый популярный, но этого не видно потому что он в среде достаточно закрытой также бы я и не говорил про s3б потому что нет инфы про закрытые экосистемы

ну он популярный в рамках авс; да популярный

я про тебя говорил

а я что... в моём случае от прямого чтения-записи в s3 из emr пришлось отказаться, работать с hdfs, воткнуть костыль в виде s3-dist-cp.

потому как запись в s3 тормозит адово на сотнях тыщ партов.

мне кажется тут уже обсуждалось, про проблемы с3 с кучей мелких файлов

потому как запись в s3 тормозит адово на сотнях тыщ партов.

я конечно вообще не знаю ничего про авс, но сотня тыщ портов наводит на некое подозрение

я конечно вообще не знаю ничего про авс, но сотня тыщ портов наводит на некое подозрение

да он где-то описывал то что у них +-

у s3 в авс в дизайне есть изъян один, про который явно не говорится нигде. там ключи внутренне сортируются на каждой операции

у s3 в авс в дизайне есть изъян один, про который явно не говорится нигде. там ключи внутренне сортируются на каждой операции

а чем aws привлекателен?

то есть на любом листе, добавлении, удалении и т.п. строится полный список того что в бакете есть, и сортируется.

соответствено на куче ключей s3 начинается задумываться, и всё больше и больше.

а чем aws привлекателен?

быстро работает и не падает при правильном использовании

а так нет проблем

спасибо!

самое долгое там - это метод write (собственно, когда все операции выполняются). Пробовал в промежуточных стадиях добавлсять .Show (как я понимаю, это из списка actions и должно приводить к выполнению очереди операций), но что-то тоже не алё

Зачем?..

ну и с учётом того что ширина линка до s3 зависит от размера инстанса, то с кластерами на мелких инстансах и парой сотен тыщ ключей в бакете снаовится освсем всё плохо.

Господа, тут 2 параллельные независимые дискуссии)

а, сорян

Зачем?..

ну типа чтобы все данные загрузились в DF 1 раз, а потом их уже фильтровать. Иначе на каждой итерации цикла выполняются все стадии из очереди (выгрузка, добавление поля, выборка полей, фильтрация, еще одна выборка полей), а я пытался сделать что-то типа выгрузка, добавление поля, выборка полей - 1 раз и уже в цикле фильтрация, еще одна выборка полей

ну типа чтобы все данные загрузились в DF 1 раз, а потом их уже фильтровать. Иначе на каждой итерации цикла выполняются все стадии из очереди (выгрузка, добавление поля, выборка полей, фильтрация, еще одна выборка полей), а я пытался сделать что-то типа выгрузка, добавление поля, выборка полей - 1 раз и уже в цикле фильтрация, еще одна выборка полей

Для того, чтобы переиспользовать 1 dataframe, сохранив его в памяти, можно использовать cache (или частный случай persist) метод.

Для того, чтобы переиспользовать 1 dataframe, сохранив его в памяти, можно использовать cache (или частный случай persist) метод.

Спасибо) сейчас попробую) Но у меня есть подозрения, что и это может не помочь.

не хочу, чтобы это превращалось в типичный хантинг, поэтому не буду тут засорять чат) если вдруг кому-то интересна позиция DE с релокейтом в Берлин, можно мне писать

не хочу, чтобы это превращалось в типичный хантинг, поэтому не буду тут засорять чат) если вдруг кому-то интересна позиция DE с релокейтом в Берлин, можно мне писать

по современным реалиям "в личку" уже стал типичным хантингом)

в принципе тут можно постить вакансии, запрета нет

я просто не хотела засорять тред)

у s3 в авс в дизайне есть изъян один, про который явно не говорится нигде. там ключи внутренне сортируются на каждой операции

это адхок вывод, или на основе дизайна/кода/... ?

это адхок вывод, или на основе дизайна/кода/... ?

на основе их (Алексея) внутреннего дизайна

сильное просто заявление

тормозам на куче мелких файлов можно немало обьяснений придумать

Спасибо) сейчас попробую) Но у меня есть подозрения, что и это может не помочь.

К сожалению, не совсем понятен твой flow

К сожалению, не совсем понятен твой flow

Если подробно, то: Мне через 1 топик кафки сыпется много разных событий. Это все json'ы, в которых разные наборы полей. В одном из этих полей, собственно, тип события. Я складываю из кафки данные в одну дирректорию hdfs, можно сказать, партиционированную по дням (данные за разные дни - в разных поддиректориях). Затем раз в день мне эти данные нужно разбирать и раскладывать разные события по разным папкам. Раньше я запускал несколько джобов спарка одновременно (по одному для каждого события) и по сути в каждом считывал все данные (за нужные даты), фильтровал по нужному событию и записывал результат. Потом, когда все это стало работать очень долго и отъедать мого ресурсов, я решил сделать так, чтобы данные выгружались один раз, а потом уже полученный датафрейм фильровать, добавлять нужное поле и записывать в дирректории. Но тут как-то лучше не стало. Пробовал динамическое выделение ресурсов, указывать структуру json'а и все такое, но все равно работает супер долго.

Выгружаются данные из hdfs и добавляется новое поле - 1 раз. Далее в цикле по типу события фильтрую исходный DF и использую write parquet метод для записи.

а их штук 20 ?

сильное просто заявление

это вывод из ответа техподдержки. я сам в осадок выпал, когда такое получил на свой запрос. оттуда же и про ограничение в 11 млн клчей, о котором я тут уже писал.

на основе их (Алексея) внутреннего дизайна

ну, а ты тут самый умный, типа.

тормозам на куче мелких файлов можно немало обьяснений придумать

ну с3 не оч работает с большим колвом мелких файлов, как и все больше фс

и хадупоконектор к с3 не самая лушая идея взаимодействовать с с3 s3a / s3n медленные

Если подробно, то: Мне через 1 топик кафки сыпется много разных событий. Это все json'ы, в которых разные наборы полей. В одном из этих полей, собственно, тип события. Я складываю из кафки данные в одну дирректорию hdfs, можно сказать, партиционированную по дням (данные за разные дни - в разных поддиректориях). Затем раз в день мне эти данные нужно разбирать и раскладывать разные события по разным папкам. Раньше я запускал несколько джобов спарка одновременно (по одному для каждого события) и по сути в каждом считывал все данные (за нужные даты), фильтровал по нужному событию и записывал результат. Потом, когда все это стало работать очень долго и отъедать мого ресурсов, я решил сделать так, чтобы данные выгружались один раз, а потом уже полученный датафрейм фильровать, добавлять нужное поле и записывать в дирректории. Но тут как-то лучше не стало. Пробовал динамическое выделение ресурсов, указывать структуру json'а и все такое, но все равно работает супер долго.

А может его сразу на лету раскладывать каким-нибудь streaming engine?

А может его сразу на лету раскладывать каким-нибудь streaming engine?

Вообще можно. Т.е. нет такого, что я все делаю не так, поэтому так медленно?)

Вообще можно. Т.е. нет такого, что я все делаю не так, поэтому так медленно?)

А если кучу джон в parquet сначала класть, а потом фильтровать?

самое долгое там - это метод write (собственно, когда все операции выполняются). Пробовал в промежуточных стадиях добавлсять .Show (как я понимаю, это из списка actions и должно приводить к выполнению очереди операций), но что-то тоже не алё

Так а show же только показывает? Если хочется промежуточную стадию посчитать, cache/persist, но не думаю, что станет лучше.

Так а show же только показывает? Если хочется промежуточную стадию посчитать, cache/persist, но не думаю, что станет лучше.

Я думал, что Спарк перед тем, как что-то показать, сначала вычисляет очередь операций. А так да, это колхоз, лучше cache использовать.

А если кучу джон в parquet сначала класть, а потом фильтровать?

Я вот тоже думал. Потом можно тем же хайвом раскладывать по табличкам. Спасибо :) надо попробовать

Я думал, что Спарк перед тем, как что-то показать, сначала вычисляет очередь операций. А так да, это колхоз, лучше cache использовать.

он это делает, но для show надо только 20 записей (по умолчанию), т.е. как появится эти 20 записей, так дальше вычисления не делает

Ааа, блин)

Спасибо?

а как выглядит DAG?

А если кучу джон в parquet сначала класть, а потом фильтровать?

А чем это лучше?

А чем это лучше?

Выгодная скорость фильтрации за счет push down predicate и общая скорость вычитки

Обработка json/xml/csv на hdfs дорогое удовольствие. Попробуй делать конвертацию при записи. Или изначально формировать в другом формате. Обработка паркета на спарке будет выше чем json при прочих равных

Обработка json/xml/csv на hdfs дорогое удовольствие. Попробуй делать конвертацию при записи. Или изначально формировать в другом формате. Обработка паркета на спарке будет выше чем json при прочих равных

А что такое "обработка на hdfs"?

Если подробно, то: Мне через 1 топик кафки сыпется много разных событий. Это все json'ы, в которых разные наборы полей. В одном из этих полей, собственно, тип события. Я складываю из кафки данные в одну дирректорию hdfs, можно сказать, партиционированную по дням (данные за разные дни - в разных поддиректориях). Затем раз в день мне эти данные нужно разбирать и раскладывать разные события по разным папкам. Раньше я запускал несколько джобов спарка одновременно (по одному для каждого события) и по сути в каждом считывал все данные (за нужные даты), фильтровал по нужному событию и записывал результат. Потом, когда все это стало работать очень долго и отъедать мого ресурсов, я решил сделать так, чтобы данные выгружались один раз, а потом уже полученный датафрейм фильровать, добавлять нужное поле и записывать в дирректории. Но тут как-то лучше не стало. Пробовал динамическое выделение ресурсов, указывать структуру json'а и все такое, но все равно работает супер долго.

Можно за один проход. В зависимости от типа события делать процессинг и указывать путь для сохранения в ключе, а затем по ключу сохранять данные в отдельные папки. Для этого придется задать свой аутпут формат, но это не сложно. Как-то так: https://gist.github.com/andr83/49d555c4204021985cc6f138b118d78a

Ну или еще вариант партицировать сырые данные по типу события и запускать разные процессинги с быстрой фильтрацией.

А что такое "обработка на hdfs"?

Вот мне тоже интересно.

Вот мне тоже интересно.

Видимо, чтение Спарком через sc.textFile

Можно за один проход. В зависимости от типа события делать процессинг и указывать путь для сохранения в ключе, а затем по ключу сохранять данные в отдельные папки. Для этого придется задать свой аутпут формат, но это не сложно. Как-то так: https://gist.github.com/andr83/49d555c4204021985cc6f138b118d78a

спасибо!