Big Data *

В последнее время мы все чаще слышим тезис: «Классический BI больше не нужен». Ведь сегодня можно открыть чат, попросить нейронку нарисовать красивый дэшборд с фильтрами и графиками, а потом спросить, что происходит с условной выручкой. Нейронка быстро соберет интерфейс, ответит на вопрос, а в следующий раз можно вообще не использовать старый дэшборд, а просто сделать новый.

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

В этой статье попробуем разобраться.

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

Поэтому при эксплуатации DWH используют инструменты мониторинга и логирования.

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

Каждая профессиональная область деятельности должна иметь своих специалистов, говорящих на своем «птичьем» языке. Иначе, какая же она профессиональная. Язык этот не является попыткой выделиться и набить себе цену. Нет, он появляется по причине необходимости собственных устоявшихся понятий. Так формируются тезаурус и онтология. В отношении естественных языков дела обстоят еще сложнее.

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

До последнего времени в мире IT всё главным образом крутилось вокруг computer science, математики, финансов (статистики) и промышленного дизайна. Однако с появлением LLM этот, вполне себе теплый и камерный мир, где «рыбак рыбака видел из далека», начал стремительно разрушаться. Вначале, появились голосовые помощники и чат‑боты, а теперь это разрослось до новой формы поиска и попыток управления чем‑то (и да же вынесения суждений о чем‑то) в реальном мире с помощью LLM.

Привет, я Салават Динмухаметов, senior ML-engineer в команде рекомендаций Авито. В статье расскажу, как мы изменили систему рекомендаций на главной странице. 

Одна из важных частей этой системы — коллаборативная модель avitofm. Раньше она обновлялась раз в 6 часов. Проблема в том, что товары из хороших объявлений разбирают быстрее: они не успевали оказаться в рекомендациях. 

Мы решили ускорить обучение — и за несколько итераций сделали neartime-архитектуру, которая обновляется каждые 20 минут. Это повысило качество, бизнес-метрики и сэкономило память.

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

Отечественный рынок решений Data Lakehouse активно развивается: после периода пилотных проектов наблюдается массовый переход к промышленным внедрениям. Растущий спрос на такие платформы обусловлен необходимостью обрабатывать разнородные данные в условиях строгих требований к информационной безопасности.

Но нюанс в том, что реализации Data Lakehouse от разных вендоров могут значительно отличаться как на уровне архитектуры, так и на уровне доступных возможностей. Поэтому при выборе решения надо понимать, как оно устроено «под капотом».

В статье расскажем, как именно реализована наша Data Lakehouse платформа для аналитики и ML — VK Data Platform от VK Tech. 

Открытых данных по загруженности парковок в мире на удивление мало: самый известный набор охватывает 30 парковок за три месяца 2016 года. Мы полтора года опрашивали открытый API Департамента транспорта каждые полчаса и выкладываем накопленное: 4 684 084 замера по 210 муниципальным парковкам, CC BY 4.0. Внутри — схема, примеры на pandas и DuckDB и честный раздел про то, что в этих данных сломано: 39 парковок из 210 не отдают занятость вообще, а счётчик инвалидных мест однажды показал 9979 свободных мест там, где их два.

Привет, Хаброжители! Познакомьтесь с полным практическим руководством по подготовке к собеседованиям на одну из самых востребованных и высокооплачиваемых позиций в ИТ.

Авторы, ведущие архитекторы решений AWS с многолетним опытом, подробно разбирают роли архитектора широкого профиля, специализированных и отраслевых решений. Вы узнаете как успешно пройти все этапы отбора — от анализа вакансии и подготовки резюме до сложных технических и поведенческих интервью, как проектировать масштабируемые, надежные и безопасные системы, какие вопросы чаще всего задают на собеседованиях по приложениям, DevOps, инфраструктуре, сетям, большим данным, базам данных, машинному обучению, безопасности и отраслевым решениям (финансы, здравоохранение, ритейл, производство).

Привет! Это Николай Анохин из команды AI VK. В этой статье расскажу про кеширование кандидатов — подход, который делает рекомендательную систему заметно менее требовательной к железу и при этом не трогает качество выдачи. Механизм уже работает в рекомендациях VK Видео и VK Клипов.

Трём моделям, включая топовую облачную, дали задачу на 15 шагов. 27 запусков, ни одного полного успеха, и все три рапортовали о завершении, которого не было. В сети из 27 тысяч магазинов 26 моделей проверяют 10 млн фото в месяц на 4 vCPU. Пилот ИИ-ассистента на 100 инженерах не сдвинул ни одну метрику разработки.

Это не три случайных истории. Я прочитал 1352 внедрения ИИ в российских компаниях, от банковского антифрода до дронов над полями, и нашёл шесть закономерностей, которые повторяются от кейса к кейсу. Одна из них объясняет, почему модели в этих кейсах можно менять местами без потери результата.

Внутри: где ломаются агенты, почему один цех даёт 270 млн рублей в год, а платформа на 34 тысячи сотрудников пока не даёт ни одной цифры, и что спрашивать у вендора вместо «какая у вас модель».

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

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

