Что такое большие данные, а что такое маленькие данные?

Каждый год это понятие меняется. Для аналитических систем это важно, ведь мы строим инженерные системы, чтобы обрабатывать большие данные! (Но непонятно, что значит большие данные).

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

Мы начинаем смотреть на distributed computing engines - Greenplum, Spark, Snowflake, Trino и т. п. Такие системы умеют обрабатывать данные параллельно.

Часто мы выбираем дорогую систему (distributed) для наших будущих объемов, а кто-то вообще ни разу в жизни ничего не выбирал и работает на legacy всю свою карьеру.

А ведь времена меняются, и теперь мы можем читать 1 ТБ данных с помощью одной машины, если использовать DuckDB. Можете посмотреть подробности в статье -
Processing 1 TB with DuckDB in less than 30 seconds

Товарищ сначала сгенерировал 1 ТБ данных на внешнем SSD, а потом написал к ним запрос. Если использовать MotherDuck и читать данные с S3, будет еще удобнее и быстрее.

В новом году хочу попробовать сократить расходы на Snowflake за счет использования DuckDB.

Как обещал, я записал видео как я использую Cursor с MCP в повседневной работе, но для начала показал VSCode, Claude Code, Kilo Code, Cline, Openrouter.

https://youtu.be/xYtXv6rqZnA

PS Если у вас есть похожий опыт, можно тоже записать демо и добавить в канал или сделать вебинар.

С Новым Годом! 🎄🎉🍾🎊🎆

Несколько статей, которые рассказывают про терминологию GenAI

Foundation vs. Instruct vs. Thinking Models - Статья объясняет разницу между тремя типами языковых моделей: Base/Foundation модели (предсказывают следующий токен, как библиотека без точки входа), Instruct модели (дообучены выполнять инструкции через SFT и RLHF, как готовое приложение) и Thinking модели (используют chain-of-thought reasoning для сложных задач, как оператор приложения). Автор рекомендует использовать Instruct модели для 90% случаев, Thinking модели для сложной логики (5%), и дообучать Base модели только для специфических доменов (5%).

AI Systems Engineering Patterns - Статья представляет 30 паттернов инженерии AI-систем, сгруппированных в 5 категорий: интерфейс (промпт-шаблоны, структурированный ввод/вывод, санитизация), инструменты (Function Calling, MCP, песочницы), контекст (CAG, RAG, кэширование, память), оркестрация (роутинг, каскадирование, LLM Gateway, Flow Engineering) и агенты (ReAct, планирование, мультиагентные системы). Автор показывает, что опыт традиционной разработки ПО применим к AI-системам через знакомые концепции (кэширование, валидация, композиция), адаптированные для работы с LLM, и для каждого паттерна объясняет применение, компромиссы и риски.


Facilitating AI adoption at Imprint - Статья описывает 18-месячный опыт автора по внедрению AI-инструментов и агентов в компании Imprint, включая подходы к стратегии, обучению сотрудников, созданию внутренних агентов и измерению эффективности. Основной вывод: успешное внедрение AI требует глубокого погружения лидеров в детали, фокуса на реальной продуктивности (а не на имидже), и тесного партнерства между разработчиками платформ и пользователями, а не просто создания инструментов в надежде, что их будут использовать.

Generative AI Strategy - Это презентация в формате слайдов (июнь 2023) с фреймворком для разработки стратегии внедрения generative AI в компании, созданная в ответ на вопрос "Руководство требует внедрить генеративный AI, что делать?". Статья представляет собой набор слайдов с практическим подходом к выбору направлений использования генеративного AI, оценке возможностей и рисков, но автор отмечает, что это ранняя версия идей, которую она планирует развить в полноценную статью позже (есть также видео доклада на YouTube).

