Проблеми TypeScript у світі React-додатків вiд Iллi Климова на React fwdays | 27 березня
×Закрыть

Какое из направлений Big Data выбрать?

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

Вопрос касаемо трех(четырех) направлений

1) Дата Инженер
2) Дата аналитик(сайентист)
3) ETL разработчик

Хочу окунуться в мир Биг даты, но не знаю что конкретно выбрать, т.к. по тех. части пока нет конкретного мнения о том, что именно мне ближе. Есть ли тут разбирающиеся люди, которые парой предложений могут расписать плюсы и минусы и конкретные отличия всех трех направлений?

Интересует — Актуальность, спрос, уровень входа, уровень зп и т.д.

Некоторые советовали именно третий вариант, что скажете вы?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Под дата инженером может подразумеваться все, что угодно, хоть бигдаты, хоть ETL на ораклах. Нужно смотреть стек, и оттуда уже плясать.

ETL-разработчик — хорошее дело. Непыльное, медитативное, работа всегда есть (ну, на западе так точно). Платят не прям чтобы миллионы, но и не совсем дно.

Из минусов:
— работа только в средних и больших энтерпрайзах, где есть много БД, из которых нужно сводить данные воедино. В стартапах работы почти нет — сводить еще нечего, если только это не стартап про именно данные.
— редко видишь результаты своей работы (если сам не делаешь аналитику, конечно)
— работа довольно монотонная и однообразная (хотя где она не такая?)
— если хочется именно в бигдату, то ETL — это довольно окольный путь
— много энтерпрайза со всеми его минусами (жуткие процессы, бюрократия, всем на все насрать)

Из плюсов:
— ETL редко входит в core business, и большая часть их идет не в реальном времени, поэтому обрушение прода не такое нервное, как если бы упало основное приложение или его среда. Ну подтянутся данные не через четыре часа, а через восемь, делов.
— Погружение в бизнес и в домен (не зная, о чем данные, вменяемый пайплайн не напишешь)
— есть, куда расти (архитектура, продуктовые всякие роли, роли, завязанные на домен)
— много БД, ня!
— много энтерпрайза со всеми его плюсами (хорошие зарплаты, можно затаиться и не отсвечивать, всем на все насрать)

Уровень входа... Не очень низкий, наверное. У меня где-то полгода на самостоятельное изучение архитектур, паттернов и ETL-тулзов, SQL, проектирование БД, перекатывалась из фулл-стека. С нуля даже не знаю.

— ETL редко входит в core business, и большая часть их идет не в реальном времени, поэтому обрушение прода не такое нервное, как если бы упало основное приложение или его среда.

Задача:
В пн начинается цикл годовых отчетов.
В ср запускают конвертацию данных
в пт она падает, потому что 7 месяцев назад приложение писало в течении недели-двух в каком-то битом формате.
Вопрос:
У кого будут веселые выходные? :)

годовых отчетов

Раз на рік, пфф, всіх би проблем

А разве перед тем как агрегировать данные их не чистят перед этим? На нашем проекте все эти рипортики со скорингом выполнялись уже на очищенных и отпирошаенных на 146% данных.

А если эта очистка и прочие манипуляции идут потоком в кафка-стримс еле еще кудой и нацепляны метрики и стреляют алерты, что какие-то сообщения не обработались за вменяемое время, то все становится изрядно занимательнее

У нас был запилена возможность стопать процесинг и возобновлять с упавшего/паузы места, работало норм, хоть и не совсем всегда, в проблемных случаях приходилось хорошенько повозиться чтобы распутать клубок и не запорость консистентность данных. Без кафки и облаков, свои сервера у кастомера.
Собственно, имхо конечно, но если вы не можете гарантииовать консистентность данных в процесе итл, то это вообще анархия и пздос и постоянные перегоных упавших данных, туда сюда, без понимания баг это или нет, хуже того, легко запороть чистые данные, у нас один прогон мог занять больше суток. Ошибки в структуре/схеме данных значили много ручной работы у всяких офисных работников, которые висели на телефонах, это влетало в серьезную копеечку и срачи с кастомером нашего кастомера :-)

