Рубикон перейден

Наступил тот момент, когда я понял: пора делиться тем, что я знаю и тем, о чем я узнаю. Поэтому я решил завести канал про дата инженеров.

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

Информация по размещению на канале
Вот тут всякая подробное про канал и размещение https://simonosipov.notion.site/f8e3b889848345bd964e17c124489076

Меня всегда можно найти по адресу @SimonOsipov.

Для начала, немного юмора.

Мне кажется, что вокруг BigData в целом столько хайпа и столько тумана войны одновременно, что очень легко запутаться, что из этого всего вещь полезная, а что - лишь временное явление.
Например, https://pixelastic.github.io/pokemonorbigdata/ - прекрасный сайт, который протестирует вас на знание технологий из стека BigData... или на то, что вы очень много играли в Pokemon GO.

Data Engineer. Восход

Российские локализаторы очень странно перевели название крайнего эпизода Звездных Войн The Rise of Skywalker -> Скайуокер. Восход. Поэтому я тоже не стал заморачиваться на тему названия этой записи.
На просторах интернета была найдена хорошая статья про рост спроса на дата инженеров.

У нее, кстати, есть продолжение. Но об этом в следующий раз..

О тестах замолвите слово

Мне повезло. У моего работодателя - несколько своих кластеров: расчетный, дев-тест и прод k8s, GP и так далее . Поэтому дата-саентисты могут гонять свои модельки туда-сюда сколько угодно раз без каких-либо забот. Я пару раз работал ночью и кластер даже ночью утилизируется минимум на 50%. Зачем задумываться о тестировании своих Spark приложений, если ошибки почти ничего не стоят в каком-то понимании (разве что модель придется заного запустить), а если еще самая тяжелая операция это toPandas(), то... О потерянном времени никто не думает.

Однако если ваши Spark приложения работают в облаке (AWS, Azure, GCP), то каждая ошибка может стоить очень дорого (например, если приложение падает после 10 часов работы). Следующее видео для тех, кому приходится запускать свои приложения в облаках и тех, кто понимает необходимость тестирования. Даже если у вас собственный кластер. Не надо HH и в продакшен


https://www.youtube.com/watch?v=S8CnHieFF28

Вещает Виталий Худобахшов из JetBrains на митапе у Wrike

Data Science Data Engineering is new sexy

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

Ох, сколько раз я слышал про неинтересные задачи, когда дело касается парсинга csv. И тут приходит осознание, что делать это надо, надо автоматизировать рутину, создавать витрины и все вот это. Наступает время искать Дата Инженеров.

Не люблю эту сегрегацию, мол саентисты это элита, а инженеры это обслуживающий персонал. В остальном - отличный выпуск подкаста с Артёмом Пичугиным — Head of Data Programs в Newprolab, в котором говорят про обучение именно таких специалистов, как я.

https://www.youtube.com/watch?v=h45p5JpA6x4



P.S. Ни в коем случае не накидываю на саентистов и аналитиков, отличные ребята, просто цели, задачи и средства достижения их у них другие, поэтому выходит как выходит.

Data Engineer. Падение

Продолжаем традицию дурацких названий. Помните, совсем недавно, я обещал вам продолжение статьи про рост важности позиции Дата Инженеров? Так вот, сдерживаю свое слово и представляю вашему вниманию вторую часть. Тут уже я не поленился и даже ее перевел. Вот о чем там буквально за пару минут:

Скучно и постоянное переключение контекстов
Во-первых, задачи ETL плюс-минус одинаковые и со временем надоедают всем. А во вторых, из-за того, что само исполнение задачи занимает какое-то время, приходится постоянно переключаться между задачами: одну выполняет компьютер, другую кодишь ты. Это изматывает.

Согласие во всем
Бывало у вас такое, есть три команы, каждая из которых собрала себе витрину одной и той же сущности, и у всех разные результаты? В моей работе так постоянно. В средних и крупных компаниях достижение "Единой точки правды" практически невозможно, ведь слишком много мнений на то, как и что нужно считать. В итоге, в компании появляется такое явление, как data silo. Это когда каждая команда или отдел создают свои базы данных, самостоятельно их наполняют и не делятся с остальными. Это одна из сложнейших проблем инженеров данных и ее решение требует существенных сдвигов в мышлении у команд и департаментов в целом.

