Как я ушел с GetCourse и сделал свою обучающую платформу
(ссылка в конце поста)

Раньше регулярно оплачивал GetCourse. В среднем около 5000 рублей в месяц (4000р за тариф, 1000р за хранилище). Это минимальный тариф (до 1000 пользователей), меньше уже некуда.

Идея сделать свою обучающую платформу давно сидела в голове, но раньше казалась слишком сложной - ведь это огромный объём работы (будто бы основной работы мало).

Но когда стало популярным писать код нейросетями, я взглянул на задачу иначе и решил попробовать 💪
Накидал схему базы данных *, прикинул разные кейсы и начал делать проект на любимом Django.

* Вспомнил, что в Karpov Courses на курсах дата-инженера мы именно такую схему и рисовали в конце первого блока - там были курсы, студенты, уроки, итд - не зря учился)))

Заход #1: Replit - AI IDE для простых смертных
Первый и самый простой вариант для старта. Там были разные глюки, странности, не всё работало идеально. Но главное, что это работало. Основа платформы была запущена и видео грузились.

Заход #2: Cursor - AI IDE для разработчиков
Настало время для «более программистского» инструмента. Cursor в мелочах удобнее для программиста, но плевался я от него не меньше. Отладка процесса оплаты потребовала проведения 50+ транзакций, прежде чем всё заработало.

Заход #3: Claude Code - агент для кодинга
И тут уже всё полетело. Переход на Claude Code позволил всё доработать и сделать приемлемым. Устранение ошибок, доработка фичей, настройка той же оплаты — всё пошло в разы быстрее и круче.

Для видео выбрал Kinescope. Нужна была надёжная платформа для хранения и стриминга, а у них отличные условия. Кстати, слышал Kinescope тоже делает один человек:)

Что в итоге получилось?

✅ Стоимость упала в 4 раза: с 5000 ₽ до 1200 ₽ в месяц. Возможно, она вырастет, но всё равно экономия существенна.

✅ Никаких ограничений - если в геткурсе минимальный тариф работает до 1000 юзеров, то тут - разве что не потянут CPU и RAM, других лимитов нет.

✅ Полная кастомизация: Можно добавлять любые фичи, которые придут в голову. Захотел переключатель «презентация/видео» - сделал. Нужны квизы после уроков - пожалуйста. Возможность скрыть или показать список всех уроков - не проблема.

✅ Игровая динамика: Добавил баллы за прохождение уроков и систему грейдов для мотивации. Теперь учиться интереснее:)

Не претендую на инфраструктуру подобную GetCourse, но тот минимальный набор функций, которым я пользовался там, реализовать удалось. И это уже очень неплохо🔥

На платформе уже появились разные курсы, в том числе и сделанные от начала до конца с помощью ИИ, но о курсах расскажу в следующих постах.

Сама платформа тут: https://directprobi.ru/platform/

ОСНОВЫ APACHE AIRFLOW

Ещё когда работал с Power BI, меня всегда интересовал Airflow. Сначала он казался чем-то сложным - миллион настроек, да еще эти питоновские классы и другие нюансы кода, что сходу не разберёшься.

У меня были коллеги, кто гораздо лучше умел его настраивать. Они писали свои кастомные операторы, делали сложную загрузку данных, отчего еще больше казалось, что я вообще ничего не пойму 🙄

Со временем стали понятны несколько вещей:
⚡️ ничего сложного в самом Airflow нет (ну, кроме классов)
⚡️ Airflow - всего лишь оркестратор, он не должен выполнять никакой загрузки данных, только вызывать скрипты
⚡️ вам на самом деле не нужен миллион настроек, хватит примерно десятка (или двух)

Теперь работаю с Airflow каждый день и сделал довольно подробный ролик по его настройке. У многих не работает YouTube, так что смотрите прямо на платформе:
https://directprobi.ru/platform/apache-airflow-osnovy/

Все коннекторы на одном лендинге

Наконец-то структурировал инфу по коннекторам для сбора данных в БД - теперь всё на одной странице.

Все функции для загрузки данных бесплатно выложены на Github. Также есть открытая справка по применению функций с примерами на Python. Всё максимально доступно и понятно, даже нейронка не нужна😊

Это отличный вариант если вы не собираетесь делиться токенами со сторонними компаниями и хотите организовать сбор данных на своём серваке.

