Data Engineer

Думаю, что многие сталкивались с подобным, очень полезное видео, вне зависимости от вашей профессии. https://youtu.be/BJ_tLZBe_wk

А теперь подведем итоги 1️⃣ DataOps является очень важным инструментом в управлении данными и должен внедряться на самых ранних стадиях проекта. «Правильные вещи нужно делать как можно раньше» (Мартин Клеппман, но это не точно) 2️⃣ На мой взгляд, DataOps — это не отдельная профессия, а еще один инструмент в арсенале инженера данных. 3️⃣ Понимание DataOps — очень важно для начинающих инженеров. Тут как с плаванием - переучивать, говорят, гораздо сложнее, чем учиться с нуля. А значит, возникает необходимость изучения систем контроля версий и контейнеризации (Git и Docker) на самом старте карьеры. 4️⃣ Ограничение DataOps заключается в том, что это односторонний подход, основанный на минимизации рисков, направленный только на одного участника жизненного цикла данных — дата-команду. DataOps позволяет ей спать относительно спокойно, зная, что в зоне ее ответственности все под контролем, но не спасает от очень плохих данных в источниках и неадекватных потребителей. Здесь нужно «кое-что абсолютно другое». The END #DataOps

А теперь переходим непосредственно к DataOps. Суть его сводится к семи простым пунктам 1️⃣ Проверяйте качество данных на каждом шаге потока данных. 2️⃣ Используйте системы контроля версий 3️⃣ Всю разработку ведите в отдельных ветках системы контроля версий и сливайте в основную после ревью, тестов и т. д. 4️⃣ Используйте различные среды для разработки, тестирования и всего остального. 5️⃣ Для каждого шага потока данных создавайте типизированные решения, которые могут быть затем переиспользованы в похожих случаях. Используйте контейнеры. Код, помещенный в контейнер проще переносить между различными средами, кроме того, нет необходимости разбираться с набором инструментов внутри контейнера, достаточно научиться работать с контейнерами. 6️⃣ Параметризируйте свой поток данных, чтобы была возможность запускать поток в различных средах, для различных источников данных, наборов данных и т.д. 7️⃣ Сочетайте ценностный и инновационый подходы. Здесь имеется в виду, что должно существовать 2 различных по сути потока данных: основной, тот который приносит компании пользу здесь и сейчас, и инновационный — идеи, гипотезы, прототипы, то есть то, что направлено на развитие работы с данными и что возможно будет встроено в текущий поток. Несложно же?😁 Продолжение следует... #DataOps

Для борьбы с вышеперечисленными проблемами существует два простых, очевидных и широко распространенных решения, тем не менее почти никогда правильно не работающих. 🔴 "Нам нужно больше ресурсов," - решает какой-нибудь высокоэффективный менеджер. И компания начинает лихорадочно закупать оборудование, искать новые инструменты, которые только усиливают хаос вокруг. 🔴 "Нам нужно больше людей," - вторит ему другой, не менее эффективный (в общем-то, многие современные управленческие подходы сводят п.2 к п.1, но моя религия не позволяет относиться к людям как к ресурсам). Подбор ведется бессистемно, часто по принципу “возьмем всех лучших с рынка или кого сможем взять”. Встраиванием новичков в команду никто не занимается, так как все заняты “тушением пожаров”. Часто даже задачи поставить некому. В результате получается, что часть сотрудников сильно перегружена, часть страдает от безделья. Продолжение следует... #DataOps

Наверное многие видели мем, который называется - The SQL Iceberg. Энтузиасты решили разобрать каждый уровень этого мема на примере PostgreSQL. Получилась такая шпаргалка на основе мема в которой кратко рассказывают про основные термины. Получилось круто 🔥 тык

4️⃣ «Слабоумие и отвага» (Hope and Heroism в оригинале) Вышеперечисленные проблемы порождают еще одну: дата-команда живет в режиме «тушения пожаров», где каждый «потушенный пожар» порождает несколько новых. Такой вот рекурсивный common table expression без условия для прекращения. Очевидно, что в подобном случае дата-команда должна состоять из супергероев, «спешащих на помощь» и появляющихся «только свистни». Однако «чудеса на виражах» случаются только в диснеевских мультфильмах. Жизнь же больше напоминает легенду о Данко Максима Горького. Супергерои быстро выгорают, увольняются, а то и «обнаруживают себя уличными художниками в Амстердаме». Ситуацию усугубляют соблазны сделать побыстрее, отказавшись от таких тормозящих ход дела процессов, как тестирование и проверка качества данных. Думаю, что финал очевиден. Закончить рассказ о проблемах хотелось бы в духе «магазинов на диване»: «Вы устали? Все плохо? Выхода нет? Не спешите с выводами, попробуйте наш чудесный подход всего за 99,99$...» Продолжение следует... #DataOps

3️⃣ Недостаточная автоматизация Мне каждый раз сложно поверить, но это так. До сих пор существуют компании, даже крупные, в которых дата-процессы выстроены следующим образом: утром, придя на работу, аналитик неспешно наливает себе чашечку кофе, включает ноутбук и по очереди начинает запускать скрипты, извлекающие данные из источников, очищающие и обогащающие их, открывает excel-файл с отчетом, копирует в него полученные данные и отправляет по электронной почте заинтересованным лицам. Подход вполне рабочий, но, очевидно, не лишен недостатков: он чреват ошибками, есть вероятность пропустить одну из стадий или даже все в случае невыхода ответственного лица. Вот другой случай. Запуск скриптов автоматизирован, но изменения в них накатываются в продуктовой среде специально обученным администратором баз данных, которому лень проверять, что там аналитик “наваял”, даже запустить лишний раз лень. “Шеф, все пропало, отчет не работает, аналитик уехал в отпуск,” - сказали бы герои легендарной комедии Леонида Гайдая. И даже если в своем марафонском забеге по граблям компания смогла достичь финишной черты, перерасти уровень предыдущего абзаца, узнав о существовании CI/CD, проверки качества данных часто проводятся в ручном режиме. О наличии ошибок в отчетах заинтересованные лица в таком случае узнают непосредственно при открытии отчета, что опять же плохо сказывается на рабочих отношениях. Продолжение следует... #DataOps

