IMHO, статья похожа на выполнение плана по статьям.
Про то, как устроен kaggle гораздо лучше прочитать на самом сайте. А чтобы рассказать, что платформа классная, нагляднее всего поделиться опытом участия и решением.
Так просто пандасом паркет из hdfs не прочитать напрямую. В пандасе нет драйвера до hdfs. А по поводу памяти - жестких дисков всегда больше чем оперативной памяти. Если вы готовы прочитать файл в оперативку в пандасе, то и на диск точно сможете соханить
Да, на C много low-level алгоритмов. Но это как правило специальный код, где используются питоновские типы данных. Вот, например, преобразование фурье в numpy. Там его ну никак не отделишь..
Есть библиотеки вроде xgboost или catboost, который написан на cpp и имеют биндинги к нескольким языкам. У них есть версии для JVM. Но это довольно ограниченный набор библиотек
Но также очень много кода (интерфейсного) написано на чистом питоне. И тут вообще никак не отделить
Ну и Spark ML - оч достойный, но узкоспециализированный фрейморк. Он содержит небольшой набор алгоритмов. Популярность не оч высокая. Алгоритмы только параллельные (а не все алгоритмы хорошо параллелятся, поэтому параллелизация дает трейдоффы) Есть конечно, например, catboost для spark, который мы даже запускали. Но там не все фичи поддерживаются и мы отказались в итоге
Какие-то библиотеки для скалы конечно есть, но по уровню их развития и сообщества несравнимы. Можно сказать, что питоновские либы отлажены на сотнях тысяч если не миллионах пользователей.
Во времена моей работы в Сбере, у нас все продовые витрины были на скале, и на скале писали ноутбуки аналитики из команды витрин. Но все остальные сидели на pySpark.
В Авито же мы сидим только на pySpark, ибо количество людей тут меньше и объем работы на человека больше. Дата инженеров мало. Аналитик сам должен докатить витрину до airflow и даже тесты написать. Нашими инженерами было принято решение дополнительную технологию пока не затаскивать. Хотя смотря на некоторые монструозные питоновские udf я кусаю локти))
Да, я согласен, что скала для спарка, это несколько процентов от скалы. Я на самом деле тоже оч топлю за скалу. Но порог входа все-таки высокий. Я причем имею выборку из довольно большого количества людей, которые учились писать на спарке, в том числе переходили с питона на скалу. Когда я еще в Сбере работал, мы обучили порядка 50 человек, примерно половина из которых до этого не умела писать на питоне особо даже (sql+excel)
Скала к тому же не покрывает всех задач аналитиков и ds-ов. Обычный пайплайн: собрал витринку, сделал toPandas, строишь графики обычным питоновским стеком, модели обучаешь и тд. Дмитрий Бугайченко я помню активно топил за анализ данных прямо на скале (https://habr.com/ru/companies/vk/articles/442688/ например) и даже в ньюпролабах был такой курс. Но это все-таки не мейнстрим.
Наверное потому что спарк изначально занял нишу продвинутого инструмента. В качестве основного инструмента у нас большая часть аналитиков сидит на вертике. В большинстве других компаний тоже стоит какая-то MPP (massive parallel processing) база, гринплам там или еще что-то. И эти MPP из коробки закрывают очень много всего.
Отличие спарка от MPP баз отдельный вопрос. Но одно из преимуществ спарка - наличие контроля: выделяемых ресурсов, оптимизации, данных, которые в памяти, а которые нет и прочее. За счет этого спарк может решать потенциально более сложные задачи и масштабироваться.
В Сбере нам приходилось использовать хадуп и спарк в первую очередь потому что только он позволял нам построить единое федеративное хранилище на десятки независимых подразделений и тысячи пользователей. Кто поднимал свой гринплам, например, мучался - с трудом забирал и отдавал данные во вне. Хотя с точки зрения пользовательского опыта гринплам гораздо комфортнее спарка.
ну тут простое соображение — если занять все ядра, почти, и оставить сколько-то простаивать — то кто их займет? Это неэффективная трата ядер. Сколько их выделено ярну — это вопрос немножко отдельный, но в любом случае, я рассчитываю что мы можем это узнать — и учесть.
Прошу прощения, немного не понял все-таки. А можете еще раз более подробно описать логику выбора размера экзекьюторов? Правильно я понял, что через API ярна можно посмотреть сколько доступно ядер на каждой ноде? (я про это не знал, нужно будет разобраться) И исходя из этого выбрать?
Валидно.. Тема сохранения достаточно большая и у меня даже есть драфт отдельной статьи на эту тему. Там есть бенчмарки по toPandas с и без arrow оптимизации, а также про скачивания с hdfs. Для теста кстати получилось выгрузить через toPandas датасет в 40Гб (за 5 мин, с arrow оптимизацией)
берите в 5-10 раз больше памяти, чем занимают ваши данные;
Вы смотрите с перспективы дата инженера, где вы оптимизируете жесткие расчеты =) Я думаю для аналитика такое не норма. Я пытаюсь донести аналитикам мысль, если данные занимают так много, что не влезают, то нужно считать меньшими кусочками. Или нести задачу дата инженерам. Потому что если аналитик будет регулярно бесконтрольно в ноутбуке запускать жесткие расчеты (а в них скорее всего будут дата спиллы), это будет руинить кластер. У меня такое в практике увы было не раз( Периодически умирал кластер, начинали выяснять, оказывалось, что кто-то регулярно насиловал кластер чем-то очень жестким.
По ядрам все просто: чем их больше, тем быстрее идут расчёты.
Это правда.. Нужно будет про партиционирование и джойны написать отдельный гайд.
Привет! Спасибо за классные комментарии! Перед переходом к деталям, нужно наверное отметить идею статьи. Задача - научить работать со спарком именно аналитика, а не дата инженера. Поэтому моя цель была - дать какие-то простые эвристические рекомендации для работы.
Если вы изменили spark.driver.memory, нужно поднимать maxResultSize до эквивалентных значений.
Да, про бродкаст я кстати не написал. Для него может быть тоже нужно расширять драйвер. Но не понятно, зачем ограничивать driver.maxResultSize и делать его меньше driver.memory. Нужно понимать, что аналитик делает исследование, пишет код с нуля. Он часто не знает заранее что ему потребуется
Да, про бродкаст я кстати не написал. Для него может быть тоже нужно расширять драйвер. Но не понятно, зачем ограничивать driver.maxResultSize и делать его меньше driver.memory. Нужно понимать, что аналитик делает исследование, пишет код с нуля. Он часто не знает заранее что ему потребуется
Fair комментарий, что непонятно какие ядра и прочее. В статье, на которую я дал ссылку, один человек сделал один тест и верно, что на него нельзя полагаться как на истину. Но тем не менее это референс. Опять же - у аналитика нет возможности запускать один и тот же код 10 раз, чтобы подобрать параметры. Ему нужен какой-то стандартный конфиг.
Про то, чтобы все ядра на ноде занимать, не очень понял.. На ярн потому что выделяется не 100% ядер. По умолчанию две трети вроде. Или вы про то, чтобы доступные ядра делились на количество экзекьюторов? Последнее - хорошая идея. Но там то драйвер, то еще что-то, то кто-то выделит с другим количеством. Не подгадаешь. 16 ядер это конечно немного, мб на них и правда нужно брать поменьше экзекьюторы
А кстати, как вы считаете нужно делать в этой ситуации? Сколько-то ядер нужно же попросить.
Чтобы понять соотношение, зайдите в YARN → Scheduler.
Не очень уловил комментарий. UI ярна нужно смотрать, как раз чтобы видеть, сколько выделено на ярн..
берите в 5-10 раз больше памяти, чем занимают ваши данные;
В ежедневной работе мы не читаем все данные за все время в память. Да и в витринах тоже. Обычно считаем по дням или по часам. И это уже можно вместить в память так, чтобы это было 5-10 от общего объема. Если вмещать больше, то люди будут регулятно ловить OutOfMemory. Для аналитика, которому нужно просто получить результат и нет времени оптимизировать запросы, это очень болезненно
Правда если вчитаться, то в тексте по ссылке есть существенное отличие от того, о чем я хотел сказать.
MoSCoW предлагает поделить цели по принципу Парето, отделив условно must have от should have. Я писал про то, что в целом часто не получается сделать ровно те цели, которые ставишь.
Из 10 целей успешно выполняются 6-7, но ты заранее не знаешь какие. Не получается сделать 6 must have, потом взяться за should have.
Вроде бы цель must have, но в процессе выясняется, что ее трудоемкость гораздо выше, чем казалось с самого начала (по той или иной причине). Или ты не успеваешь закрыть предыдущую задачу и не можешь переключить разработчика на новую. А предыдущую на середине бросать тоже нельзя.
Конечно, есть какое-то количество жестких коммитов, где от тебя что-то очень ждут, или от тебя зависят другие команды. Но таких целей должно быть совсем немного, потому что на них нужно перезакладывать ресурсы.
Спасибо за статью. Хочу добавить зачем вообще нужны MFCC.
Как многие знают, алгоритм распознавания — это черный ящик. Что-то на входе, что-то на выходе. На вход идет вектор свойств (feature vector), а на выходе мы получаем решение алгоритма. И в задачах распознавания сложность состоит не самом алгоритме (как было сказано, алгоритмов много и они хорошо изучены), а именно в формировании вектора свойств. Вектор свойств должен быть некоторой фиксированной длины, поэтому напрямую отсчеты сигнала отправить нельзя. К тому же понятно, что по отсчетам напрямую распознать речь очень сложно — варьируется амплитуда, длительность звуков и т.д. Можно было бы отправить в алгоритм спектр. Но тут тоже возникают сложности — частот очень много, по ним сложно отличать звуки, просто каша получается. Кстати, насколько я знаю, в настоящий момент в распознавании речи распространены методы, основанные на вейвлетах, которые характеризуют сигнал и по частоте и по времени.
В общем, теперь вы можете понять, почему были разработаны кепстральные коэффициенты, как некоторый вектор, способный качественно охарактеризовать речь. Кстати, MFCC это лишь один из многих других вариантов feature vector.
IMHO, статья похожа на выполнение плана по статьям.
Про то, как устроен kaggle гораздо лучше прочитать на самом сайте. А чтобы рассказать, что платформа классная, нагляднее всего поделиться опытом участия и решением.
Так просто пандасом паркет из hdfs не прочитать напрямую. В пандасе нет драйвера до hdfs. А по поводу памяти - жестких дисков всегда больше чем оперативной памяти. Если вы готовы прочитать файл в оперативку в пандасе, то и на диск точно сможете соханить
Да, полностью согласен!
А что за задача если не секрет?)
Да, на C много low-level алгоритмов. Но это как правило специальный код, где используются питоновские типы данных. Вот, например, преобразование фурье в numpy. Там его ну никак не отделишь..
Есть библиотеки вроде xgboost или catboost, который написан на cpp и имеют биндинги к нескольким языкам. У них есть версии для JVM. Но это довольно ограниченный набор библиотек
Но также очень много кода (интерфейсного) написано на чистом питоне. И тут вообще никак не отделить
Ну и Spark ML - оч достойный, но узкоспециализированный фрейморк. Он содержит небольшой набор алгоритмов. Популярность не оч высокая. Алгоритмы только параллельные (а не все алгоритмы хорошо параллелятся, поэтому параллелизация дает трейдоффы)
Есть конечно, например, catboost для spark, который мы даже запускали. Но там не все фичи поддерживаются и мы отказались в итоге
Какие-то библиотеки для скалы конечно есть, но по уровню их развития и сообщества несравнимы. Можно сказать, что питоновские либы отлажены на сотнях тысяч если не миллионах пользователей.
Да, полностью согласен. Функциональное программирование изучать не нужно)
Во времена моей работы в Сбере, у нас все продовые витрины были на скале, и на скале писали ноутбуки аналитики из команды витрин. Но все остальные сидели на pySpark.
В Авито же мы сидим только на pySpark, ибо количество людей тут меньше и объем работы на человека больше. Дата инженеров мало. Аналитик сам должен докатить витрину до airflow и даже тесты написать. Нашими инженерами было принято решение дополнительную технологию пока не затаскивать. Хотя смотря на некоторые монструозные питоновские udf я кусаю локти))
Привет! Спасибо за комментарий)
Да, я согласен, что скала для спарка, это несколько процентов от скалы. Я на самом деле тоже оч топлю за скалу. Но порог входа все-таки высокий. Я причем имею выборку из довольно большого количества людей, которые учились писать на спарке, в том числе переходили с питона на скалу. Когда я еще в Сбере работал, мы обучили порядка 50 человек, примерно половина из которых до этого не умела писать на питоне особо даже (sql+excel)
Скала к тому же не покрывает всех задач аналитиков и ds-ов. Обычный пайплайн: собрал витринку, сделал toPandas, строишь графики обычным питоновским стеком, модели обучаешь и тд. Дмитрий Бугайченко я помню активно топил за анализ данных прямо на скале (https://habr.com/ru/companies/vk/articles/442688/ например) и даже в ньюпролабах был такой курс. Но это все-таки не мейнстрим.
Ого, спасибо за инсайт! Очень круто)
Наверное потому что спарк изначально занял нишу продвинутого инструмента. В качестве основного инструмента у нас большая часть аналитиков сидит на вертике. В большинстве других компаний тоже стоит какая-то MPP (massive parallel processing) база, гринплам там или еще что-то. И эти MPP из коробки закрывают очень много всего.
Отличие спарка от MPP баз отдельный вопрос. Но одно из преимуществ спарка - наличие контроля: выделяемых ресурсов, оптимизации, данных, которые в памяти, а которые нет и прочее. За счет этого спарк может решать потенциально более сложные задачи и масштабироваться.
В Сбере нам приходилось использовать хадуп и спарк в первую очередь потому что только он позволял нам построить единое федеративное хранилище на десятки независимых подразделений и тысячи пользователей. Кто поднимал свой гринплам, например, мучался - с трудом забирал и отдавал данные во вне. Хотя с точки зрения пользовательского опыта гринплам гораздо комфортнее спарка.
Прошу прощения, немного не понял все-таки. А можете еще раз более подробно описать логику выбора размера экзекьюторов? Правильно я понял, что через API ярна можно посмотреть сколько доступно ядер на каждой ноде? (я про это не знал, нужно будет разобраться) И исходя из этого выбрать?
Привет! Тоже спасибо за классные каменты!
Валидно.. Тема сохранения достаточно большая и у меня даже есть драфт отдельной статьи на эту тему. Там есть бенчмарки по toPandas с и без arrow оптимизации, а также про скачивания с hdfs. Для теста кстати получилось выгрузить через toPandas датасет в 40Гб (за 5 мин, с arrow оптимизацией)
Вы смотрите с перспективы дата инженера, где вы оптимизируете жесткие расчеты =) Я думаю для аналитика такое не норма. Я пытаюсь донести аналитикам мысль, если данные занимают так много, что не влезают, то нужно считать меньшими кусочками. Или нести задачу дата инженерам. Потому что если аналитик будет регулярно бесконтрольно в ноутбуке запускать жесткие расчеты (а в них скорее всего будут дата спиллы), это будет руинить кластер. У меня такое в практике увы было не раз( Периодически умирал кластер, начинали выяснять, оказывалось, что кто-то регулярно насиловал кластер чем-то очень жестким.
Это правда.. Нужно будет про партиционирование и джойны написать отдельный гайд.
Сейчас я работаю в Авито. В Сбере тоже работал, провел там хорошие 4 года =)
Привет! Спасибо за классные комментарии!
Перед переходом к деталям, нужно наверное отметить идею статьи. Задача - научить работать со спарком именно аналитика, а не дата инженера. Поэтому моя цель была - дать какие-то простые эвристические рекомендации для работы.
Да, про бродкаст я кстати не написал. Для него может быть тоже нужно расширять драйвер. Но не понятно, зачем ограничивать driver.maxResultSize и делать его меньше driver.memory. Нужно понимать, что аналитик делает исследование, пишет код с нуля. Он часто не знает заранее что ему потребуется
Fair комментарий, что непонятно какие ядра и прочее. В статье, на которую я дал ссылку, один человек сделал один тест и верно, что на него нельзя полагаться как на истину. Но тем не менее это референс. Опять же - у аналитика нет возможности запускать один и тот же код 10 раз, чтобы подобрать параметры. Ему нужен какой-то стандартный конфиг.
Про то, чтобы все ядра на ноде занимать, не очень понял.. На ярн потому что выделяется не 100% ядер. По умолчанию две трети вроде. Или вы про то, чтобы доступные ядра делились на количество экзекьюторов? Последнее - хорошая идея. Но там то драйвер, то еще что-то, то кто-то выделит с другим количеством. Не подгадаешь. 16 ядер это конечно немного, мб на них и правда нужно брать поменьше экзекьюторы
А кстати, как вы считаете нужно делать в этой ситуации? Сколько-то ядер нужно же попросить.
Не очень уловил комментарий. UI ярна нужно смотрать, как раз чтобы видеть, сколько выделено на ярн..
В ежедневной работе мы не читаем все данные за все время в память. Да и в витринах тоже. Обычно считаем по дням или по часам. И это уже можно вместить в память так, чтобы это было 5-10 от общего объема. Если вмещать больше, то люди будут регулятно ловить OutOfMemory. Для аналитика, которому нужно просто получить результат и нет времени оптимизировать запросы, это очень болезненно
Интересно, платит ли УИИ налоги?)))
Спасибо, теперь будет на что сослаться)
Правда если вчитаться, то в тексте по ссылке есть существенное отличие от того, о чем я хотел сказать.
MoSCoW предлагает поделить цели по принципу Парето, отделив условно must have от should have. Я писал про то, что в целом часто не получается сделать ровно те цели, которые ставишь.
Из 10 целей успешно выполняются 6-7, но ты заранее не знаешь какие. Не получается сделать 6 must have, потом взяться за should have.
Вроде бы цель must have, но в процессе выясняется, что ее трудоемкость гораздо выше, чем казалось с самого начала (по той или иной причине). Или ты не успеваешь закрыть предыдущую задачу и не можешь переключить разработчика на новую. А предыдущую на середине бросать тоже нельзя.
Конечно, есть какое-то количество жестких коммитов, где от тебя что-то очень ждут, или от тебя зависят другие команды. Но таких целей должно быть совсем немного, потому что на них нужно перезакладывать ресурсы.
Сложно поспорить)
PS. 50 лет в программировании - огонь!! Почитаю ваш блог)))
Как многие знают, алгоритм распознавания — это черный ящик. Что-то на входе, что-то на выходе. На вход идет вектор свойств (feature vector), а на выходе мы получаем решение алгоритма. И в задачах распознавания сложность состоит не самом алгоритме (как было сказано, алгоритмов много и они хорошо изучены), а именно в формировании вектора свойств. Вектор свойств должен быть некоторой фиксированной длины, поэтому напрямую отсчеты сигнала отправить нельзя. К тому же понятно, что по отсчетам напрямую распознать речь очень сложно — варьируется амплитуда, длительность звуков и т.д. Можно было бы отправить в алгоритм спектр. Но тут тоже возникают сложности — частот очень много, по ним сложно отличать звуки, просто каша получается. Кстати, насколько я знаю, в настоящий момент в распознавании речи распространены методы, основанные на вейвлетах, которые характеризуют сигнал и по частоте и по времени.
В общем, теперь вы можете понять, почему были разработаны кепстральные коэффициенты, как некоторый вектор, способный качественно охарактеризовать речь. Кстати, MFCC это лишь один из многих других вариантов feature vector.