Если нужно добавить коннектор к популярному сервису, можно написать мне в личку, думаю смогу с этим помочь.

Вся инфа и ссылки теперь тут: https://directprobi.ru/connectors/

ГОЛОСОВОЕ УПРАВЛЕНИЕ АГЕНТАМИ

Многие видели маску для диктовки промптов, которая позволяет не мешать друг другу в офисе. Я долго вбивал текст руками, пока все пользовались аудио. Пришла пора перестать печатать🎙

Я привык вбивать любой текст руками. Мне казалось, что я печатаю быстро, но на практике скорость речи в 2.5 раза быстрее. Да, точность снижается, но скорость речи = 850 знаков в минуту против 330 знаках при печати.

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

После первого общения с агентами в аудио возникли вопросы: зачем вообще ждать, пока этот микрофон включится? Почему нельзя всё время работать с активно включённым микрофоном? Почему не наговаривать текст в тот же Telegram или прямо в файл, не ограничиваясь Claude Code или Codex?

В Windows есть Win+H, но он требует интернета и не активен постоянно. Да и гибкости ему явно не хватает.

Как всегда - придумываем своё решение 🧠

Распознавание голоса оказалось гораздо проще, чем я ожидал. Не нужно задействовать API и платить деньги. Всё можно сделать на своём компе. С помощью Claude написал небольшую программу на базе Сберовской аудио-модели GigaAM v3 e2e CTC. Теперь прога постоянно крутится локально, слушает мою речь и транслирует в текст. Кстати, этот пост частично написан с помощью аудио.

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

Отдельный кайф - настраиваемая автозамена. Говоришь одно слово, а печатается заранее заготовленная длинная команда.

произносишь "окружение"
-> печатается "source /home/user/venv/bin/activate"🔥

Можно даже повесить на голосовую команду выполнение скрипта: сказал слово - запустилась программа. Звучит как что-то невероятное 😵‍💫

Есть конечно и недочёты: если пишешь пост или важное сообщение, сходу правильно надиктовать почти нереально, придётся править. Хотя и при печати также☺️
По скорости и ресурсам у себя проблем не замечал (на серверах тоже ок), но если ресурсов не хватает, диктовка может подтормаживать.

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

А вы как, уже пользуетесь голосовым промптингом?

CLICKHOUSE: ЧТО ВАЖНО ЗНАТЬ

Записал курс по ClickHouse и собрал самое важное в один пост. Если хотите работать с кликхаусом или собираетесь на собес - очень рекомендую🔥

Получилось 15 уроков, всё максимально структурировано и по делу. Ниже - ключевые моменты, чтобы за пару минут понять суть. А в конце - ссылка на бесплатный курс ⬇️

Что такое ClickHouse 🏠

Колоночная аналитическая СУБД - данные хранятся по столбцам, а не по строкам. Это упрощает сжатие и аналитические запросы, так что Clickhouse считает агрегаты по миллиардам строк за секунды.

Это не замена PostgreSQL, скорее его партнёр - транзакции приходят в OLTP-базу, аналитика собирается в ClickHouse, а между ними работает CDC или ETL-пайплайн.

Почему кликхаус такой быстрый🏄

Он берёт только нужные столбцы, ничего лишнего. Читает не построчно, а гранулами по 8192 строки, считает данные блоками и обрабатывает несколько значений за 1 такт процессора. Однотипные значения в столбце жмутся в 5–20 раз.

Структура хранения 📖

Внутри ClickHouse выстроен так: таблица - партиция - кусок - гранула (8192 строки). Вставки могут происходить и небольшими кусками, но фоновые слияния укрупняют мелкие куски.

Базовый движок хранения - MergeTree, на движках семейства MergeTree обычно хранят основные данные. Есть варианты - ReplacingMergeTree, CollapsingMergeTree и AggregatingMergeTree. На таких движках данные автоматически подменяются, удаляются или агрегируются в фоновом режиме. Для просмотра итогового вида таблицы в запросах используют слово FINAL.

Как правильно делать 🔥

● При создании таблицы задаём ключ сортировки - задаётся по частым фильтрам, от низкой кардинальности к высокой. Это даёт ускорение запросов в разы.

● Партиционирование делают по месяцу, при большом потоке - по дню. Лучше иметь десятки партиций, чем десятки тысяч. Таблицы меньше 10 ГБ можно не партиционировать.

