Хранение данных *

Битовые массивы кажутся экзотической структурой данных, которую применяют только опытные учёные мужи в специфичных сферах? Не всегда!

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

Под катом — эволюция от классических битовых массивов до современных сжатых форматов и реальный бизнес‑кейс их прикладного применения.

За последние несколько лет кадровый электронный документооборот перестал быть инструментом для отдельных новаторов.

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

В этой статье посмотрим на 6 популярных решений для КЭДО и оценим, насколько оперативно они хранят документы и есть ли у вендоров решения для архивного хранения.

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

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

На Mac с диском 256–512 ГБ место заканчивается регулярно. Обычный путь известен: найти самое большое, перетащить на внешний SSD и удалить оригинал. Если разобраться, что при этом ломается, окажется, что ломается много чего, и чаще всего тихо.

Разбираю грабли: почему сверка копии сразу после записи ничего не доказывает, что exFAT теряет при переносе, какие папки переносить нельзя вовсе, как Docker съедает диск во время архивации томов и как правильно работать с шифрованным образом hdiutil.

В этом году платить за зарубежные облака из России стало почти невозможно. С апреля закрыта оплата сервисов Apple, Google Play не принимает платежи с 2022 года, а Notion отключил российских пользователей ещё в сентябре 2024 года. В комментариях к таким новостям всегда советуют одно и то же: поднимите свой сервер и забудьте о подписках. Я решил проверить этот совет на цифрах. Поднял на своём компьютере Immich, Nextcloud, Vaultwarden и AFFiNE, замерил, сколько им нужно памяти, и сравнил стоимость за пять лет с Яндекс 360 и Облаком Mail. Цены собраны 28 сентября 2026 года. Облако выиграло не на любом объёме: есть граница, после которой свой сервер экономит до 175 тысяч рублей за пять лет. Где она проходит и почему её почти не сдвигает даже б/у железо, разберу по порядку.

Привет, Хаброжители! Джей Бортен дает подробное практическое руководство по интеграции данных — от базовых понятий и терминологии до реального сквозного примера, который шаг за шагом превращает разрозненные источники в работающий конвейер на AWS, Qlik, Databricks и Confl uent.

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

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

Привет, Хабр! Меня зовут Сергей Третьяков. Я product owner MWS Data Scout — сервиса, который описывает таблицы баз данных с помощью больших языковых моделей (LLM). 

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

Главный сдвиг — Data Catalog перестал быть просто справочником метаданных и становится инфраструктурой доверия к данным и источником контекста для аналитиков, процессов и ИИ-агентов.

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

В отчёте «Data Catalog Круг Громова 2026» - количество критериев выросло до 325. За три года рынок заметно изменился, и прежней методики стало недостаточно. В этой статье расскажем не о результатах сравнения продуктов, а о главных изменениях рынка — в том числе тех, которых мы сами не ожидали увидеть.

В первой части материала мы разобрали, что необходимо контролировать в корпоративном хранилище данных - от инфраструктуры и ETL/ELT-процессов до Data Quality и выполнения запросов:

Мониторинг и логирование DWH, часть 1: уровни контроля, метрики и типовые проблемы

Во второй части перейдем к конкретным инструментам: Prometheus, Grafana, Zabbix, ELK Stack, OpenSearch, Loki. Разберем, как они устроены, какие задачи решают, чем отличаются друг от друга и на что обратить внимание при выборе стека для мониторинга и логирования DWH.

Cloud Tracing — сервис распределённой трассировки в VK Cloud. Приложения отправляют в него спаны по протоколу OpenTelemetry, сервис хранит их и отдаёт через Jaeger-совместимое API. Поэтому трейсы можно открывать в привычных Jaeger UI и Grafana без доработок.

За этой совместимостью стоит выбор хранилища, который для публичного облака оказывается сложнее, чем кажется. Сервис принимает поток спанов от сотен несвязанных клиентов, хранит десятки терабайт телеметрии и должен надёжно изолировать данные проектов друг от друга. По умолчанию один проект может отправлять до 1 МБ/с, а доступ к данным контролируется токенами IAM. При таких ограничениях недостаточно просто выбрать базу, которая быстро записывает спаны или умеет находить трейс по trace ID.

На странице развёртывания Jaeger на момент проектирования сервиса были перечислены шесть вариантов: Cassandra, Elasticsearch, Kafka, gRPC-плагин, Badger и memory. На первый взгляд это полноценный список кандидатов. Но локальные хранилища отпадают для прода, Kafka оказывается буфером перед настоящим хранилищем, а gRPC-плагин служит способом подключить систему, которой в списке нет. В результате сравнивать приходится Cassandra и Elasticsearch, а через плагин появляется третий вариант — ClickHouse.

