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

Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации. 

Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных). 

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

Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.

Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре. 

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

Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».

Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.

Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».

Мысль написания такой статьи зародилась по итогам обсуждений на форуме iXBT вопроса о том, как организовать хранение в домашних условиях некоторого количества личной информации. Статья "LLM free", все картинки и текст - органического происхождения ;)

Начнем со вводных параметров:

• есть желание сохранить на длительный срок (для конкретности берем 40 лет) данные, при этом сведя к возможному минимуму вероятность их утраты;

• данные включают в себя — электронные копии документов, семейные фото, видео. У них есть особое свойство — в случае утраты всех копий восстановление невозможно. Это не фильмы или музыка, которые можно найти в Сети и скачать повторно. Объем данных, по результатам опроса знакомых и коллег — не превышает 1 терабайта;

• человек, озаботившийся сохранением данных — не профессиональный сисадмин, и возможно — даже не связан с IT, поэтому написанием скриптов, постройкой СХД, и установкой в кладовке ленточной библиотеки заниматься не будет, все инструменты должны быть доступны простому обывателю и...;

• ...не требовать чрезмерно много расходов, в идеале — как говорит нам ТРИЗ, «объекта нет — а задача выполняется».

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

Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. Сегодня мы наблюдаем очевидную тенденцию. Серверные комплектующие становятся все более ориентированными на ИИ-нагрузки и энергоэффективными. Рекордные объемы хранения и новые стандарты сетей это подтверждают. Например, в июле вендоры выпустили вместительные HDD-диски на 30 ТБ и высокопроизводительные ИИ-ускорители. Подробнее о каждой новинке — в статье. 

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

Сегодня я расскажу про Buffalo LinkStation LS220D — недорогой NAS на два HDD, который я купил с серьезной поломкой, починил и теперь активно использую. Разберем возможности системы, скорость работы, интерфейсы, совместимость, шум и, конечно, поговорим о недостатках. Ну а в комментариях рассказывайте о своих NAS — офисных или домашних. Думаю, многим читателям Хабра будет интересно.

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

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

Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.

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

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

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.

Новички убивают свое хранилище плагинами. Чтобы этого не было, нужно уметь работать в Obsidian — программе, крайне коварной в своей простоте.

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

Хранение 1 ГБ данных в облаке стоит от 2 до 12 рублей. Можно ждать, пока диски подешевеют, а можно сжать данные и получить «бесплатный» апгрейд хранилища. Но если вы храните данные в облаке, сжимать все подряд — как пытаться загрузить стиральную машинку не глядя: льняные брюки могут сесть в 5 раз и освободить место, но если кинуть в барабан кирпич, меньше он не станет, зато вы получите грохот, счет за электричество, недовольных соседей и возможно — сломанную машинку. 

Чтобы не потратить кучу CPU с сомнительным результатом, мы у себя в команде R&D Cloud.ru решили исследовать, как сделать сжатие оптимальным, чтобы не тратить время на упаковку того, что сжатию не поддается и эффективно расходовать вычислительные ресурсы.

Я Александр Аксенов, мой профиль — оптимизация хранения данных и мне есть что вам рассказать про то, как ускорить процесс сжатия до 80 раз, сэкономить CPU и сохранить качество. Звучит как кликбейт (так оно и есть 😃), но почему это технически правда и может пригодиться вы узнаете из статьи. Надеюсь, мои выводы окажутся полезными всем, кто работает с данными, в особенности инженерам СХД, DevOps, разработчикам распределенных систем и архитекторам облачных решений.

Подсесть на облачные сервисы довольно просто. Сначала берешь 5 ГБ в iCloud чисто для резервных копий, потом соглашаешься на семейный тариф на 200 ГБ, и вот через год уже и сам не понимаешь, как решаешься на ежемесячную оплату терабайтного пространства. Хуже всего, что с течением времени данных, которые ты просто не можешь удалить, становится только больше. Поэтому плата за хранение собственных файлов на чужих серверах становится только выше. При этом скорость загрузки ограничена интернет‑каналом, доступ к данным зависит от работы сервиса, а вопрос сохранности накопленных годами фотографий остается исключительно на усмотрение корпораций. А ведь они могут просто взять и закрыться или отказать в обслуживании, так сказать, по «географическому признаку». Логичным решением этой проблемы становится собственное сетевое хранилище. Именно об актуальных моделях этих устройств мы поговорим сегодня.

RDMA — аббревиатура, достаточно известная благодаря частым упоминаниям в технических статьях и спецификациях на оборудование. Многим, скорее всего, известно, что означает она Remote Direct Memory Access или прямой доступ к памяти на удаленном хосте. Но что скрывается за ней на самом деле? В чем суть этой технологии, особенно в контексте систем хранения данных? Давайте разберемся в этом. Тем более, что поддержка данной технологии недавно появилась в СХД Qsan.

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

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

Материал будет полезен инженерам, которые проектируют архитектуру обмена данными, DevOps-специалистам, отвечающим за эксплуатацию, и разработчикам, которым важно предсказуемое поведение стриминга на продакшене. Погнали!

Что делать, если хранилище захламлено? Подскажем как быстро сортировать хранилище с большим количеством заметок, картинок и документов.

Без плагинов! (ну пару упомяну удобных)

Полагаю, вам из разных утюгов уже поорали, что вы обязаны брать согласие на обработку персональных данных (ПДн). Что ж, правильно орут, ибо и правда надо, но не всегда.

Что такое вообще это согласие?

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

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

Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.

В работе с публичными облаками много плюсов, но с точки зрения ИБ — есть свои риски по сравнению с on‑premises. Минимизировать их помогает выделенный Security Operation Center (SOC). При этом создать его у себя не так просто: для эффективной работы SOC в Yandex Cloud понадобилось несколько лет разработки, а также технологии и мощности Яндекса, которые развивались годами.

Поскольку у клиентов облака не всегда есть ресурсы и экспертиза, чтобы создать подобный SOC у себя, мы не только строили свой центр, но и параллельно делали на его основе управляемый сервис Yandex Cloud Detection & Response (YCDR). В процессе разработки мы должны были позаботиться о том, чтобы даже привилегированные учётные записи не могли обойти семь слоёв облачной безопасности, — и в итоге многие компоненты написали самостоятельно.

— Первая часть статьи для тех, кому важны механизмы безопасной изоляции ресурсов. Покажем, как мы строили SOC c учётом особенностей облачной защиты.

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

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

Вы можете игнорировать и отрицать это, но за несоблюдение правил платить штраф всё равно придётся.

Есть альтернативный вариант — доработать свой сайт и в разы снизить риски проблем с законом.

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