Agents - подробная статья (январь 2025, адаптация из книги "AI Engineering") о AI-агентах — системах, которые воспринимают окружение и действуют в нём. Статья охватывает ключевые аспекты: определение агента через окружение и набор инструментов (tools), планирование (разделение на генерацию плана, валидацию и выполнение, дискуссия о способности LLM к планированию), инструменты (три категории: расширение знаний через RAG/поиск, расширение возможностей через калькуляторы/code interpreters, write-действия для изменения данных), рефлексия (паттерны ReAct и Reflexion для анализа и коррекции ошибок), и оценку агентов (режимы отказа в планировании, использовании инструментов и эффективности). Автор подчёркивает, что успех агента зависит от правильного выбора инструментов и качества планировщика, обещая будущие посты про фреймворки и системы памяти.

Common pitfalls when building generative AI applications - Статья описывает 6 типичных ошибок при создании генеративных AI-приложений (январь 2025):
1) использование gen AI там, где он не нужен (многие задачи решаются проще без AI),
2) путаница между "плохим продуктом" и "плохим AI" (часто проблема в UX, а не в технологии,
3) старт со сложных решений (раннее использование фреймворков и fine-tuning вместо простых подходов),
4) переоценка ранних успехов,
5) отказ от человеческой оценки в пользу только AI-судей (лучшие команды ежедневно проверяют 30-1000 примеров вручную для калибровки, обнаружения проблем и улучшения),
6) краудсорсинг use cases без общей стратегии (приводит к множеству мелких низкоэффективных приложений). Автор подчёркивает важность продуктового мышления и стратегии, а не просто технологии.

Building A Generative AI Platform - Это очень подробная статья (июль 2024) о построении платформы для генеративного AI, которая постепенно описывает архитектуру от простейшей (запрос → модель → ответ) до сложной production-системы. Основные компоненты:
1) Context construction (RAG с embedding/term-based поиском, SQL-запросы, веб-поиск, query rewriting),
2) Guardrails (входные для защиты от утечек PII и jailbreaking, выходные для проверки качества/токсичности/галлюцинаций),
3) Router и Gateway (маршрутизация запросов к разным моделям, унифицированный доступ, fallback, контроль доступа),
4) Cache (prompt cache, exact cache, semantic cache для снижения латентности и стоимости),
5) Complex logic (циклы, условное ветвление, write-действия),
6) Observability (метрики, логи, трейсы) и
7) Orchestration (LangChain, LlamaIndex и др., но автор советует начинать без них).

А какие вы порекомендуете свежие ресурсы? Если хотите добавить ее как ссылку в коммент, можно использовать код:

http://ssilka.ru

Для инвесторов было необходимо посмотреть демографию клиентов в США. Для такой задачи можно использовать открытые источники, например данные US Census Bureau, которые доступны в Snowflake.

Бюро переписи населения США публикует данные о американском населении и экономике.

Американское исследование сообществ (American Community Survey) этого агентства — это постоянно проводимый опрос, который предоставляет самые актуальные социальные, экономические, жилищные и демографические статистические данные. Ежегодно публикуются как однолетние, так и пятилетние оценки для различных уровней географических единиц, включая штаты, города, почтовые индексы и группы переписных участков. В отличие от Всеобщей переписи населения (Decennial Census), Американское исследование сообществ публикуется каждый год и рассылается по выборке адресов в США (~3,5 миллиона).

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

Сами по себе данные очень неудобные https://api.census.gov/data/2023/acs/acs5/variables.html, так что AI очень хорошо помог (Cursor, MCP - прям как я в недавнем видео записал).

Чтобы упросить логику, трансформации разложил по слоям в dbt.

Хотел поделиться примером демографии по медиане доходов в США:

CASE 
        WHEN median_household_income_dollars >= 150000 THEN 'High Income ($150k+)'
        WHEN median_household_income_dollars >= 100000 THEN 'Upper Middle ($100k-$150k)'
        WHEN median_household_income_dollars >= 75000 THEN 'Middle Income ($75k-$100k)'
        WHEN median_household_income_dollars >= 50000 THEN 'Lower Middle ($50k-$75k)'
        ELSE 'Lower Income (<$50k)'

