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

Привет, Хабр! Меня зовут Александр, я DevRel команды Selena Lakehouse. Пишу про СУБД StarRocks, архитектуры Lakehouse и Streamhouse в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena).

Полгода назад термин Streamhouse начал всплывать на конференциях и в блогах. При этом многие русскоязычные источники, которые я читал, сводят его к «замене Iceberg на Paimon и обновлению Flink» или путают с обычным Lakehouse. На самом деле за Streamhouse стоит интересная архитектурная логика. Конкретный набор компонентов, где каждый решает свою задачу: Apache Flink для вычислений, Apache Fluss как горячий потоковый слой, Apache Paimon как холодное хранилище. Вместе они дают потоковый Lakehouse с задержкой в секунды вместо минут.

Мне стало интересно: можно ли на этом стеке построить полноценный аналитический конвейер? Не на слайдах, а руками в Docker Compose, с SQL и реальным сценарием.

В этой статье:

Разбор статьи из Nature о Project Silica — фемтосекундные лазеры, боросиликатное стекло и конец эпохи миграций.

Технологии децентрализованной идентификации и верифицируемых данных перешли от концепций к промышленной эксплуатации. И ключевой драйвер этого перехода – не отдельные продукты или вендоры, а стык между международными стандартами (прежде всего W3C) и адаптированными под наше регулирование блокчейн-решениями. Статья объясняет, как эти два слоя взаимодействуют на практике, где уже применяются и какие вызовы остаются на пути массового внедрения.

Лет десять назад объектное хранилище было экзотикой. Крупные компании обходились NFS‑шарами и надеждой, что RAID не развалится в самый неподходящий момент. Средний бизнес в целом не понимал, зачем это нужно. Но сегодня все изменилось. S3 API стал таким же стандартом, как REST или JSON. Мы в Диасофте построили «Фабрику данных» (Digital Q.DataFactory) в архитектуре Data Lakehouse на основе S3 Архипелаг, которая объединяет гибкость Data Lake с надежностью хранилища данных. В этой статье расскажем, как построили слой хранения.

Теперь Manticore Search поддерживает прямое указание настроек токенизации непосредственно в команде CREATE TABLE. Таким образом, исчезает необходимость создавать внешние файлы при настройке стоп-слов, исключений, словоформ и слов без позиции, делая создание таблиц проще и удобнее для развертывания.

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

Так исполнение законов подталкивает платформы к навязчивым системам верификации, которые зачастую напрямую противоречат современному законодательству о защите персональных данных.

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

Именно такой формат электронного онлайн-взаимодействия то будущее, которое готовит нам ФНС. Техническую и правовую базу АУСН я уже разбирал в статье «АУСН: налоговый оазис или цифровой концлагерь для бизнеса?». А в этой статье разберу инфраструктуру налогового мониторинга. Что этот режим представляет собой на практике, и где чаще всего «ломается» интеграция.

Представьте: вы – архитектор в растущем холдинге. У вас 12 систем, которые нужно связать: ERP, CRM, пара WMS, три базы 1С, биллинг, портал для партнёров и что-то унаследованное на Delphi, которое «работает – не трогай». Каждый месяц бизнес приносит новые требования: «нам нужна интеграция с маркетплейсом», «хотим видеть данные в реальном времени», «регулятор требует логировать всё».

И вот вы на развилке: собрать интеграционный слой на open source (Kafka + Camel + самописные скрипты) или взять проприетарную ESB-платформу? DevOps-инженеры уверяют, что «Kafka решает всё». Финдиректор намекает на «бесплатный» open source. А служба безопасности присылает очередной список CVE-уязвимостей в ваших текущих компонентах.

Знакомо? Тогда эта статья для вас. Мы разберём аргументы за и против, но не абстрактно, а с конкретными цифрами из свежего исследования «ESB Круг Громова 2025», где проанализировано более 20 платформ по 300+ критериям.

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

А если точнее то тут будет не про флешку и скорее "Вечный CD диск" который сможет хранить от 1 Тб до до 10 ПБ информации (10 петабайт – около 10 тыс. ТБ, терабайт) на срок от 500 до 100 000 лет.

За последнюю сотню лет человечество преодолело огромный путь в совершенствовании технологий хранения информации. Многие из нас ещё видели пяти- и трёхдюймовые дискеты, а некоторые даже могут вспомнить перфокарты. Но по сравнению с предыдущими технологиями мы явно выиграли в плотности информации, но на порядок потеряли в её долговечности хранения. Флешка с 16ГБ информации (2 000-5000 стандартных книг) живет не более 5-10 лет. Книга на пергаменте при хороших условиях хранения не менее 900 лет.