2️⃣ Данные хранятся в различных изолированных источниках, в разных форматах, часто содержат множество ошибок. Подключение к источникам требует получения доступов, а у ребят из IT-служб задач хватает и без каких-то там аналитиков. Кроме того, для получения данных из разнообразных источников требуется большое количество специалистов, умеющих это делать. Для разработчиков на первом месте стоит их продукт, у них есть задачи и им тоже нет дела до нужд аналитики. «Вот тебе подключение, чем отличается Orders от Orders_new или Orders1, сам разберешься. И вообще, это не моя работа...» Кажется, что качество данных в источнике — забота команды источника, но см. абзац выше. Придется столкнуться с такими артефактами как: тестовые данные, ошибки ввода, результаты багов и т. д. Расстроенные некорректными данными пользователи отчетов придут к вам. Фразы типа «это все источник виноват», не вызовут у них сочувствия, даже не пытайтесь. Скорее наоборот, подобные попытки приведут к потере доверия. Продолжение следует... #DataOps

Теперь о проблемах, которые был призван устранить DataOps 1️⃣ Требования постоянно меняются. Пользователи не знают, чего хотят. Они не являются дата-экспертами. Они не понимают всех возможностей, пока Вы, как дата-специалист, им их не покажете. Пользователи хотят «все и сразу». Когда у них возникает, какой-то вопрос, невозможно объяснить им, что «для ответа нужно подождать релиз, ближайший будет через 2 недели, при этом далеко не факт, что данная задача в него попадет». Вопросы не закончатся никогда. Данные позволяют взглянуть на проблему под другим углом, а значит, приводят к появлению новых вопросов. И это абсолютно нормально. Вот только, если для решения даже самой простой задачи нужно подождать пару недель, а то и месяцев, отношения между дата-командой и пользователями начнут ухудшаться. Знакомо? Продолжение следует… #DataOps

«Если легок как дым, то таким и не нужен DataOps» (ВИА «АукцЫон») Я давно хотел разобраться с тем, что же из себя представляет DataOps, настолько, что эта тема, кажется, перестала быть актуальной в дата-мире. Опытные инженеры данных уже «любят, умеют, практикуют». И вот, наконец-то, у меня руки дошли до книги «The DataOps CookBook». Начну с определения. DataOps - автоматизированный, процессно-ориентированный подход, независимый от технологий, используемый аналитическими и дата-командами для улучшения качества и сокращения времени цикла аналитики данных. Продолжение следует... #DataOps

Дима Ибрагимов — топовый спец, прекрасно умеющий «готовить» такие популярные опенсорсные продукты, как NiFi или GreenPlum, да и не только их. Кроме того, он отличный докладчик и автор, настоящий дата-адвокат. Даже странно, что я пропустил его статью о мониторинге производительности GreenPlum. Публикация не для новичков и даже не совсем для инженеров данных. Тем не менее, считаю, что в вакууме работать невозможно и время «чистых» специалистов прошло, как в футболе прошло время фланговых нападающих и плеймейкеров, а значит, погружение в смежные профессии хотя бы на базовом уровне сейчас — must have. Статья для вас, если Вы хотите узнать ➖Что такое Observability-подход и как его применять при использовании GreenPlum ➖Какие метрики нужно отслеживать, чтобы SRE-инженер ночью спал спокойно, и какие средства для этого применяются ➖Какие алерты полезно реализовать С нетерпением жду новых статей и докладов от Димы😃 Как следить за здоровьем GreenPlum

Собственно то, чего уже давно пора было сделать. Немного переработанные материалы из канала про дата-профессии. Надеюсь, что я все-таки смогу завершить этот сериал😀 https://vc.ru/u/2214539-mathshub/798375-garri-potter-i-bolshie-dannye

Кажется, пришло время выходить из межсезонья, плавно возобновлять тренировочный процесс и двигаться дальше в выбранном направлении😁

⏺Прямой эфир Mathshub и Андрей Ларионов Андрей — эксперт и преподаватель Mathshub. Более 15 лет работы с данными, архитектор аналитических систем с опытом в крупных компаниях — KupiVIP, Связной, Леруа Мерлен. Приглашаем вас на встречу, где обсудим, как начинающим развиваться в сфере науки о данных. Спикер поделится своей историей, расскажет о различиях в дата-профессиях и самых необходимых навыках для любого дата-специалиста. Когда: 12 июля в 19:00, в Telegram-канале Mathshub. Пишите вопросы Андрею под этим постом ⬇️

Запомните мудрость. То, что страшно релизнуть в пятницу вечером, релизить вообще нельзя.©

Привет 🖐 Исходя из их популярности, вот несколько книг о программировании, которые могут оказаться для вас полезными: 👉 «Чистый код: руководство по Agile-мастерству разработки программного обеспечения» Роберта К. Мартина. 👉 «Прагматичный программист: от подмастерья до мастера» Эндрю Ханта и Дэвида Томаса. 👉 «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса. 👉 «Code Complete: Практическое руководство по созданию программного обеспечения» Стива МакКоннелла. Эти книги содержат информацию о лучших практиках, шаблонах проектирования и принципах, которые помогут вам улучшить свои навыки программирования и создавать высококачественное программное обеспечение. #книганавечер

Пятничное настроение🤣