● Данные вставляют батчами по 10–100 тысяч строк, не чаще раза в секунду. Если клиент не умеет вставлять батчами - включаем асинхронную вставку.

● ClickHouse не любит точечные правки. Есть лёгкий UPDATE, но для потока изменений стандарт такой: ReplacingMergeTree и вставка новой версии строки. Дубли схлопнутся при фоновом слиянии, а до него таблицу читают через FINAL.

● Денормализация при вставке, а не соединения при чтении. Справочник до 10 миллионов строк помещается в словарь, его значения подтягиваются в материализованном представлении через dictGet.

● EXPLAIN indexes = 1 SELECT ... показывает, сколько кусков и гранул будет прочитано запросом - сразу понятно надо ли менять ORDER BY.

● system.query_log - журнал выполненных запросов с временем, объёмом чтения и памятью, отдельно проверяем частые запросы.

Как лучше не делать🫣

1) Вставлять часто и по одной строке. Тысяча INSERT за минуту - тысяча кусков и ошибка "too many parts".

2) Менять строки по одной, как в OLTP. Мутация переписывает затронутые столбцы целиком, лёгкий UPDATE дешевле, но тоже не бесплатен.

3) Соединять две большие таблицы: правая целиком собирается в хеш-таблицу в памяти и если она большая - памяти может не хватить.

4) Ставить Nullable без нужды - лишний байт на строку и проверки. Если нет смысла в пустоте - выставляйте значение по умолчанию.

5) Ждать от ClickHouse транзакций, внешних ключей и быстрых точечных запросов по id, особенно если id нет в ключе сортировки. Это не его работа.

Что путают чаще всего🙄

Словарь - справочник в памяти, обращение по ключу за наносекунды, обновляется сам по времени жизни. Лучшая альтернатива JOIN.

Материализованное представление - обычно это триггер на вставку: считает агрегаты на входящем блоке и пишет в целевую таблицу.

PRIMARY KEY - не уникальный столбец, а разреженный индекс: одна отметка на гранулу, поэтому он указывает лишь диапазон, где искать.

Ключевое правило 🧠

ClickHouse блестяще решает задачу «прочитать много данных быстро» и плохо - «изменить одну строку быстро». Это ключевой момент при выборе СУБД и дальнейшей архитектуры таблиц.

Полное погружение в ClickHouse тут: https://directprobi.ru/platform/clickhouse-teoriya/

КТО ТАКОЙ ДАТА-ИНЖЕНЕР

Данные должны быть актуальны, корректны и находиться в нужном месте - именно за это отвечает инженер данных.
Но что за этим кроется?

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

Классическое понимание Data Engineer

Если в компании правильно выстроены процессы, Data Engineer получает задание от системного аналитика, где детально написано, что нужно сделать. Сам инженер данных не принимает решений какую таблицу грузить в базу и какое поле в неё добавить. Всё это приходит в виде системных требований.

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

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

Разный масштаб и команды

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

В небольшой компании дата-инженер может заниматься чем угодно: поиском правильного решения совместно с бизнесом (вместо бизнес-аналитика), составлением системных требований (вместо системного аналитика), тестированием различных решений (вместо тестировщика) и, конечно, анализом данных и созданием BI-систем (вместо дата-аналитика и BI-аналитика). Всё это интересно, но это не работа дата-инженера.

Что по инструментам?

Стек технологий везде разный, но есть ключевые узлы. У вас должен быть оркестратор, чаще всего Airflow, иногда - Dagster. В оркестраторе идёт планирование процессов загрузки данных.

В любой системе есть источник (откуда данные грузятся) и приёмник (куда всё поступает). Тут всегда актуальны Python и SQL. Python - чтобы реализовать саму загрузку данных, SQL - чтобы правильно осуществлять вставки и проверить корректность данных.

Инструментами обработки данных могут быть Spark, DBT, Flink итд. В качестве финальной точки часто используют ClickHouse - на нём удобно делать витрины для UI или BI. Внутри системы можно столкнуться с Postgres, в Postgres обычно хранят транзакционные данные или метаданные. И конечно Kafka - через неё проходят потоковые данные, которые потом обрабатывает Flink или Spark Streaming.

Если компания работает с миллиардами строк, они могут использовать Lakehouse: хранение данных в S3 (Iceberg или Delta Lake). Если компания работает с миллионами строк и данные структурированы, ничего не мешает обходиться обычными Postgres и ClickHouse.

