В архитектуре потоковой обработки данных Kafka, как высокопроизводительная очередь сообщений, обычно используется для агрегации данных, а StarRocks, как высокопроизводительная аналитическая СУБД, отвечает за хранение и анализ. С помощью Routine Load можно стабильно и эффективно загружать в StarRocks данные в форматах JSON и CSV из Kafka.
От монолита к модулям: строим масштабируемую архитектуру AI-агентов с FastMCP и LangChain
Год бума AI-агентов показал: самая большая проблема — не галлюцинации, а архитектура. Когда инструментов много, а агенты распухают, копипаста и сложность тестирования убивают скорость разработки.
В современных data-процессах ключевую роль играет обеспечение качества данных. Рассмотрим четыре популярных подхода: DBT, SQL, Python (Pandas/SQLAlchemy) и Great Expectations, оценив их эффективность для различных сценариев проверки данных.
Эта статья будет интересна и полезна Data-инженерам, аналитикам данных и специалистам Data Quality для выбора оптимального метода валидации данных в зависимости от стека технологий и сложности бизнес-логики. Материал ориентирован на начинающий уровень подготовки: тем, кто еще не сталкивался системно с инструментами управления качеством данных.
Привет, Хабр! Меня зовут Мария, я Data-инженер в SimbirSoft, и предлагаю для начала немного познакомиться с каждым из вышеперечисленных инструментов.
Если в 2026 году вы планируете наконец освоить ML или просто пока не придумали, чем заняться в каникулы, то у нас есть одна идея.
Под катом — подборка бесплатных ресурсов, которые позволят погрузиться в работу с искусственным интеллектом. Есть материалы и для новичков, и для тех, кто уже работает с ML и хочет углубить знания.
Всем привет, меня зовут Игорь Горбенко, и я системный аналитик в компании М2.
Отчёты, которые обновляются раз в сутки, хорошо подходят для стратегической аналитики. Но в какой-то момент бизнесу становится важно понимать, что происходит в течение дня, а не только по итогам ночной загрузки.
В М2 мы столкнулись с этим, когда от продуктовых команд и службы поддержки начали приходить запросы на внутридневную отчётность и почти real-time метрики. Наш основной подход — ежедневная батчевая загрузка данных — перестал закрывать такие сценарии, и нам понадобился другой способ работы с изменениями в продуктовых базах.
В этой статье я расскажу, как мы внедряли Change Data Capture (CDC) с использованием Apache Flink, какие задачи это помогло решить, с какими ограничениями мы столкнулись и почему CDC — полезный, но не универсальный инструмент.
CDC и Apache Flink: кратко о технологии и нашем подходе
Давайте начнем разбираться. Некоторые из вас наверняка знакомы с понятием CDC, Change Data Capture — техника захвата изменений в базах данных.
Для контекста стоит отметить Apache Flink — движок для загрузки и обработки батчей и стриминговых данных в реальном времени. В статье речь пойдет про Flink CDC — фреймворк с открытым исходным кодом для отслеживания изменений данных в базах данных в реальном времени.
В проектах нашего отдела в М2 основной метод загрузки — это ежедневное ночное
копирование продуктовых баз данных (PostgreSQL, MongoDB) в аналитическое хранилище на базе Apache Iceberg и последующая их обработка с помощью движка Trino.
В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.
ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом - «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя.
На SQL-собеседованиях интервьюер часто формулирует условия устно, просит рассуждать вслух и быстро писать запрос в реальном времени. Это непривычный формат — и именно поэтому он становится испытанием даже для тех, кто много практиковался.
В предыдущей статье мы говорили о текстовом поиске, а в сегодняшней я расскажу о векторном (семантическом) поиске.
Итак, если мы используем OpenSearch, в Yandex Cloud представляется логичным использовать модели вложений этого же облака.
Этот код можно запустить как Python Cloud Function. Написан он исходя из того, что в каталоге сервисного аккаунта, под которым запускается функция, доступна модель вложений (embedding). Детали подключения к кластеру описаны в документации.
Рассмотрим один крайний случай: если мы подключаемся, указывая FQDN DATA-узлов, у которых не включен публичный доступ, то функция должна запускаться в сети кластера OpenSearch, иначе они будут недоступны. Альтернативные варианты: подключаться через «Особый FQDN» или узел DASHBOARD с публичным доступом.
Код создаёт тестовый индекс с текстовым и векторным полем, явно вызывает embedding model через REST API, создавая векторы вложений для документов и запроса, и выполняет векторный поиск, демонстрируя способ интеграции. Обратите внимание на способ выбора разных моделей для документов и запросов.
Ранее я уже делился опытом, как мой приятель искал работу в Германии в 2025 году (см. статью [Личный опыт] Поиск работы в Германии в середине 2025). И вот теперь уже нашей компании самой пришлось искать Middle Data Engineer в команду на замену увольняющемуся сотруднику, что позволило мне взглянуть на процесс с другой стороны баррикад, так как я выполнял в этом найме роль основного технического эксперта. Как это выглядит со стороны работодателя, а также своими наблюдениями я хочу поделиться в данной статье.
Спойлер - от результата (кого в итоге мы наняли) я выпал в осадок %)
Сегодня наличие платформы данных является уже де-факто стандартом даже для малого бизнеса. И частный, и государственный секторы понимают важность цифровой трансформации через накопление и анализ данных для будущей монетизации и грамотного управления. Принятие стратегических и даже операционных решений на основе экспертизы и чуйки уходит в прошлое. Прогнозирование спроса, управление запасами, оптимизация логистики — все опирается на анализ данных.
Однако внутренняя эффективность компаний при работе с данными (трансакционные издержки) остается все еще «темной материей». Time-2-market для релиза цифровых решений по-прежнему велико, документация устаревает быстрее среднего срока работы специалиста по данным в компании, а приоритезация бэклога, выбор способа расчета метрик и т. д. принимаются на основе экспертизы, эскизов в Miro и тысяч внутренних Excel-таблиц, которые переделываются при каждой смене лидеров направлений. Все это — скрытые внутренние издержки, которые негативно сказываются на марже компании в долгосрочном периоде.
Искусственный интеллект резко ворвался в нашу жизнь. Для кого-то это возможность смотреть или генерировать прикольные и не очень картинки и видео, которые многим уже надоели.
А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи. Многие кто уже успел попробовать Cursor и подобные инструменты, восхищаются как ИИ способен писать код.
В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.
Кажется, о внедрении каталога данных не написал только ленивый. Каждая крупная компания так или иначе к этому (каталогу) приходит. Пробует разные решения и методологию. У кого-то успешно только на презентации для совета директоров (чаще всего), у кого-то на деле.
Здесь же я хочу рассказать не о том, как заполнять каталог или какой выбрать. А о том, что нужно сделать, прежде чем переходить к покупке/запуску этого каталога. Для тех, кто уже имеет такого зверя в своем зоопарке, но с ним что-то не так, думаю, тоже будет полезно.
Если вы один из счастливчиков, у кого каталог действительно взлетел, можете дальше не читать. Однако что-то мне подсказывает, что таких будет не много.
Осторожно, статья-детектор.
Привет, Хабр! На связи — технические лидеры направления разработки Apache Spark в составе платформы Data Ocean Андрей Первушин и Дмитрий Паршин из Data Sapience. Мы занимаемся решением нетривиальных задач в области Spark-вычислений, некоторые из которых становятся частью конечного продукта.
Сегодня мы расскажем, с какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg, что такое equality delete, почему они создают нагрузку при чтении таблиц в Apache Iceberg и как мы оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.
Давайте разберем, как выглядит работа с MCP, на реальном примере из опыта моего дата-консалтинга. В этой статье теории не будет, только практика, много скриншотов и пара лайфхаков.
В A/B-тестах хотелось бы смотреть на главную метрику, ту самую North Star, которая показывает успех продукта. Но на практике она почти всегда медленная, шумная и бесполезная для быстрых решений. Например, вы запускаете тест новой системы рекомендаций, ждёте неделю, две, а LifeTime Value не двигается. И непонятно, это потому что нет результата или ещё рано делать выводы.
Чтобы не тратить месяцы на догадки, можно воспользоваться прокси-метриками — быстрыми, чувствительными показателями, которые реагируют раньше, чем бизнес-метрика «успевает моргнуть». Проблема в том, что это решение часто требует дополнительные ресурсы.
Привет, Хабр! Меня зовут Артем Ерохин, и я Data Scientist в X5 Tech. Я прочитал современные исследования, пропустил их через свой опыт и собрал концентрат подходов к работе с прокси-метриками. Постараюсь передать только суть. Разберемся, зачем нужны прокси, как с ними не выстрелить себе в ногу, где заканчивается польза и начинается самообман.
Привет, Хабр!
Сегодня предлагаю обсудить Managed OpenSearch Yandex Cloud. Поговорим о том, как автоматизировать управление кластером, чтобы сократить расходы на разработку, и как улучшить качество поиска на русском языке, используя доступные в сервисе инструменты морфологии.
Импортозамещение аналитических систем остаётся одной из наиболее трудоемких задач в корпоративной ИТ-среде. Особенно когда речь идёт о платформах уровня SAP BW/4 HANA: больших объемах данных, сложной архитектуре, множестве отчетов и строгих нефункциональных требованиях. В подобных проектах важны не только выбор стека и корректная миграция хранилища, но и организационные решения, планирование и работа с пользователями.
Всем привет! Меня зовут Михаил Синельников, я лидер кластера импортозамещения аналитической отчетности в ВТБ. Вместе с моим коллегой Владимиром Ведяковым, ИТ-лидером проекта со стороны компании «Сапиенс Солюшнс», мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами.
От «обезьяньей» работы к Smart-анализу: как правильно готовить данные для моделей.
Что такое Exploratory Data Analysis и как избежать основных ошибок при его выполнении.
В статье описываю практический опыт построения корпоративного ИИ‑ассистента: от структуры базы знаний и графовой модели до фильтрации контекста и контроля версий. Материал будет полезен продактам, архитекторам, маркетологам и всем, кто внедряет ИИ в бизнес‑процессы.
«Garbage in — garbage out», как мусор в корпоративной Базе Знаний мешает корректной работе ИИ и как мы предлагаем это исправить.
Сегодня многие компании внедряют ИИ‑агентов по упрощённому сценарию: загружают PDF‑регламенты, Excel‑прайсы и архивы переписок в векторную БД, после чего ожидают, что модель будет корректно отвечать на вопросы пользователей.
Такой подход, известный как Naive RAG, в большинстве случаев приводит к нестабильным результатам: несогласованные ответы, ошибки в тарифах, применение устаревших инструкций.
Причина — не в возможностях моделей: современные LLM хорошо работают с контекстом. Проблема — в структуре данных, которые подаются на вход. Если знания представлены в виде фрагментов без связей, версий и семантической целостности, то на выходе появляется то, что обычно называют «галлюцинациями».
Краткая история о техническом эксперименте. Автор проанализировал многолетнюю историю высоколиквидных активов, чтобы найти «гарантированные» ранги наклона, которые всегда дают выигрыш. Робот был идеален, но столкнулся с фундаментальным препятствием. О том, как эмпирическое фиаско приводит к формулировке метафизического принципа, который опровергает Эйнштейна и Екклесиаста.