То есть из примера видно, что средний доход в штатах это 75к в год (до налогов), где-то 4т в месяц на руки. А высокий доход это 150т+, около 8т на руки в месяц. Точно так же и в Канаде, только в Канадских долларах, но налоги будут выше и цены на все тоже будут выше.

А если посмотреть на зп Инженера данных, то старший специалист в США это 180-220к$, а в Канаде 160-180к CAD.

То есть зарплаты в ИТ они выше, чем “high income”.

Но у них есть недостаток, как правило все “high income” специалисты будут жить в дорогих городах, платить большую ипотеку или рент, платить кредит за машину(ы) и по факту, они будут такими же бедными.


Я бы сделал сейчас другие бакеты:
- High Income: >600к
- Upper Middle: 400-600к
- Middle: 250-400к
- Lower: <200к

Очень интересный обзор М5 процессора https://youtu.be/Jh9pFp1oM7E?si=gwUcZVsxPhzA4TFk

Будет интересно с детьми посмотреть

PS согласно автору без использования AI, все сделано в Blender. Хотя у Blender есть MCP.

Apache Spark выпустил релиз 4.1

Если 4.0 было страшно использовать, то 4.1 уже вполне.


Ключевые обновления
1. Spark Declarative Pipelines (SDP)
Новый декларативный фреймворк, который позволяет разработчикам определять наборы данных и запросы, а Spark автоматически управляет:
• Графом выполнения и порядком зависимостей
• Параллелизмом, контрольными точками и повторными попытками
• Поддержка Python, SQL и Spark Connect API

2. Real-Time Mode (RTM) в Structured Streaming
Первая официальная поддержка режима реального времени для непрерывной обработки с задержкой менее секунды:
• Задержка p99 в диапазоне единиц миллисекунд для задач без сохранения состояния
• Поддержка Kafka источников и приёмников
• Активируется простым изменением конфигурации без переписывания кода

3. Улучшения PySpark
Arrow-нативные UDF и UDTF:
• Новые декораторы ⁠@arrow_udf и ⁠@arrow_udtf для эффективного выполнения без накладных расходов на конвертацию Pandas
• Прямая работа с объектами PyArrow для векторизованной обработки
Python Worker Logging:
• Захват логов UDF через встроенную табличную функцию
• Упрощённая отладка Python функций

Filter Pushdown для Python Data Sources:
• Уменьшение перемещения данных за счёт обработки фильтров на уровне источника

4. Spark Connect
• Spark ML теперь GA для Python клиента
• Интеллектуальное кэширование моделей и управление памятью
• Сжатие планов выполнения protobuf с использованием zstd
• Потоковая передача результатов Arrow порциями
• Снято ограничение в 2 ГБ для локальных отношений

5. Улучшения SQL
SQL Scripting (GA):
• Включён по умолчанию
• Поддержка циклов, условных операторов и обработчиков ошибок
• Новый синтаксис ⁠CONTINUE HANDLER и многопеременное объявление ⁠DECLARE
VARIANT Data Type (GA):
• Стандартизированное хранение полуструктурированных данных (JSON)
• Shredding для оптимизации чтения:
▪ В 8 раз быстрее по сравнению со стандартным VARIANT
▪ В 30 раз быстрее по сравнению с JSON-строками
Recursive CTE:
• Поддержка рекурсивных общих табличных выражений для обхода иерархических структур
Новые аппроксимационные скетчи:
• KLL (для квантилей) и Theta скетчи для эффективных операций над множествами
Производительность
• Режим реального времени обеспечивает улучшение задержки на порядки величин
• VARIANT с shredding: 8-30x ускорение чтения (с компромиссом 20-50% замедления записи)

Статья "When AI writes almost all code, what happens to software engineering?" от The Pragmatic Engineer посвящена изменениям в профессии разработчика в связи с развитием AI для написания кода.

Основные темы статьи:

🔄 Переломный момент
Автор и многие опытные инженеры заметили, что новые модели AI (Opus 4.5, GPT-5.2, Gemini 3), выпущенные в ноябре-декабре 2025 года, достигли качественно нового уровня. Теперь AI может генерировать 90%+ кода, который раньше писали разработчики вручную.