Из чего состоит ежедневная рутина?

Как и везде, вам придётся общаться с коллегами. Это могут быть аналитики, тестировщики или ваш руководитель. Коммуникация в любом случае будет. В моей работе созвоны и встречи обычно занимали ~10% времени.

У вас уйдёт время на разбор системных требований и деталей ТЗ. Это ключевой этап, иногда он занимает даже больше, чем работа с кодом. Сюда же добавим текстовую коммуникацию - нужно написать вопросы и отчитаться о сделанной работе. Текстовая коммуникация тоже занимает свои 10% времени.

Ну и база - работа с кодом. Это и запросы к нейросетям, и разбор проблемных моментов, и само написание кода. Несколько раз столкнувшись с ошибками нейросети в важных запросах или скриптах, вы точно начнёте всё проверять. Так что проверка, тестовый запуск и финальные правки - еще 20% работы перед публикацией в git.

Что примерно выходит по времени:

- речевая коммуникация ~ 10%
- текстовая коммуникация ~ 10%
- разбор требований к задаче ~ 20%
- написание кода ~ 20%
- проверка кода и тесты ~ 20%
- работа с Git (+ ребейзы, конфликты, итд) ~ 10%
- паузы, переключения, орг. моменты ~ 10%

И напоследок

400-500К рублей в месяц - вполне реальные зарплаты для опытного дата-инженера в РФ. Ваша рутина может отличаться от описанной тут. Но, надеюсь, общее понимание у вас появилось.

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

Учиться работе с данными можно долго и это очень увлекательно. Если учесть востребованность и неплохие зарплаты, Data Engineer - одна из самых интересных современных IT-специальностей.

Если заинтересовало - в статье еще больше деталей

СЕКРЕТЫ В КОДЕ: КАК Я ПАЛИЛСЯ И КАК ПЕРЕСТАЛ

Когда-то для меня было нормой держать рабочий пароль к БД прямо в коде. У меня был скрипт на Python, который подключается к базе, и пароль был вписан как обычный текст. Рано или поздно это должно было сыграть против меня.

В то время я регулярно проходил занятия по Python. Мы созванивались с программистом, он показывал мне разные фишки. Все уроки он записывал, чтобы я мог посмотреть и лучше разобраться.

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

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

Как по неопытности не слить свой пароль? Давайте разбираться.

Хорошие практики

Хранение пароля в коде у разработчиков считается типичной плохой практикой. А что же считается хорошей? Вариантов много. Всё зависит от того, где вы работаете, с чем, от чего этот пароль и какая у вас среда. Пробежимся по вариантам.

1. HashiCorp Vault - корпоративный стандарт для хранения паролей и кредов в целом. Внутри простой интерфейс: создается переменная, ей указывается значение. У одних сервисов есть права на просмотр или изменение переменной, у других - нет. Еще Vault умеет генерировать пароли "на лету" и выдавать их на ограниченное время. Если злоумышленник украдет такой пароль, через час он уже истечёт.

2. Переменные окружения. Самый простой и популярный способ. Пароль хранится в настройках операционной системы или в CI/CD-платформе (GitHub Actions, GitLab CI, Jenkins). В коде же мы пишем просто:

import os
password = os.getenv('DB_PASSWORD')

Если переменная не задана - скрипт упадет с ошибкой, но пароль точно не засветится в коде или репозитории.

3. Файл .env - удобно для локальной разработки. В корне проекта создается файл .env, куда записываются все секреты. Сам файл .env всегда добавляется в .gitignore, чтобы он точно не попал в коммит. В репозиторий кладется файл-шаблон .env.example. В нём указаны имена переменных без реальных значений (значения пустые или фейковые). Новый разработчик клонирует репозиторий, создаёт .env из .env.example и вписывает свои пароли локально.

4. Шифрование конфигурационных файлов. Для этого есть Ansible Vault, git-crypt или SOPS. Конфиг с паролями лежит в репозитории, но в зашифрованном виде. Расшифровывается только в момент деплоя с помощью мастер-ключа, который хранится отдельно. Это компромисс между удобством и безопасностью.

5. Подмена на этапе сборки. В некоторых фреймворках (Docker BuildKit, Webpack) можно подставлять секреты только во время сборки образа, не зашивая их внутрь контейнера. Пароль используется для установки зависимостей из приватных репозиториев, а после сборки - удаляется.