Я Леонид Левин, архитектор PaaS в VK Cloud. Этот разбор мы подготовили вместе с технологическим евангелистом Стасом Погоржельским и инженерами сервиса. Мы разберём, почему Cassandra и Elasticsearch по-разному подходят для хранения трейсов, что дали чужие продовые кейсы и наши замеры до 362 тысяч спанов в секунду на четырёх ядрах коллектора, а также как схема хранения на ClickHouse закрыла точечное чтение и поиск по атрибутам.

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

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

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

В этой статье я расскажу Хабру, как мы вместе с другими участниками рынка искали более надёжную конструкцию и пришли к схеме на основе Oblivious Pseudorandom Function (OPRF), предотвращающей отслеживание пользователя по его номеру.

Обычное утро администратора Nexus: вместо списка артефактов — красный баннер. Запись заблокирована, сборки не грузятся, пайплайны падают. Если такое происходит не на тестовом стенде, а в проде — это кошмар. Особенно в большой компании, где таких инстансов десятки, и каждый — критический элемент разработки.

В статье расскажу, как жесткие лимиты со стороны Nexus подтолкнули нас к миграции на собственное решение, как мы организовали переход «со звёздочкой» — без переучивания разработчиков, без перестройки CI/CD и с гарантией отката на старый Nexus, от которого сделан форк — и на какие грабли наступили.

Привет, я — Иван Засухин, DataOps Лаборатории искусственного интеллекта департамента больших данных Россельхозбанка. Мы одна из команд платформы RAISA (RSHB AI Systems and Applications), отвечаем за инструменты, которые связаны с данными и их обработкой: Оркестрация (Apache Airflow), Compute( Apache Spark и Apache Trino), Хранение (S3 и Qdrant), интерфейсы взаимодействия с источниками данных (python‑модули и кастомные операторы). В команде я занимаюсь развитием инструментов и их дальнейшим сопровождением.

Как эффективно заменить MinIO, если это одно из главных объектных хранилищ команды и ИИ‑платформы большого банка? В этой статье поделюсь результатами двух этапов тестирования S3-совместимых хранилищ. Сравнивали три решения: коммерческую российскую разработку «Закрома», опенсорс‑решения RustFS и SeaweedFS. Тесты проводились на реальных стендах с нагрузками, приближенными к боевым. Спойлер: однозначного победителя нет, но у каждого кандидата есть четкие сценарии применения. 

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

Большинство экспертов, наставников, онлайн‑школ при запуске своего курса/обучения думают о том, как получить ту конверсию заявок и учеников, которые они поставили себе как цель. Думают также о своем продукте и его качестве, чтобы ученики получили и были довольны своими результатами. И совсем забывают обезопасить свой запуск с юридической стороны. Как итог: несут колоссальные убытки.

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

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

Спор о формате таблиц для lakehouse, похоже, закончился, Iceberg сегодня поддерживают Trino, Spark, ClickHouse, Snowflake и дальше по списку, так что следующим приходится выбирать каталог. Каталог хранит указатель на актуальную версию таблицы, проводит commit и решает, кому эту таблицу читать, поэтому по весу я бы поставил этот выбор рядом с выбором СУБД.

В статье разбираю Lakekeeper, это один бинарник на Rust и обычный Postgres для метаданных, права на OpenFGA до отдельной таблицы и механизм ContractVerification, который может отклонить commit, если тот ломает контракт данных. Для сравнения рядом Apache Polaris, проект фонда Apache на Java с RBAC в два уровня и федерацией внешних каталогов.

В конце описан стек из банковского проекта (RustFS, Lakekeeper с Postgres, SeaTunnel, NiFi, Trino и ClickHouse), который развернули на своём железе за три дня и через три недели вывели в тестовую эксплуатацию.

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

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

Привет, Хабр! Разбирать вопросы после эфиров — полезная практика. В чате трансляции часто поднимают темы, с которыми инженерам приходится сталкиваться на пилотах и в продакшене.

На вебинаре Хайстекс про восстановление в гибридной и мультиоблачной среде мы разбирали сценарии катастрофоустойчивости. Из обсуждения в чате получился список практических тем: оркестрация, гибридное хранение, защита от шифровальщиков и совместная работа с действующей СРК.

Под катом разбор этих тем и линк на демо.