Привет, меня зовут Дмитрий. Я работаю Data Engineer и веду блог по Data Engineering. Хочу поделиться наблюдением, которое сам довольно болезненно проживал в начале и которое до сих пор часто вижу у тех, кто пытается зайти в DE.
Очень многим кажется, что маршрут здесь довольно прямой: выучил SQL, потом начал Python, дальше потихоньку добираешь стек и заходишь в профессию. На бумаге это звучит логично. На практике именно на этом месте люди часто и застревают. Причём застревают надолго. Они уже не новички в чистом виде, что-то знают, какие-то задачи решают, но внутри всё равно нет ощущения, что они готовы к нормальной работе дата-инженера.
И проблема здесь обычно не в том, что человек ленивый или “недоучил ещё пару тем”. Проблема в том, что SQL и Python сами по себе не собирают профессию. Они дают опору, но не дают понимания того, как живёт весь контур данных.
Где это стало очевидно для меня
У меня Python начал нормально вставать на место тогда, когда появилась первая рабочая задача: на основе готовых SQL-скриптов нужно было генерировать файл и подготавливать JSON для релизов. До этого он ощущался как обязательная вещь “на вырост”: да, надо учить, да, пригодится, да, без него дальше будет тяжело. Но только реальная задача показала мне его нормальную роль в процессе.
И именно в этот момент стало очень заметно, что одного SQL и начального Python всё равно не хватает. Не потому что мало синтаксиса выучено. А потому что сама работа дата-инженера устроена шире. Ты можешь написать запрос. Можешь что-то собрать на Python. Но это ещё не значит, что ты понимаешь, как данные проходят путь от источника до витрины и где расчёт может начать разваливаться.
Где начинается настоящий разрыв
Сильнее всего я это почувствовал уже на первой работе в роли Data Engineer, когда пришлось разбираться с полноценным end-to-end pipeline. Данные забирались с источника, дальше шли трансформации в Spark, результат писался в HDFS, потом эти данные нужно было нормально приносить в Greenplum, а уже поверх этого слоя строились view, из которых BI забирал данные для отчётов.
И вот в таком контуре очень быстро понимаешь неприятную вещь: отдельных знаний по SQL и Python недостаточно не в том смысле, что они “слабые”, а в том смысле, что они не дают тебе целой картины. А без неё ты постоянно идёшь на ощупь.
Ты вроде бы понимаешь запрос, понимаешь код, но ещё не держишь в голове маршрут данных: откуда они пришли, где поменялась гранулярность, где что-то почистилось, где слой собрался не так, где нужен пересчёт за день, где за историю, где должны появиться проверки качества, и как это всё потом должно жить без ручного контроля.
Вот это и есть тот кусок, на котором многие буксуют.
Что меня выбивало больше всего
Меня тогда сильнее всего выбивали Spark-трансформации и тот кусок, где после записи нужно было правильно приносить данные в Greenplum. Работа внутри самого Greenplum ощущалась понятнее, потому что там уже знакомая SQL-логика: таблицы, view, понятный слой работы. А вот всё, что происходило до этого, уже требовало другого мышления.
Со Spark я разбирался долго не потому, что там какой-то запредельный порог входа. Основная сложность была в том, что нужно было перестроить голову. Пока ты живёшь в локальной логике “вот запрос -> вот результат”, тебе кажется, что ты контролируешь расчёт. Когда заходишь в реальный пайплайн, оказывается, что расчёт — это только один кусок. Дальше есть запись, следующий слой, оркестрация, качество данных, использование результата другими системами, и если ты этого не видишь, ты всё время работаешь только с фрагментом, а не с целым контуром.
Почему люди с SQL и Python всё равно застревают
Сейчас я часто вижу одну и ту же историю. Человек уже знает SQL, уже трогал Python, и дальше у него начинается гонка за технологиями. Он думает, что сейчас надо срочно глубже в Python, обязательно pandas, ещё несколько библиотек, ещё сверху Spark, Airflow, Hive, Docker, и тогда, наверное, картина наконец сложится.
Обычно не складывается.
Потому что проблема чаще не в количестве технологий. Проблема в отсутствии маршрута. У человека в голове лежат куски, но они не собираются в систему. Из-за этого он всё время чувствует, что как будто идёт правильно, но на самом деле стоит на месте. Чем больше таких разрозненных кусков, тем сильнее ощущение, что профессия расползается в стороны.
На старте полезнее обычно не это, а гораздо более приземлённые вещи: писать аккуратно и в SQL, и в Python, уметь видеть повторяющуюся логику, автоматизировать расчёт, понимать, какие данные у тебя на входе, куда они потом идут, какая у них гранулярность, где ты можешь потерять строки, где должен появиться data quality, и как сделать так, чтобы всё это жило не на ручных действиях, а как нормальный воспроизводимый процесс.
И вот здесь у многих обнаруживается главный разрыв. Они учат инструменты, но ещё не учатся мыслить расчётом как системой.
Что для меня значит готовность к DE
Для меня готовность к Data Engineering давно уже не сводится к формуле “я знаю SQL и Python”. Намного важнее, начинает ли человек видеть данные и расчёт целиком. Понимает ли он, что приходит на вход, в каком месте меняется гранулярность, где у него логика по слоям, где нужны проверки качества, где нужен пересчёт, как всё это будет запускаться, где результат будут использовать дальше, и что будет, если какой-то кусок в этой цепочке даст кривой выход.
В какой-то момент я для себя очень чётко понял, что инженерный подход начинается там, где ты перестаёшь думать только про “как написать расчёт” и начинаешь думать про то, “как сделать этот расчёт устойчивым”. Как убрать лишнюю ручную работу. Как не зависеть от случайной проверки глазами. Как сделать так, чтобы слой нормально жил дальше. Как не собирать всё на честном слове.
И вот с этого места SQL и Python наконец становятся тем, чем должны быть: рабочими инструментами внутри одного контура, а не отдельными галочками в списке “что я уже выучил”.
Почему нужен не список тем, а маршрут
Мне кажется, именно поэтому так много людей и зависают в промежуточной точке. Они уже не с нуля, у них правда есть база, они могут решать отдельные задачи, но при этом внутри всё равно нет ощущения опоры. И в такой момент очень легко пойти по ложной траектории: ещё один курс, ещё одна библиотека, ещё одна подборка тем, ещё один чек-лист “что должен знать DE”.
А помогает обычно не это. Помогает собранный маршрут, по которому видно, как знания начинают вставать на свои места. Где источник, где слои DWH, где трансформации, где Spark job, где проверки качества, где оркестрация, где витрина, где финальный результат. Когда это начинает собираться в одну картину, становится резко спокойнее. Уже нет ощущения, что ты хаотично хватаешь куски. Появляется понимание, зачем тебе каждый следующий инструмент и в какое место он встраивается.
Если вы сейчас в этой точке
Если у вас уже есть SQL, Python понемногу идёт, а Data Engineering всё ещё кажется слишком широким, тяжёлым и немного хаотичным, это нормальная история. У меня этот этап тоже был. И чаще всего здесь не нужен ещё один случайный список тем. Здесь нужнее нормальный маршрут, по которому можно пройти руками и постепенно собрать всю картину.
Я пишу про такие вещи у себя в блоге по Data Engineering: про SQL, Spark, пайплайны, витрины, собесы и реальные рабочие кейсы. Если вам это близко, присоединяйтесь: https://t.me/kuzmin_dmitry91.
А если база по SQL и Python уже есть, но всё это пока не собирается в цельный контур, у меня есть практикум, где мы как раз проходим этот путь руками: от источника данных и слоёв DWH до Spark job, качества данных, оркестрации и витрин. Он не убирает необходимость думать и практиковаться, но сильно помогает в тот момент, когда отдельные знания уже есть, а цельной системы в голове пока нет: https://kuzmin-dmitry.ru/de_practicum.