Для консистентности данных на разных этапах у нас было море тестов, в том числе и на скл стороне.

Халва аллаху все попроще и в общем то таки скучно)
Ну бывают приколы, что со стороны пришла цена со 100500 знаков после запятой и в NUMERIC не влезает, подшаманил чуток и процесс пошел дальше.

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

У нас система такое детектила на раз два, там целый мешок экшенов был чтобы чистить рукописные ошибки, разные форматы из документов/писулек из разных организаций и при этом вычислять что вот эти данные уже у нас есть не смотря на все ошибки и булщит, или понять что надо проапдейтить эти данные.
Потом поверх уже всего делались расчеты, скоринги и прочие штуки.

Собственно акцент делался не на выжимании наносекунд и упаси господь простоя, чтобы остальная система не слягла, а на том чтобы машина могла гарантировать очень точный результат обработки большого количества грязных данных, чтобы не делать это руками, ибо руками там просто тьму сотрудников надо и очень много времени, да и тупят люди знатно. Если данные не гарнатировали точность то все рипорты и скоринги просто мусор.

Цепляй тайтл дата-инженегра)

Да я вот уже тоже думаю ))) Собственно как я вижу, так делают и у нас и за бугром, без заморочек.

Раз в год конвертация данных для отчетов — это не типичный ETL, это какая-то разовая конвертация данных для отчетов.

Типичный ETL — это как раз очистка, пидорашенье, сведение и иногда агрегация данных (очень часто в лучшем случае вчерашних) на ежедневной основе. Для аналитики там, или для чего еще.

И отчеты — это очень важно, конечно, и очень плохо, если они падают, но обычно никто не умирает и не несет миллионных убытков, если они приходят на день позже. Это не отказ core banking или сервиса заказа билетов, а всего лишь отказ вторичного приложения. Так что чиним в понедельник, без овертаймов.

Хорошо написано, чуток развить мысль и будет отличная полноценная статья.

Может кто-то объяснить, почему везде и на всё натягивают Питон?
Есть ли шанс просунуться куда-то, со Скалой, например? Только не сразу на позицию сеньора с 5 годами опыта)

Может кто-то объяснить, почему везде и на всё натягивают Питон?

На нем море туториалов для всего. Копипастишь туториал и ты сделал работу. Быстро и дешево.

А как насчёт эффективности/производительности?

Я же написал, разработка быстрая и дешевая и понимать того, что делаешь не нужно. Туториалы обычно на гугл колабе или подобном лежат.
Про другое не вспоминал, чтобы срач не провоцировать.

Хочешь понять удовольствие от Питона для чего-то серьезного. Просто заюзай С либу из питона.
Но для прототипов и набросков чего он отличен.

А как насчёт эффективности/производительности?

1) местами писпарк работает быстрее
2) в бигдате узкое место — это ИО и скедулинг задач, а не вычисления в которых имеет значение питон или скала/джава.

1) я могу представить только случай кривой увязки библиотек или преднамеренной python-to-python связи. Других причин, особенно в эпоху apache arrow, почему pyspak быстрее spark scala api я не могу увидеть. Что в вашем опыте такое — расскажите ?

2) при прочих равных я бы не забывал сериализацию. Насколько я вижу только бинарные (аля protobuf) и бесшовные (arrow) подходы позволяют утверждать, что нет разницы между python & scala api’s

Других причин, особенно в эпоху apache arrow, почему pyspak быстрее spark scala api я не могу увидеть

А что меняет арров в контексте питон или скала для скриптинга?
Снова же у арров на наших данных был больше размер и тогда афина не работала с арров на прямую.

при прочих равных я бы не забывал сериализацию. Насколько я вижу только бинарные (аля protobuf) и бесшовные (arrow) подходы позволяют утверждать, что нет разницы между python & scala api’s

