Big Data *

Меня зовут Антон Чикин, я руковожу отделом интеллектуального анализа в «Инфосистемы Джет». В статье я попробую показать на практическом примере, почему корпоративный ИИ нельзя свести к установке готовой LLM — и что именно приходится выстраивать вокруг неё, чтобы получить реальную ценность для бизнеса.

Этот материал будет полезен тем, кто отвечает за внедрение ИИ в компаниях среднего и крупного масштаба: ИТ-директорам, архитекторам корпоративных систем, специалистам по информационной безопасности и тем, кто рассматривает генеративный ИИ как инструмент автоматизации бизнес-процессов.

Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.

GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.

Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.

На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:

От чат-ботов к цифровым близнецам, от промптов к протоколам — что ждет нас через 12 месяцев, и почему ваша ментальная модель ИИ безнадежно устарела.

2025-й был годом хайпа. Мы все научились писать промпты, восхищались Sora, DeepSeek, Chat GPT-5 и спорили, отнимет ли ИИ наши работы. 2026-й будет годом, когда хайп умрет, а на смену ему придет суровая, неудобная и стремительная реальность.

Забудьте про ИИ как про инструмент. В 2026-м ИИ окажется средой. Воздухом, которым дышит цифровой мир. И мы все в ней — не операторы, а обитатели, вынужденные вырабатывать новые инстинкты выживания. Я называю это эрой «Цифрового Шизофреника» — состояния, когда грань между человеческим и искусственным интеллектом настолько истончится, что наш мозг будет постоянно метаться между мирами.

Тезис: К концу 2026 года мы столкнемся не с одной, а с тремя взаимосвязанными революциями, которые перевернут все: от кода до культуры.

Если вы работаете с аналитическими базами данных, то наверняка слышали о Greenplum — одном из самых мощных MPP-решений (Massively Parallel Processing) на базе PostgreSQL.
Однако в последние годы в экосистеме PostgreSQL появилось новое имя — Apache Cloudberry.

На первый взгляд, это ещё один форк Greenplum.
Но на деле Cloudberry — переосмысление архитектуры MPP-СУБД, выполненное с уважением к наследию Greenplum, но с современным кодом, ядром PostgreSQL 14+, открытым управлением через Apache Foundation и амбициозной целью стать по-настоящему открытой аналитической платформой уровня DWH.

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

В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.

Как потратить почти полмиллиона долларов, чтобы собрать в центре Сан-Франциско хранилище данных объёмом 30 петабайт

Мы собрали в центре Сан-Франциско центр для хранения данных с общим дисковым пространством, где хранятся видеоданные общей длительностью 90 миллионов часов. Зачем? Мы предобучаем модели, чтобы разобраться с использованием компьютеров. Дело в том, что видео гораздо крупнее, чем текстовые данные. Например, на обучение такой текстовой БЯМ как LLaMa-405B требуется ~60 ТБ текстовых данных, а на хранение видео нужно в 500 раз больше текстового пространства. За хранение всей этой информации на серверах AWS пришлось бы выложить 12 миллионов долларов в год, поэтому мы пошли другим путём и арендовали пространство в колокационном центре в Сан-Франциско. Так нам удалось снизить эти расходы примерно в 40 раз (до $354 тысяч в год, считая издержки на устаревание).

Эксперты Gartner дают краткие ответы на свежие вопросы клиентов о перспективных технологиях.

Фокус на принятии решений: когда инвестировать в агентный ИИ и DSLM, какие метрики измерять и как масштабировать без потери контроля.

Каждый разработчик знает, насколько важны структуры данных. Без них не обходится ни один серьезный проект, будь то оптимизация запросов, работа с Big Data или просто написание чистого и эффективного кода. Не зря же на собеседованиях постоянно спрашивают про деревья, хеш-таблицы и сложность алгоритмов!

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

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

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

Бизнес-аналитику чаще внедряют в облаке или гибридной инфраструктуре. Но что делать, если по требованиям безопасности выход интернет недоступен, а BI‑система должна работать только внутри корпоративной сети?

Эта статья будет полезна архитекторам, DevOps‑инженерам и администраторам, которым нужно развернуть BI‑платформу в изолированной среде. На примере Modus BI мы разберём ключевые технические трудности и покажем решения, проверенные в реальных проектах.

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

Помните свой первый «вау‑эффект» от LLM?

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

Что, если Greenplum пережил перерождение?
Новый проект Greengage DB возвращает PostgreSQL в большую игру — теперь с авто-масштабированием, чистым ядром и реальной совместимостью.
Разбираемся, почему этот форк может стать «Linux для аналитики».

Как использовать ML-модели, чтобы не просто анализировать пользователей, а управлять их поведением — предсказывать отток, оценивать эффект от акций и подбирать оптимальные воздействия.

В этой статье я собрал три типа моделей: прогнозирование поведения, uplift-модели и выбор оптимального воздействия. Давайте разбираем, как они устроены и где реально приносят пользу.

