Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Какое из направлений 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.
С ЕЛТями есть хитрая штука: всякие Информатики и тд не факт что дадут буст для развития в БигДате.

Могу взять стажёром

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

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

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