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

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

 Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.

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

Как появилась задача

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

Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.

Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.  

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

• Отсутствие контроля структуры и содержания документа.

• Проблема совместимости файлов и форматов.

• Отсутствие единого хранилища и версионированию.

• Замедление согласования из‑за отсутствия интеграции с системами электронного — документооборота.

• Дублирование документов.

• Сложность с отчетностью и аудиторскими проверками — документы, в т.ч. архивные, не хранятся централизованно.

• Дополнительные затраты для обучения персонала и поддержке нескольких систем.

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

Рассмотрим конкретный бизнес‑сценарий, когда административно‑хозяйственному отделу (АХО) нужно закупить мелкое оборудование для ремонта офиса.

Рынок SSD-накопителей прямо сейчас переживает непростое время. С одной стороны, далеко не все еще поняли, есть ли смысл переходить с PCIe 4.0 на PCIe 5.0. А с другой, производители уже демонстрируют твердотельники следующего поколения с еще более высокой пропускной способностью. Получается парадокс: технология развивается быстрее, чем у массового потребителя появляется реальная потребность в ней. Но это не значит, что PCIe 6.0 не нужна никому. Напротив, очень даже нужна.

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

Я Евгений Прочан, в платформенной команде 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-специалистам, отвечающим за эксплуатацию, и разработчикам, которым важно предсказуемое поведение стриминга на продакшене. Погнали!

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

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

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

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

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