CODERIKK - Python и SQL DE

🔹 Ключевые слова из текста с помощью LLM 🔹 Как быстро получить аккуратный список keyword extraction из текста? 🔸 Извлечение ключевых слов решает проблему: без него трудно искать, тегировать и группировать документы — классические regex/TF-IDF часто шумят и теряют смысловую суть. 🔸 Сначала попроси LLM сделать краткий summary (резюме). Сжатый контекст уменьшает шум и делает keyword extraction точнее. 🔸 Дай строгий prompt с ожидаемым форматом для простого парсинга (парсинг = превращение текста в структуру). Проси JSON и минимум лишнего. Пример prompt и ожидаемый ответ: Сделай 1-2 предложения summary и верни JSON: {"summary":"...","keywords":[{"k":"...","score":0.0}]} Текст: 📚 Совет: требуй JSON — легче парсить, валидировать и интегрировать в пайплайн. #CODERIKK #Prompt #Junior ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️

🔹 NULL в SQL: почему он опасен и как с ним работать 🔹 Что делает NULL и почему сравнения ломаются? 🔸 NULL в SQL (Structured Query Language) — маркер неизвестного/отсутствующего значения; нужен, чтобы отличать «нет данных» от пустой строки. Проблема: выражения типа col = NULL не дают true/false, потому что NULL — не значение, а неизвестность. 🔸 Проверять NULL надо через IS NULL / IS NOT NULL — это оператор, который явно ловит "нет данных". Пример поиска записей без email: SELECT * FROM users WHERE email IS NULL; 🔸 Подставлять значения по умолчанию: COALESCE возвращает первый NOT NULL, NVL делает то же в Oracle. Небольшой пример: SELECT COALESCE(phone, 'no-phone') AS phone FROM users; SELECT NVL(age, 0) FROM users; 📚 Запомни: NULL — это "неизвестно", не сравнивай с =; используй IS NULL, COALESCE или NVL. #CODERIKK #ErikkKollil #Junior ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️

🔹 Agile в DE: Scrum vs Kanban для Data Engineering 🔹 Как Scrum/Kanban помогают управлять data engineering задачами? 🔸 Data pipelines ломаются, требования к данным меняются, а задачи — разной длины. Agile нужен, чтобы разбить большие интеграции на итерации, снизить риск и быстрее доставлять рабочие части данных. 🔸 Sprint (итерация) даёт фиксированный ритм: планируете backlog, берёте набор задач в Sprint, демо и релиз — это заставляет дробить крупные "проектные" задачи на выполнимые инкременты. Kanban полезен, если поток задач непрерывный — ограничиваете WIP (work in progress) и уменьшаете переключения. 🔸 Retrospective помогает выявить причины flaky ETL и забытые проверки; backlog хранит и приоритизирует задачи: баги, data quality, рефакторинг. Пример item в backlog: - "Fix nulls in user_events source" | estimate: 2d | tests: add null-handling 📚 Небольшие итерации + приоритетный backlog + ретроспективы = меньше аварий и быстрее ценность от данных. #CODERIKK #DE #Middle ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️

🔹 Результаты недели: схемы, MariaDB и Cassandra 🔹 Что важнее — Schema Registry или единообразие формата? 🔸 Schema Registry нужен, чтобы гарантировать соответствие схем между продьюсерами и консюмерами: без него JSON может меняться и ломать пайплайны. 🔸 Когда работаешь с NoSQL (Not Only SQL) и Cassandra, схемы часто implicit; отсутствие Registry приводит к рассинхрону данных. MariaDB — реляционная, там схемы явные и другие инструменты подходят. 🔸 Практика: храните JSON‑схемы в Schema Registry, валидируйте в CI и версионируйте; добавление nullable‑поля обычно backward‑safe, смена типа — breaking, планируйте миграцию заранее. 📚 Итог: Schema Registry + валидация JSON обеспечивают соответствие и предсказуемые миграции. #CODERIKK #Result #Junior ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️

🔹 NoSQL: когда реляции не спасают 🔹 Когда выбирать NoSQL вместо реляционной базы? 🔸 NoSQL (Not Only SQL) появился потому, что реляционные схемы ограничивают гибкость: часто модель меняется, а ALTER TABLE и сложные JOIN'ы тормозят разработку и работу при больших объёмах данных. 🔸 Когда нужна простая схема для быстрых записей и масштабирование по горизонтали (масштабирование) — NoSQL проще шардировать и выдерживает высокую нагрузку на запись без сложной синхронизации. 🔸 Типы и практическая разница: документоориентированные хранят JSON-документы — удобно для вложенных объектов; ключ-значение дают экстремально быстрый доступ по ключу. Пример документа: { "user_id": 123, "name": "Иван", "prefs": {"theme": "dark", "lang": "ru"} } 📚 Выбирайте NoSQL, когда нужна гибкость схемы и горизонтальное масштабирование; подбирайте тип БД под шаблон доступа к данным. #CODERIKK #DE #Junior ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️

🔹 Как собрать портфолио Data Engineer — что показать? 🔹 Что поставить в портфолио, если ты junior? 🔸 Портфолио решает нехватку опыта: оно показывает, что ты умеешь строить рабочие ETL (Extract, Transform, Load)‑пайплайны, думать о качестве данных и выставлять результат на GitHub как доказательство работы. 🔸 Проекты: 2–4 маленьких end‑to‑end проекта — простой ETL из CSV в БД, схема хранилища (star/schema), один проект с оркестрацией (Airflow) или стримингом. Каждый проект демонстрирует конкретную проблему и её решение. 🔸 Навыки: явно укажи Python и SQL, версии, библиотеки (pandas, sqlalchemy), плюс Docker/CI и облако если есть — это показывает, когда проект готов к продакшену. 🔸 GitHub и README: организуй репозиторий — README с целью, архитектурной схемой, шагами запуска и кратким примером кода. import pandas as pd df = pd.read_csv('data.csv') df.to_sql('table', con=engine, if_exists='replace') 📚 Сделай акцент на reproducibility: инструкции + диаграмма = лучшее впечатление. #CODERIKK #Speaking #Junior ➡️ Мы в Telegram - Сетке - ВК Буду рад вашей реакции здесь⬇️