Это только 5 базовых способов, а ведь есть еще...
Пока писал пост, понял, что материала получается на целую статью, так что ловите ссылочку если заинтересовались: https://directprobi.ru/blogs/sekrety-v-kode-paroli-tokeny-peremennye-okruzheniya-env-vault/

ТЕОРИЯ APACHE SPARK

Еще до начала работы с большими данными делал видео про Apache Spark (в качестве эксперимента). Это было небольшое обзорное видео, чтобы структурировать и запомнить основные моменты. Тогда еще монтировал всё сам🤗

Позже на работе плотно столкнулся со спарком и вот что понял: Power Query, CTE в SQL и PySpark - очень похожие штуки.

Да, разные движки, разные операции, но:
● везде есть цепочка преобразований (набор шагов последовательных изменений данных),
● вы пишете что нужно сделать, а движок определяет как именно это сделать внутри,
● можно попросить движок кэшировать этап если он нужен более одного раза,
● по возможности всё выполняется в параллель, чтобы завершить запрос быстрее (на pq это параллельные вычисления, в spark - разделение данных по воркерам).

Я конечно обобщаю, но сходства присутствуют.

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

Но однажды собрал всю инфу, нарисовал презентации и всё же разобрался. Теперь у вас есть почти 3 часа крутого контента, чтобы не только подготовиться к собесу, но и применить знания на текущей работе.

Ссылочка тут: https://directprobi.ru/platform/apache-spark-teoriya

СВОЙ ИИ-АГЕНТ

Один мой друг испытывал трудности при оплате Claude, и я подумал: почему бы не сделать агента под российскую аудиторию, где не будет проблем? Где никто не заблокирует аккаунт и не нужно пользоваться VPN.

Теперь, когда проект почти готов, могу сказать, что это был самый крупный мой проект в плане вайб-кодинга. И только на нём я почувствовал, что у этого подхода есть ограничения. Например, деградация ответов моделей по мере роста проекта.

На чём всё построено

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

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

Удобно, что сейчас множество моделей лежат в Open Source, и они не такие уж слабые. Санкции в основном ложатся на популярные системы вроде Codex или Claude. Open Source это касается меньше, так что всё строилось именно на открытых моделях (Kimi K3 и других).

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

В основном фокус был на онлайн-песочнице, но локальная версия тоже есть. Если привыкли работать на своём компьютере, это не проблема.

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

Что по итогу

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

Сейчас нет прямой возможности оплачивать агента - он пока в тестовом режиме. Всё зависит от вашей реакции, и если идея покажется интересной, продолжим её развивать🔥

Видео тут: https://kinescope.io/aHftHEH5Mrzq3y2QgNiKJf
Тоже самое на YouTube: https://youtu.be/t-hw0nur6OI
Сам агент живет тут: https://kotagent.ru/

На будущее - есть идея голосового агента, пока в простом варианте, но её можно развивать. Возможно тоже скоро опубликую.

ИНКРЕМЕНТНАЯ ЗАГРУЗКА: КАК НЕ ГРУЗИТЬ ВСЁ ЗАНОВО

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

Тут и появляется идея инкрементальной загрузки - забирать только изменения. Но не всё так просто. Изменения ещё нужно поймать и правильно загрузить. А это часто вызывает затруднения🙄

Четыре способа поймать изменения

1. Самое простое - по дате. Берём строки, где updated_at больше последней засечки. Это самый частый вариант, но нужно учитывать нюансы - часовые пояса, строки на границе времени записи и изменения, пришедшие задним числом.

2. По возрастающему ключу. Всё, где id больше максимального. Отлично работает для журналов, куда строки только дописываются, и молча пропускает любые правки старых строк.

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

4. CDC. Читаем журнал изменений базы: WAL в Postgres, binlog в MySQL. Видим вставки, правки, а главное - удаления. Тут нужна отдельная инфраструктура - коннектор, очередь и мониторинг лага.

Когда возникают трудности?

Если процесс упал посередине загрузки - старые данные уже удалены, а новые ещё не записаны. Как итог - дыра в отчёте.

Другой вариант - удвоенные строки. Если удаление старых данных не произошло, а новые загружены - в таблице появятся дубли.

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

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

Изменения схемы - добавление столбца на источнике роняет весь пайплайн или просто остаётся незамеченным.

Как это обходится?

