Привет 🖐

Исходя из их популярности, вот несколько книг о программировании, которые могут оказаться для вас полезными:

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

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

#книганавечер

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

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

Собственно то, чего уже давно пора было сделать. Немного переработанные материалы из канала про дата-профессии. Надеюсь, что я все-таки смогу завершить этот сериал😀

https://vc.ru/u/2214539-mathshub/798375-garri-potter-i-bolshie-dannye

Дима Ибрагимов — топовый спец, прекрасно умеющий «готовить» такие популярные опенсорсные продукты, как NiFi или GreenPlum, да и не только их. Кроме того, он отличный докладчик и автор, настоящий дата-адвокат. Даже странно, что я пропустил его статью о мониторинге производительности GreenPlum.

Публикация не для новичков и даже не совсем для инженеров данных. Тем не менее, считаю, что в вакууме работать невозможно и время «чистых» специалистов прошло, как в футболе прошло время фланговых нападающих и плеймейкеров, а значит, погружение в смежные профессии хотя бы на базовом уровне сейчас — must have.

Статья для вас, если Вы хотите узнать
➖Что такое Observability-подход и как его применять при использовании GreenPlum
➖Какие метрики нужно отслеживать, чтобы SRE-инженер ночью спал спокойно, и какие средства для этого применяются
➖Какие алерты полезно реализовать

С нетерпением жду новых статей и докладов от Димы😃

Как следить за здоровьем GreenPlum

«Если легок как дым, то таким и не нужен DataOps» (ВИА «АукцЫон»)

Я давно хотел разобраться с тем, что же из себя представляет DataOps, настолько, что эта тема, кажется, перестала быть актуальной в дата-мире. Опытные инженеры данных уже «любят, умеют, практикуют».

И вот, наконец-то, у меня руки дошли до книги «The DataOps CookBook». Начну с определения.

DataOps - автоматизированный, процессно-ориентированный подход, независимый от технологий, используемый аналитическими и дата-командами для улучшения качества и сокращения времени цикла аналитики данных.

Продолжение следует...
#DataOps

Теперь о проблемах, которые был призван устранить DataOps

1️⃣ Требования постоянно меняются.

Пользователи не знают, чего хотят. Они не являются дата-экспертами. Они не понимают всех возможностей, пока Вы, как дата-специалист, им их не покажете.

Пользователи хотят «все и сразу». Когда у них возникает, какой-то вопрос, невозможно объяснить им, что «для ответа нужно подождать релиз, ближайший будет через 2 недели, при этом далеко не факт, что данная задача в него попадет».

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

Знакомо?

Продолжение следует…
#DataOps

2️⃣ Данные хранятся в различных изолированных источниках, в разных форматах, часто содержат множество ошибок.

Подключение к источникам требует получения доступов, а у ребят из IT-служб задач хватает и без каких-то там аналитиков. Кроме того, для получения данных из разнообразных источников требуется большое количество специалистов, умеющих это делать.

Для разработчиков на первом месте стоит их продукт, у них есть задачи и им тоже нет дела до нужд аналитики. «Вот тебе подключение, чем отличается Orders от Orders_new или Orders1, сам разберешься. И вообще, это не моя работа...»

Кажется, что качество данных в источнике — забота команды источника, но см. абзац выше. Придется столкнуться с такими артефактами как: тестовые данные, ошибки ввода, результаты багов и т. д. Расстроенные некорректными данными пользователи отчетов придут к вам. Фразы типа «это все источник виноват», не вызовут у них сочувствия, даже не пытайтесь. Скорее наоборот, подобные попытки приведут к потере доверия.

Продолжение следует...
#DataOps

3️⃣ Недостаточная автоматизация

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

Вот другой случай. Запуск скриптов автоматизирован, но изменения в них накатываются в продуктовой среде специально обученным администратором баз данных, которому лень проверять, что там аналитик “наваял”, даже запустить лишний раз лень.
“Шеф, все пропало, отчет не работает, аналитик уехал в отпуск,” - сказали бы герои легендарной комедии Леонида Гайдая.

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

Продолжение следует...
#DataOps

4️⃣ «Слабоумие и отвага» (Hope and Heroism в оригинале)

Вышеперечисленные проблемы порождают еще одну: дата-команда живет в режиме «тушения пожаров», где каждый «потушенный пожар» порождает несколько новых. Такой вот рекурсивный common table expression без условия для прекращения.