📉 Плохие новости (The Bad)
• Снижение ценности специализации - знание конкретных языков программирования становится менее важным
• Прототипирование - теперь доступно не-техническим специалистам
• Конец узкой специализации - разделение на frontend/backend разработчиков может исчезнуть
• Рефакторинг и реализация задач - всё больше делегируется AI

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

📈 Хорошие новости (The Good)
• Инженеры важнее кодеров - навыки software engineering (архитектура, тестирование, код-ревью) ценятся больше
• Tech lead навыки - становятся базовыми требованиями
• Product-minded подход - разработчики должны лучше понимать продукт
• Системное мышление - важнее умение проектировать системы, чем писать код

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

⚠️ Неприятные последствия (The Ugly)
• Больше сгенерированного кода = больше проблем
• Слабые практики разработки начнут вредить быстрее
• Work-life balance может ухудшиться из-за повышенных ожиданий продуктивности

Мой коммент: Проблемы от vibe-coding — это очевидно, и некоторые уже меняют noscript в LinkedIn на "fixing your problems after vibe-coding". В токсичных компаниях реально могут требовать от вас больше результатов за меньшее время. Только вот в токсичных компаниях часто руководство не понимает ничего в AI, vibe-coding, и пока можно делать больше за меньшее количество времени. Но рано или поздно это изменится. Ведь можно отслеживать, сколько токенов было израсходовано, в какие репо коммитился код, и использовать AI как надзирателя. В любом случае, на данном этапе work-life баланс улучшился. Вопрос: надолго ли?

🤝 Слияние ролей
Границы между product managers и software engineers размываются - PM могут генерировать код, а инженеры берут на себя больше продуктовых решений.

Мой коммент: Я уже рассказывал про product-менеджера, который устал ждать отчет и навайбкодил целое решение с AI, дашбордом и парсингом данных опросов по продукту и стал чувствовать себя очень крутым и важным после этого. К сожалению, в production такое решение не пойдет, но он смог решить проблему сам от начала до конца без навыков и получил классный прототип с реальными инсайтами.

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

Возьмем пример Azure Data Factory. Это такой orchestration инструмент на Azure. По умолчанию там UI и drag&drop. Все очень просто, пока не нужно делать 100 pipelines.

Допустим, мы продвинутые инженеры (сеньоры, например), и мы хотим использовать best practices и engineering excellence, и добавили git версионирование, и следующий шаг будет сделать Infrastructure as a Code.

Первое, о чем мы подумаем - это Terraform или Azure Bicep. А может быть, вообще возьмем ADF SDK, и там есть Python SDK или C# (я, кстати, на нем и делал все в Microsoft внутри Visual Studio (не путать с VS Code)).

То есть мы думаем о привычном методе, о коде, который будет написан AI, но как будто человеком, и, в теории, другие человеки смогут его читать (без AI).

Хотя по факту никто его уже не будет читать без AI. И вообще уже не важно, что там C#, Python, Bicep, Terraform - главное, чтобы данные грузились.

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

Что я сделал?

Взял свой GitHub репозиторий с ADF, где все автоматически создано в ARM (Azure JSON формат), который не пишется человеком, и попросил AI сделать правила репозитория и начать создавать новые pipelines. (Аналог может быть Tableau Workbook XML или другие смежные программы с их файлами)

Таким образом, из моего backlog я просто взял и выкинул кучу задач про миграцию ADF на Bicep/Terraform и ускорил разработку, доработку и документацию в несколько раз.

То есть идея в том, что с AI я спустился на уровень ниже: вместо привычной абстракции в виде Terraform/Python я начал фигачить JSON ARM, который не human readable. И я полагаю, нам нужно не бояться уходить от традиционных методов и начинать исследовать новые возможности.

Скоро можно будет сразу на бинарном коде строить дашборды.

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

Дальше хочешь попробовать вставить duckdb куда-нибудь для оптимизации расходов, один ADF Runtime стоит 3к$ в месяц.