В феврале 2026 года электроника столкнулась с одним из самых серьезных кризисов за последние годы. Чипы NAND — ключевой элемент смартфонов, ноутбуков, автомобилей и телевизоров — стали дефицитом. Заводы работают на пределе, но объемы выпусков все равно недостаточны. Соответственно, стоимость чипов выросла кратно, поставки срываются, а компании за пределами первой десятки рискуют уйти с рынка. 

Что случилось? Тут нет сюрприза — ИИ стал главным потребителем ресурсов. Обучение моделей, их работа и хранение генерируемых данных требуют колоссального объема накопителей. Гигантские корпорации платят огромные деньги, заставляя производителей работать на себя, а потребительский сегмент в это время получает то, что осталось. Давайте попробуем разобраться в ситуации и понять, когда все наладится.

Сразу успокоим читателя: AI не вытеснил data-инженера из рабочего процесса. Наоборот, он сделал эту роль еще более значимой. И в этой статье объясняется, что именно это означает для вас и вашей профессии. Не с точки зрения технологий и инструментов, а с точки зрения изменения зоны ответственности.

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

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

Цифровые данные не рассчитаны на хранение десятилетиями, не говоря уже о веках. Жесткие диски и SSD со временем выходят из строя, архивные ленты нужно регулярно переписывать, а облачные сервисы зависят от электричества, серверов и самих компаний. На этом фоне проект Microsoft Silica предлагает другой подход — записывать информацию прямо внутрь стеклянных пластин с помощью фемтосекундных лазеров. И это не фантастика, а реальность. Команда проекта показала рабочий прототип, увеличила скорость записи и продемонстрировала, что при обычных условиях данные могут сохраняться не менее 10 тысяч лет. Давайте разберемся, что это за технология, как она работает и на каком этапе развития находится.

Привет, Хабр! Меня зовут Ольга Косарева, я инженер данных команды «Прогнозирование финансового результата» Центра разработки решений ALM в ИТ‑холдинге Т1, мы занимаемся созданием современной ALM‑системы (подробнее тут ).

Полтора года назад я пришла в команду и получила задачу дописать и внедрить инструмент для DDL‑операций над данными в экосистеме Hadoop. Моя первая реакция была: «А зачем так сложно? Какой инструмент? Почему нельзя просто выполнить команду ALTER TABLE через Hive?»

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

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

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

В начале 2025 года ФБР вручило Microsoft ордер на получение ключей шифрования BitLocker с нескольких ноутбуков. Следователи считали, что на них хранятся доказательства мошенничества в программе помощи безработным в связи с COVID-19 на Гуаме. Microsoft выполнила запрос — и передала ключи.

В 2021 году Databricks ввели в моду термин «lakehouse», и индустрия дружно решила, что это и есть будущее. Аналитики писали восторженные статьи о том, что классические DWH мертвы. Вендоры спешно проводили ребрендинг своих продуктов, а на конференциях обещали единую архитектуру, которая решит вообще любые проблемы с данными.

Некоторые обещания Lakehouse сбылись. Другие оказались лишь маркетингом. А еще всплыли проблемы, которых никто не ожидал.

В этой статье разберем честный опыт внедрения Lakehouse к 2025 году: какие обещания оказались маркетингом, почему расходы на вычисления часто растут вместо экономии, и как на самом деле выглядит прагматичная работа с Delta Lake, Iceberg и Hudi в современных проектах. Что выжило в продакшене, что тихо скончалось, а о чем принято помалкивать?

Привет, Хабр. В ноябре 2025 года наша команда выпустила релиз TROK SDS. Это программно-объектное хранилище корпоративного уровня. Первые клиентские успехи уже есть, но пока под NDA, про это расскажем чуть позже. А сегодня хотелось бы просто поразмыслить над темой хранения данных и объяснить, что и как. 

Спойлер тем, кто не хочет читать много букв: TROK SDS создавался для тех, кто не хотел и не хочет покупать дорогие аппаратные СХД или танцевать с бубном вокруг сложных решений вроде Ceph. В основе лежит синхронная репликация данных между узлами. При отказе оборудования система автоматически восстанавливает реплики без вмешательства администратора. Экономия достигается за счет работы на стандартных серверах x86_64, без специализированного железа. Управление через веб-интерфейс. Разворачивается за 40 минут опытными руками из плеч. 

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