Первый важный момент - идемпотентность: несколько запусков пайплайна подряд должны давать один и тот же результат. Самый надёжный приём - перезаписывать окно целиком (например, день или партицию), а не дописывать строки по одной.

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

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

При удалении строк в источнике можно на какое-то время ставить пометку об удалении, чтобы пайплайн успел забрать эту информацию. Также подойдёт CDC с чтением WAL-журнала или на крайний случай периодическая сверка.

От изменений схемы спасает явный список столбцов вместо SELECT * и проверка схемы перед запуском.

Как это работает в разных СУБД

Postgres - INSERT ... ON CONFLICT DO UPDATE внутри транзакции. Вставка и обновление одной командой, перезапуск безопасен.

ClickHouse - транзакций нет, поэтому вставляем новую версию строки в ReplacingMergeTree и читаем через FINAL, либо подменяем партицию целиком.

В обычном S3 атомарность очень ограничена, зато в Iceberg и Delta есть атомарный коммит и MERGE INTO. Кроме того, можно спросить, что изменилось с такого-то снапшота: инкрементальность встроена в сам формат.

dbt - инкрементальные модели: is_incremental(), unique_key и стратегии merge или insert_overwrite.

В Airflow и Dagster - окна и бэкфилы: задача обычно считает один интервал, и любой интервал можно перезапустить руками.

Что по итогу

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

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

А как вы ловите изменения? И на чём уже обжигались?

ИИ ПРОТИВ ДАТА ИНЖЕНЕРОВ

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

С MCP-коннекторами всё вышло из под контроля. Мой Claude подключён к Power BI, Яндекс Директу, и даже к программе для монтажа видео. Задачи я ставлю голосом: пары фраз достаточно, чтобы построить дашборд или создать рекламную кампанию.

За монтаж часового ролика для ютуб я платил от 10 до 30 тысяч рублей. Теперь в этом нет смысла - с клодом я не только получаю неограниченный контроль над процессом, но и нереальное качество монтажа. И это без особых усилий и промптинга. А обложку для видео не напрягаясь делает ChatGPT.

Возникает вопрос: что же будет с дата-инженерами? Claude уже пишет код на уровне сильного мидла если не синьёра. Зачем я тогда вообще нужен работодателю?

Агент забирает задачи по одной

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

Почему пока всё спокойно?

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

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

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

И да, кто-то должен ставить задачи клоду, так как это всё еще инструмент.

Первыми страдают новички

Часто людей даже не увольняют - какой смысл платить им 2-3 зарплаты, их просто не нанимают. Задачи распределяются между миддлами или синьёрами при поддержке агентов.

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

Удешевление кода

Сам код дешевеет, давайте посмотрим что на этом фоне становится дороже.

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

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

Ответственность. Ценится тот, кто проверяет результат и подписывается под цифрами. За это чаще всего и платят.

Доступы и безопасность. Те самые NDA и запрет отдавать данные наружу - зона дата-инженера. Тот, кто покажет, как дать агенту доступ к данным безопасно, будет нужен при любом раскладе.

Доверие и репутация. Когда сгенерировать можно что угодно, верят людям с историей.

Чтобы оставаться ценным, нужно знать систему, отвечать за неё и быть тем, кому её доверяют.

Что по итогу

Нейросеть остаётся инструментом, даже такая мощная как Claude. Важно использовать её для решения задач, при этом отвечая за результат.

Каким бы ни был завтрашний день, сегодня есть ряд шагов, которые позволят подготовиться.

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

А вы уже отдали агенту часть своей работы?

УТЕЧКИ ДАННЫХ - КАК ОНИ ПРОИСХОДЯТ

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

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

Сканеры непрерывно обходят интернет и проверяют типовые порты. Даже если вы никому не интересны, вас найдут просто по открытому порту или ссылке. Многие помнят индексирование в поиске открытых по ссылке отчетов Power BI 😊

Классика сканирования портов:
- 5432 у Postgres,
- 8123 и 9000 у ClickHouse,
- 6379 у Redis,
- 27017 у MongoDB,
- 9200 у Elasticsearch.

Типовые причины утечек

Пароли
Стандартные admin/admin, пароль от другого сервиса, который уже утек год назад, и отсутствие двухфакторной авторизации. Для перебора берут словари из прошлых утечек, где уже лежат реальные пароли.