Сегодня многие организации работают на базе решений из семейства 1С. Но для того, чтобы получить развитые практики BI – то есть реализовать полномасштабную аналитику для принятия управленческих решений на базе данных из 1С, всегда нужно было принимать немало дополнительных усилий. Все потому, что встроенные в платформу технологии не позволяют добиться уже привычного уровня гибкости, а использование промежуточных структур несет в себе ряд технологических неудобств. Все это стало причиной появления собственного коннектора Visiology к 1С.  В этой статье мы рассказываем о том, какие проблемы возникают при попытке настроить автоматическую аналитику на базе 1С, и как новый компонент платформы Visiology помогает решить их все в комплексе.

Представьте: Один неоптимизированный запрос от неопытного коллеги - и вот уже 40 ТБ SPILL-файлов парализуют систему.

Срабатывает лимит на уровне Greenplum, запрос завершён. Никто ничего не знает.

Создаются заявки, пишутся письма, пользователь недоволен.

Это не какая-то выдуманная история, а обычный будний день в большом Greenplum. Вернее, так было раньше.

Представьте: ваши дашборды, от которых зависят ежедневные решения, внезапно перестали обновляться. Скрипты интеграций сломались, а поддержка отвечает шаблонными письмами. Знакомая ситуация? После ухода Qlik, Tableau и других игроков многие российские компании оказались в аналитическом вакууме. Мы прошли через это же и в ответ создали Sigla Vision. В этой статье я покажу, как мы решали технические вызовы, с которыми сейчас сталкиваетесь вы.

Привет, Хабр! Меня зовут Алексей Солдатов, я выпускник магистратуры «Системный анализ и математические технологии» НИУ ВШЭ. Хочу поделиться с вами опытом исследования атак на модели машинного обучения под руководством Павла Литикова, архитектора ИБ-подразделения AI VK, в рамках мастерской по безопасности ИИ в Инженерно‑математической школе НИУ ВШЭ и VK.

Модели машинного обучения сегодня применяют в самых разных сферах жизни людей. Однако вопросы безопасности зачастую остаются на периферии внимания разработчиков и инженеров. Для компании VK, в инфраструктуре которой функционируют тысячи ML-моделей, особенно актуальна задача автоматизации и упрощения процессов обеспечения их безопасности.

Наша команда продолжает работу над проектом RnD OSS-инструментов для MLSecOps, целью которого является систематизация открытых инструментов и подходов к обеспечению безопасности систем машинного обучения. Сейчас мы сосредоточены на изучении и воспроизведении атак различной природы на ML-модели. В рамках экспериментов протестировали инструменты для атак на модели разных модальностей: текстовых, табличных, визуальных и аудиоданных. Средства защиты планируем рассмотреть на следующих этапах проекта. Этот материал — промежуточный обзор задач проекта, его структуры и первых полученных результатов анализа атакующих подходов.

Привет! Меня зовут Влад, я DWH-инженер в Циан. Занимаюсь проектированием витрин и пайплайнов для доставки данных в корпоративное хранилище. В этой статье хочу поделиться опытом применения методологии Data Vault на Greenplum.

Data Vault часто упоминают рядом с Kimball и Inmon, но практических материалов по его внедрению заметно меньше. Для инженеров, которые только начинают строить DWH или думают о переходе на Data Vault, я собрал практический разбор: на каких задачах методология действительно помогает, с какими трудностями можно столкнуться и как это выглядит в реальном проекте.

Привет! Вчера вышла отличная статья от Себастьяна Рашки, которая детально разбирает основные способы оценки LLM-моделей. Глобально их можно разделить на 4 категории: оценка по бенчмаркам, использование верификаторов, лидерборды и LLM-as-a-judge.

Для каждого метода есть описание и код реализации с нуля, которые отлично показывают, что под капотом у каждого из методов оценки. И такой материал заслуживает того, чтобы быть на русском языке, поэтому я сделал качественный перевод, включая ключевые картиночки. Объёмные блоки кода скрыты за спойлерами, основные схемы переведены — если вы интересуетесь оценкой LLM (ее еще называют evals), то будет интересно.

Важное уточнение: статья позиционирует себя как «создание с нуля» (from scratch), и для этой цели она отлично подходит. Однако, будучи глубоко погружённым в эту тему, я посчитал многие моменты достаточно базовыми. Поэтому финальные выводы с radar-диаграммой и таблицей плюсов-минусов я вынес в самое начало — это отличный способ быстро освежить знания и систематизировать понимание для тех, кто уже глубоко в теме. И продублирую идею о том, что в реальной жизни под конкретную задачу стоит создавать свой бенчмарк и замеряться именно на нем.

В остальном — из песни слов не выкинешь, всё переведено как в оригинале, и это действительно отличный материал. Дальше будет именно он.