 |
VOOZH | about |
Это продолжение новых безопасных паттернов по работе с MCP, которые я для себя придумал, которые я описал в статье:
Основная задумка вместо того, чтобы строить очередной Data-lake возможно ли организовать взаимодействие через MCP так с данными, чтобы это было безопасно и эффективно
Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.
В статье - краткий разбор некоторых принципов моделирования данных простыми словами.
- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth
Я хотел написать маленький локальный RAG для научных статей: графы, hybrid search, HyDE, reranker, всё красиво. В итоге Full Pipeline проиграл почти всем простым baseline’ам, графы начали портить контекст, HyDE вредил, а локальная LLM уверенно делала вид, что всё хорошо. Потом я разобрался, что ломалось, выкинул лишние LLM‑вызовы, починил trimming и получил систему, которая, наконец, начала выигрывать там, где должна.
Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.
Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.
Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.
Привет, это команда Далее. На одном из проектов у нас есть терабайты данных о рекламных кампаниях, которые хранятся на десятках площадок. Это множество таблиц, агрегаций, расчетных метрик и формул.
Big Data обрабатывают аналитики и дата-инженеры: приводят в нормальный вид, следят за качеством, рассчитывают дополнительные метрики. В конце концов, все приходит в BI-систему, где менеджеры делают отчеты и визуализируют информацию на дашбордах.
MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО.
Мы ИТ-компания, создающая собственные продукты с высоким уровнем инженерной сложности, без зависимости от вендоров и системных интеграторов. В этой статье — честный рассказ о том, над чем мы работаем прямо сейчас и куда движемся в 2026 году.
Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач.
Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой.
В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа.
В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса.
Меня зовут Даниил Никольский, я бэкенд-инженер команды Trisigma. В создании статьи участвовали Искандер Мирмахмадов, руководитель продуктового направления, и Александр Кузнецов, старший аналитик. В этой статье я расскажу про Switchback-эксперименты, рассмотрим как они устроены, почему для него не подходит обычный t-тест, и какая инфраструктура нужна, чтобы проводить такие эксперименты в промышленном масштабе.
Решение доступно всем желающим по ссылке, а тут можно познакомиться с подробной технической документацией.
У вас есть список целей на день/неделю/год/жизнь? Не путайте его со списком неотложных дел, такой есть у всех, а если еще нет, то, как только приедете утром на работу, появится. Но от чего зависит, будут ли исполнены долгосрочные цели? Один из важнейших факторов – наличие внутренней мотивации. Она настолько мощный двигатель всей нашей жизни, что не только мы, но и все окружающие нас люди пытаются его эксплуатировать. Маркетологи в первую очередь. Но получается у них это далеко не всегда. Путаница в разных типах мотивации в рекламе и программах лояльности иногда приводит к обратным результатам, чем было запланировано.
Но нам, маркетологам, хорошо бы понимать, почему очень часто попытка воздействовать на мотивацию клиента извне приводит к полному ее отказу.
Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.
Как устроен Data Mesh, какие требования подход предъявляет к бизнесу и почему большинству российских компаний сегодня зачастую важнее построить зрелое DWH, чем пытаться перейти к распределенной архитектуре данных
В 1915 году Владимир Иванович Вернадский запустил проект, который сегодня назвали бы национальной базой данных ресурсов. Без компьютеров и цифровых технологий комиссия КЕПС собрала сведения о недрах, лесах, водах и энергии страны, заложив основы подхода «сначала данные, потом решения».
Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.
С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций.
Переход к такому состоянию системы часто воспринимается болезненно. Особенно если технология долго была центральной для команды и бизнеса. Но сам факт перехода в legacy не означает, что система была плохой или что работа команды обесценилась. Чаще наоборот: legacy становятся решения, которые долго работали, выдержали рост и успели стать частью критичной инфраструктуры.
В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития.
Меня зовут Андрей, я работаю с данными. И так получается, что на реальных проектах у меня никогда не было возможности собрать идеальный, на мой взгляд стек. Поэтому я собрал его в идеальном пет проекте.
В каждой лаборатории один и тот же биомаркер называют по-своему, и кажется логичным «схлопнуть все синонимы в один код». Но это работает ровно наполовину: LOINC-код — это не название анализа, а шесть осей (что, чем, где, как измерили), и рядом нужен UCUM для единиц.
Почему «синонимы → код» — ловушка, зачем нужны и LOINC, и UCUM, как это ложится в OMOP для RWE и почему финальный код нельзя доверить языковой модели. Референсная архитектура на бумаге — и честно про путь.
Привет! Меня зовут Саша Журавлев. Я основатель и управляющий партнер фонда Mento VC. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, Великобритании и Израиле, а в своем телеграм-канале рассказываю, как вижу рынок и принимаю инвестиционные решения.
Одна из вещей, которую я заметил за много лет в венчуре – решения крупных фондов могут быть не так независимы, как принято считать. Мы со-инвестируем с top-tier фондами и пристально за ними наблюдаем. И со временем начали замечать паттерны: одни и те же фонды снова и снова вместе оказываются в одних и тех же сделках. Потому что у них похожий фокус, или есть еще какая-то связь?
Мы с командой Mento VC решили проверить это на данных. Проанализировали тысячи раундов топ-36 фондов мира – и обнаружили 8 устойчивых кланов Кремниевой долины (вообще-то, 11, но при более пристальной проверке трое как кланы не подтвердились). «Кланами» мы считаем группы фондов, которые связаны не только через стартапы, в которые инвестируют, но и рабочими, дружескими и даже семейными связями. Про это не принято говорить вслух, но кто вам еще расскажет если не мы? 🙂
Читайте наше исследование ниже, а если вам интересны регулярные заметки и инсайты о венчуре, разбор наших сделок и новости рынка - добро пожаловать в мой телеграм-канал.
Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:
- Поговорим о том, когда и зачем нужен отдельный слой Policies.
- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.
- Покажу нашу архитектуру, примеры кода и способы внедрения.
- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.
- В конце посмотрим, в каких ещё системах используется аналогичный механизм.
Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸
Всем привет! Меня зовут Вардан Манучарян, я аналитик в команде Монетизации Авито, и мы отвечаем за механику алгоритмов продвижения, то есть управляем порядком, в котором пользователи видят объявления. Для этого нам нужно отслеживать, как изменения в ранжировании влияют на бизнес и покупателей. В этой статье расскажу про интерливинг, — метод, который помогает корректно проводить A/B-тесты с изменением ранжирования. Статья будет интересна аналитикам, которые проводят много A/B-тестов.
28 мая мы провели в Альпине закрытую мастер-встречу про то, как растить ИИ-компетенции в команде без миллионных бюджетов. На встречу подключились более 150 специалистов из фармы, ритейла, IT, логистики и банков. Я рассказывал про наш путь в AlpinaGPT, коллеги показывали свои кейсы в маркетинге, продажах и разработке, в зале задавали вопросы CTO и L&D-директора крупных российских компаний. После трёх часов разговоров у меня осталось одно главное наблюдение — то, ради чего я и пишу эту статью.
Меня зовут Жемал Хамидун, я CPO AlpinaGPT, Head of AI Alpina Digital и автор тг-канала «Готовим ИИшницу». Главное наблюдение простое: разрыв в ИИ-компетенциях растёт. Одни сотрудники работают с моделями ежедневно, у них уже свой стек, свои шаблоны, своя память между сессиями и встроенные в рабочий процесс агенты. Другие открыли ChatGPT один раз, написали что-то вроде «составь мне отчёт», получили шаблонный текст без контекста, решили, что инструмент бесполезный, и закрыли вкладку. Между этими двумя сотрудниками разрыв растёт каждый месяц быстрее, чем компании успевают его закрывать обучением.
Разрыв в компетенциях растёт быстрее, чем обучение его закрывает
Главная цифра, которую я показывал на мастер-встрече, — из свежего отчёта DataCamp и YouGov State of Data & AI Literacy 2026 (опрос 517 enterprise-руководителей в США и Великобритании, декабрь 2025 — февраль 2026). 82% компаний уже предоставляют ИИ-обучение для сотрудников, и при этом 59% этих же компаний сообщают, что разрыв в ИИ-компетенциях у них всё равно сохраняется. 23% опрошенных заявили, что программы обучения не адаптированы к конкретным должностным обязанностям, 21% опрошенных говорят, что сотрудникам сложно понять, с чего начать. То есть деньги в обучение пошли, программы запустили, лицензии раздали — а сотрудники в массе своей по-прежнему не владеют ИИ на нужном уровне.
На заметку всем, кто интересуется, как меняется современная разработка ПО.
Недавно Anthropic выпустил отличную статью о том, как меняется современная разработка ПО на примере трансформации подходов внутри собственной компании.