В том случае было: читаем CSV, пишем parquet. На сколько я помню, то потом ребята нашли что проблемы были в UDF.

Цикл «накидати якийсь експеримент — отримати результат — зрозуміти, що він абсолютно нічого тобі не дав» на пітоні швидший, ніж з будь-чим іншим.

на нашем рынке намного больше дата инженеров с python, чем со scala, на порядок. это в свою очередь влияет на выбор языка api для того же spark. вопрос производительности во многих случаях уже вторичен (к тому же если используется data frame api, а не rdd — то и разница особо не ощутима)

Зверни увагу на DevOps, MLOps, cloud computing: AWS, Azure.

Направления совсем разные. Вкратце о каждом:
1. дата-сатанист — говорит что строит мат. модели на Python, на самом деле в основном чистит данные. Трактор без PhD не заводится.
2. ETL-разработчик — 90% времени пишет SQL для Оракла или чего-то подобного. Оставшиеся 10% кликает в UI чтобы настроить ETL-пайплайны.
3. дата-инженер — термин размытый, означает «не [только] программист». Работает с чем придется: где-то со Spark, а где-то и в Excel.

Судя по постановке вопроса — бэкграунда нет ни в чем, так что выбирайте что больше нравится.
Например, JS.

Тут же полезная статья вышла
dou.ua/...​umns/about-data-engineer
Или не проезная?

Идеальная для пояснения, чем занимаются в бигдатах — рисуют красивые картинки ни о чем и пытаются разводить лохов на бабки. У единиц получается — остальные пролетают мимо бабок.

чем занимаются в бигдатах — рисуют красивые картинки ни о чем и пытаются разводить лохов на бабки

Бабки — это про менеджмент.
В случае разработчика, бигдата — это код который нормально не оттестируеш (например, потому что данные окажутся «битыми»), и проблема вылезет после дней работы программы (прям как деды рассказывали в универе :) )

Код, который никому не нужен, кроме это твоего менеджера тестировать не нужно. Он все одно лоху втюхивает его.

Код, который никому не нужен, кроме это твоего менеджера тестировать не нужно.

То есть в вашем мире данные сами переезжают между площадками, а в екселе можно посчитать любую аналитику по любым объемам данных (за вменяемое время)?

А бигдата тут причем?
Любую по любым посчитать нельзя, вот просто нельзя.

А бигдата тут причем?
Любую по любым посчитать нельзя, вот просто нельзя.

Биндата — это как раз про то чтобы сделать из «любых данных», те по которым можно посчитать аналитику за вменяемое время (часто средствами технологий, которые включены в бигдата стеки).

Главное, что это можно рекламировать и втюхивать.

Дело в том что на таких проектах заказчик сам толком не понимает когда оно работает правильно или не правильно, в итоге колхозят как показалось. Если с формошлепством какбы ясно и наглядно выглядит результат, то с этим очень тяжело становится.
Я как-то работал на подобном. :-)

Чаще всего он даже не понимает чего хочет. Точнее понимает на уровне «хочу бигдату» и не более.

Вопрос касаемо трех(четырех) направлений

1) Дата Инженер
2) Дата аналитик(сайентист)
3) ETL разработчик

А вы понимаете разницу между этими «направлениями»?

Одно что стоит немного особняком — это датасайнс, поскольку требует больше мат образования, чем понимания бигдаты, но это тоже условность и зависит от того кто как что называет.

Некоторые советовали именно третий вариант, что скажете вы?

Если вы джун, то во всех направлениях вы начнете с этого (даже в датасайнсе, вам скорее дадут сначала «подготовку данных»).

Надежнее начать с анализа вакансий (скорее всего там выплывут СКЛ, Спарк, Амазон) и потом уже развиваться в том контексте куда попадете на первую работу.

UPD.
С ЕЛТями есть хитрая штука: всякие Информатики и тд не факт что дадут буст для развития в БигДате.

Я например с бешеным удовольствием, если позвольте конечно.

А ты после этого меня в стажёры возьмёшь))

Подписаться на комментарии