Kwai перенесла расчёт метрик A/B-экспериментов со Spark на Apache Doris: до 145 раз быстрее при снижении потребления ресурсов на 72%. В переводе разбираем, как команда переработала размещение данных, Local Distinct, UDF, планирование и метаданные FE на кластере из 2000 BE-узлов. С примечаниями о границах сравнения и доступности оптимизаций в открытом Doris.

Реранк — самая дорогая стадия пайплайна классификации по справочнику ОКТРУ: поиск отбирает 30 кандидатов, LLM выбирает один. Я проверил, можно ли отдать этот шаг модели, которая вообще не генерирует текст, — TypeSafe Jev: она принимает состояние и типизированные вопросы, а возвращает вероятности.

Замер на 928 позициях технических спецификаций госзакупок, на одном пуле кандидатов, против gpt-oss-120b с reasoning и без него, Gemma-4-31B, Gemini 3.5 Flash Lite, 3.8 Flash и 3.1 Pro и классического кросс-энкодера Qwen3-Reranker-8B. Jev дал отличную точность, как у больших моделей, но при этом стоимость и латенси как у небольшой 8B-модели.

Привет, Хабр! По первому образованию я юрист. Успел поработать в прокуратуре и арбитражном суде, потом ушёл в ИТ и последние 13 лет занимаюсь инфраструктурой, разработкой и DevOps. Сейчас строю MLOps-платформу.

Эта биография мешает мне спокойно читать споры об авторском праве и генеративном ИИ. Юрист видит копирование чужих книг. Инженер — цепочку операций: crawler, raw storage, очистку, дедупликацию, training mix, веса, API. Между «скачали страницу» и «модель ответила пользователю» слишком много разных действий, чтобы обсуждать их одним словом «обучение».

Отправной точкой для этого разбора стала колонка Мэтта Столлера о внутренних материалах OpenAI и Microsoft. Столлер пишет прежде всего о политике и неравном применении закона. Меня зацепил другой вопрос: как тот же конфликт выглядит на уровне движения данных по ML-pipeline — и что с этим вообще может сделать инженерная команда.

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

Часто задаюсь таким вопросами:

• что будет с моими активами через 5 лет, если взять квартиру в ипотеку?

• стану ли я богаче или же беднее от этого?

• смогу ли я выплатить вообще с текущими доходами и расходами всю ипотеку?

• а если не смогу, в какой момент получу кассовый разрыв?

Ипотечные калькуляторы считают только платёж, а в Excel нужно знать тонну формул для учета всех нюансов расчетов во времени, да и наглядность в эксель сильно хромает.

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

• снимать квартиру и параллельно гасить ипотеку

• или взять жильё на миллион дороже, сразу заехать и отправлять сэкономленную аренду в досрочное погашение.

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

В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.

Звучит громко, понимаю. Поясню, откуда такая уверенность.

Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.

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

Начнём даже не с каталогов, а на шаг раньше — с того, что такое вообще Iceberg, вокруг которого последний год прыгают все вендоры.

Добро пожаловать в середину сентября 2026 года. Если вам казалось, что индустрия ИИ летит на гиперскорости в бетонную стену, то на этой неделе это поняли и сами водители спорткаров. Риски того, что технологии выйдут из-под контроля, перестали быть сюжетом для блогов и перешли в разряд экстренных совещаний.

Эта неделя подарила нам киберпанковые сюжеты: нейросети начали взламывать серверы конкурентов (буквально), автономные агенты изобретают собственные диалекты с отсылками к Джойсу, а для «спятивших» ботов теперь создают горячие линии доносов. И пока в Китае ИИ-актеры уже захватили рынок мобильных сериалов, бигтех всерьез заговорил о том, чтобы ударить по тормозам.

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

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

Такую работу удобно поручать Агенту.

Привет, Хабр. Я Игорь Юрченко, backend-разработчик Сбера. В предыдущей статье я описал автоматизацию развёртывания потоков NiFi, а сейчас расскажу о дальнейшем развитии этого подхода для интеграции с корпоративной системой управления секретами — SecMan. Буду использовать терминологию предыдущей статьи.

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

Я автоматизировал почти всю цепочку действий по фандрейзингу: сбор инвесторов из источников, отбор, отправку им сообщений через свою CRM, отслеживание ответов и вывод на звонок.

Чуть ниже описываю, как делал и какие цифры получились. Ну и где не получилось так, как мне бы хотелось.

Привет, Хабр! Я Алексей Новаков, ведущий инженер данных в Рунити. Сегодня разберемся, зачем Lakehouse понадобился streaming, почему одного Iceberg для этого не всегда хватает и как Iceberg и Paimon могут жить рядом в одном конвейере.

Если сильно упростить, классический Lakehouse решает понятную задачу: берем дешевое объектное хранилище и добавляем поверх него то, чего не хватало обычному Data Lake — транзакции, schema evolution, snapshots, SQL, update/delete отдельных строк и одновременное чтение и запись.

Но дальше возникает следующий вопрос: что делать, если аналитика должна видеть не вчерашние или часовые данные, а состояние, которое обновляется постоянно?

Именно здесь Lakehouse начинает превращаться в Streaming Lakehouse — или Streamhouse.