Вспоминается недавний случай в Дании: через учётку частной компании с доступом к реестру населения утекли данные 8,8 миллиона человек. По словам хакера, у админа стоял пароль “123456”.

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

Если ключ хоть раз попал в git, удалить строку недостаточно - он остался в истории коммитов. Такой ключ считается скомпрометированным - его нужно менять.

Человек
Письмо "подтвердите доступ", сообщение от "коллеги", звонок из "техподдержки". Это самый дешевый вход, который не требует технических навыков.

Забытое и необновленное
Старый сервис, который никто не обновляет, потому что никто уже не помнит, зачем он нужен. Если в нём есть уязвимость, это может позволить получить доступ к другим сервисам.

Слишком широкие права
Человеку нужна одна таблица, а ему дали доступ ко всей базе. Один угнанный пароль или токен - и наружу уходит всё. Это же касается и сервисов - не используйте один доступ к БД для всех сервисов. Каждому нужны свои права.

Сторонние библиотеки
Довольно часто слышу про этот способ: люди массово ставят популярную библиотеку, а её репозиторий уже взломан. Как итог - повсеместные утечки.

Ну и из свежего - критические уязвимости. Если своевременно не обновляться - можно стать жертвой взлома из-за общеизвестной дыры.

Что же делать?

Инвентаризация. Откройте правила фаервола и ответьте, зачем нужен каждый открытый порт. К базам выдайте доступ только по списку IP, ничего не выставляя наружу.

Секреты держите вне кода. Переменные окружения или менеджер секретов, конфиги - в .gitignore. Ключ, который попал в репозиторий - меняем.

Двухфакторная авторизация везде, где возможно.

Минимальные права для юзеров. Свой пользователь на каждый сервис, только нужные таблицы. Для аналитики - отдельный доступ только на чтение.

Логи и оповещения. Алерт на успешный вход после серии неудачных и на вход с нового адреса.

Бэкапы отдельно. Если угнали доступ к серверу, бэкап не должен открываться тем же ключом.

Минимум сторонних библиотек и аккуратнее с их обновлением. Чужие библиотеки могут подвергнуться атаке и с обновлением привезти вам потенциальную дыру.

Обновление в случае обнаружения критических уязвимостей. Очень актуально сейчас, когда ИИ каждый день находит что-то новое.

Защищаем сервер от подбора
В первые сутки после покупки сервера в логах можно увидеть попытки входа: сканеры добрались до нового адреса. Против такого ставим fail2ban и блокируем подобные IP. Как вариант - вообще отключить вход на сервер по паролю, оставив доступ только по ключу.

Какой тут вывод?

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

Большинство утечек - не взлом, а банальный беспорядок. И наведение порядка - первая линия защиты.

Проверьте прямо сейчас, что у вас смотрит наружу.
И расскажите в комментах, нашли ли что-нибудь неожиданное.

SQL-ТРЕНАЖЕР

Собрал все базовые моменты SQL в один крутой тренажёр. Задания получились не самые простые, но вполне решаемые. Первая часть доступна всем (задания работают после регистрации), а вторая - по базовой подписке.

Тут не будет задач, сгенерированных ИИ на лету - это слишком ненадёжно. Задачи специально прорабатывались заранее, чтобы помочь вам освоить базу.

Что я закладывал внутрь?

1. Разнообразие. Каждая следующая задача заставляет вспоминать или разбирать что-то новое.
2. Ограничение. В тренажёре всего 50 задач, не тысячи. Это вполне обозримый горизонт.
3. Оптимальная сложность. Да, в самом начале идут простые задачки, но даже они заставляют начать думать.
4. Ничего лишнего. Только самые частые ходовые выражения.
5. Практичность. Это именно то, что спрашивают на собесах и то, с чем вы столкнетесь в реальной работе.
6. Наглядность. В каждой задаче вы наглядно увидите таблицы, список столбцов и их описание.
7. Интерактивность. В тренажёре уже есть шаблон запроса, который нужно дозаполнить. При нажатии на колонку или таблицу, её имя автоматически вставится в запрос.

Раньше для подобных тренировок, я специально разворачивал postgres и выполнял запросы в dbeaver. Но тут postgres уже развёрнут под капотом. При вашем ответе запрос проверяется именно на нём.

Ссылочка: https://directprobi.ru/platform/sql-practice/

Не забудьте залогиниться и если что-то не работает, обязательно напишите мне.