Мы не попали на лодку Devops
Современный Data Engineering штука довольно дорогая и крайне чуствительная к ошибкам. Поэтому когда весь мир побежал внедрять практики devops, мы не потащили свой багаж туда, ибо очень дорого. А теперь расхлебываем, ибо почти все изменения в pipeline upstream (хрен переведешь адекватно) приводят к ошибкам и тому, что пайплайн останавливается.

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

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

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


С оригиналом можно ознакомиться здесь:
https://medium.com/@maximebeauchemin/the-downfall-of-the-data-engineer-5bfb701e5d6b

Минутка юмора

История смешная, а ситуация страшная.

За Postgres замолвите слово

https://www.youtube.com/channel/UC0SBGSNmBLrTZIkbN-lJHnw/playlists

Тут ребята с канала RuPostgres собрали 350+ видео про Postgres, начиная от основ и простых запросов, заканчивая оптимизацией, шардированием и вот это все. Советую себе сохранить и потихоньку посматривать. Ибо работа с СУБД - один из основных скилов дата инженеров.

Вредные советы. Вступление

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

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

Конечно, желательно это изучить чем раньше, тем лучше. Однако на практике выходит все довольно просто: пока ты не столкнешься с проблемой и в действительности не увидишь, как паттерн или стандартный алгоритм тебе может помочь решить эту проблему - смысла в этом все ты видеть не будешь.
Тоже самое и с "чистым кодом": пока не погрязнешь в рефакторе собственных велосипедов, не начнешь ценить.

Для того, чтобы изучить алгоритмы, есть 3 прекрасные книжки (в порядке возрастания сложности):

1) Грокаем Алгоритмы (Бхаргава)
2) Алгоритмы. Руководство по разработке (Скиена)
3) Алгоритмы. Построение и Анализ (Корман)

А вот чтобы писать "чистый код" нужно делать две вещи:

1) Писать хорошие штуки
2) Не писать плохие штуки (или антипаттерны).

Вот про набор плохих штук и будет эта серия заметок: какие подходы необходимо избегать в своем коде, чтобы потом токсичный душнила-сеньор не зарубил твой код на code-review. Погнали!

Вредные советы. 1. Доступ к защищенному аттрибуту извне

Что не так?
Если мы пытаемся получить доступ к защищенному аттрибуту (аттрибут с префиксом _) класса не внутри класса, обычно это фигня выходит, потому что тот, кто писал класс явно указал, что не хочет выставлять наружу данный аттрибут, поставив ему _ префиксом. Не, если вы попытаетесь к нему обратиться или изменить, у вас это получится, но так делать не надо.

Кстати, если использовать __ (double underscore, двойное подчеркивание), то уже просто к аттрибуту обратиться не получиться, ибо произойдет такая штука, как name mangling.

Антипаттерн

class Rectangle(object):
    def __init__(self, width, height):
        self._width = width
        self._height = height

r = Rectangle(5, 6)

print(f"Width: {r._width}")

А как надо?
Если вы прям уверены, что вам нужно обращаться к защищенному аттрибуту класса, делайте следующее:
1) Убедитесь, что это не приводит к неожиданным результатам далее
2) Рефакторьте код так, чтобы этот аттрибут стал частью публичного интерфейса класса

#вредныесоветы

Вредные советы. 2. Не пихайте лямбду в переменные

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

- У нас есть проблема..
- Ее можно решить с помощью регулярных выражений!
- У нас есть две проблемы...

Основное преимущество лямбда-выражений над созданием отдельной функции это возможность просто их встроить в "большее" выражение. А вот сохранять лямбда-выражение в переменную не надо, для этого используем def определение функций.

Антипаттерн

f = lambda x: 2*x

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

А как надо?

def f(x):
    return 2 * x

В этом случае имя результирующей функции именно f, а не дженерик <lambda>. В этом случае и дебажить проще будет, и один функционал не подменяется другим.


#вредныесоветы