Очевидно, что в подобном случае дата-команда должна состоять из супергероев, «спешащих на помощь» и появляющихся «только свистни». Однако «чудеса на виражах» случаются только в диснеевских мультфильмах. Жизнь же больше напоминает легенду о Данко Максима Горького. Супергерои быстро выгорают, увольняются, а то и «обнаруживают себя уличными художниками в Амстердаме».

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

Закончить рассказ о проблемах хотелось бы в духе «магазинов на диване»: «Вы устали? Все плохо? Выхода нет? Не спешите с выводами, попробуйте наш чудесный подход всего за 99,99$...»

Продолжение следует...
#DataOps

Наверное многие видели мем, который называется - The SQL Iceberg.

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

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

🔴 "Нам нужно больше ресурсов," - решает какой-нибудь высокоэффективный менеджер. И компания начинает лихорадочно закупать оборудование, искать новые инструменты, которые только усиливают хаос вокруг.

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

Продолжение следует...
#DataOps

А теперь переходим непосредственно к DataOps. Суть его сводится к семи простым пунктам

1️⃣ Проверяйте качество данных на каждом шаге потока данных.

2️⃣ Используйте системы контроля версий

3️⃣ Всю разработку ведите в отдельных ветках системы контроля версий и сливайте в основную после ревью, тестов и т. д.

4️⃣ Используйте различные среды для разработки, тестирования и всего остального.

5️⃣ Для каждого шага потока данных создавайте типизированные решения, которые могут быть затем переиспользованы в похожих случаях. Используйте контейнеры. Код, помещенный в контейнер проще переносить между различными средами, кроме того, нет необходимости разбираться с набором инструментов внутри контейнера, достаточно научиться работать с контейнерами.

6️⃣ Параметризируйте свой поток данных, чтобы была возможность запускать поток в различных средах, для различных источников данных, наборов данных и т.д.

7️⃣ Сочетайте ценностный и инновационый подходы. Здесь имеется в виду, что должно существовать 2 различных по сути потока данных: основной, тот который приносит компании пользу здесь и сейчас, и инновационный — идеи, гипотезы, прототипы, то есть то, что направлено на развитие работы с данными и что возможно будет встроено в текущий поток.

Несложно же?😁

Продолжение следует...
#DataOps

А теперь подведем итоги

1️⃣ DataOps является очень важным инструментом в управлении данными и должен внедряться на самых ранних стадиях проекта. «Правильные вещи нужно делать как можно раньше» (Мартин Клеппман, но это не точно)

2️⃣ На мой взгляд, DataOps — это не отдельная профессия, а еще один инструмент в арсенале инженера данных.

3️⃣ Понимание DataOps — очень важно для начинающих инженеров. Тут как с плаванием - переучивать, говорят, гораздо сложнее, чем учиться с нуля. А значит, возникает необходимость изучения систем контроля версий и контейнеризации (Git и Docker) на самом старте карьеры.

4️⃣ Ограничение DataOps заключается в том, что это односторонний подход, основанный на минимизации рисков, направленный только на одного участника жизненного цикла данных — дата-команду. DataOps позволяет ей спать относительно спокойно, зная, что в зоне ее ответственности все под контролем, но не спасает от очень плохих данных в источниках и неадекватных потребителей. Здесь нужно «кое-что абсолютно другое».

The END
#DataOps

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

Я здесь изложил свой взгляд на DataOps, если же кто-то хочет составить собстенное мнение, книгу «The DataOps CookBook» можно скачать совершенно бесплатно.

Добавлю сюда еще парочку моих самых любимых цитат.

"We believe that the secret to successful data science is a little about tools and a lot about people and processes."

"A single data engineer should be able to support ten data analysts and scientists."

Последняя должна служить метрикой качества управления данными в компании😁

Ссылка на книгу: https://datakitchen.io/the-dataops-cookbook/

#мысливслух

«Если уж решился стать архитектором данных, то надо идти в своем увлечении до конца».

Первое, что нужно сделать — «убить в себе инженера». Гнать от себя подальше подленькие мысли, что сделал бы по-другому. Унять зудящие руки, так и тянущиеся что-нибудь написать, типа: create_dag, select * from big_and_wide_table, а то и drop database.

После чего заняться своими непосредственными задачами.

Ну и о главном😀