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

Когда вышел DuckDB 1.0, я написал статью Всё что нужно знать про DuckDB. Теперь вышел DuckLake v1.0 — LakeHouse-формат из той же экосистемы. Это отличный повод разобраться, как он устроен и как его можно использовать в production-сценариях.

В этой статье разберём, какую проблему решает DuckLake, чем его архитектура отличается от Apache Iceberg и как поднять DuckLake локально или в окружении, приближённом к production: PostgreSQL для каталога метаданных и S3/MinIO для файлов данных.

В нашей компании исторически сложилась децентрализованная модель управления данными. Каждая из бизнес-вертикалей развивала собственные аналитические системы и хранилища, выбирая технологии и инфраструктуру независимо. В результате сформировался ландшафт из разрозненных решений с дублирующей функциональностью и растущим числом физических кластеров. На момент принятия решения о переходе в облако инфраструктура насчитывала более 10 отдельных железных кластеров под Airflow, Hadoop и смежные технологии. Совокупный объём аналитических данных достиг 0,5+ эксабайта (EB). 

Такая архитектура создавала не только технические, но и бизнес-ограничения. Обмен данными между вертикалями был затруднён: мешали как различия в инфраструктуре, так и юридические тонкости, связанные с оформлением доступа. Поддерживать такой ландшафт становилось всё сложнее. Поэтому в компании решили построить единую платформу для работы с данными, чтобы увеличить скорость и качество принятия решений на основе данных как в runtime, так и в отчётности и А/Б-тестах. 

Я Василий Ципиди, операционный руководитель OneDWH VK. Вместе с техническим руководителем OneDWH VK – Олегом Виноградовым расскажем сегодня о том, как мы подошли к миграции 0,5+ EB данных на единый облачный стек, какие архитектурные решения выбрали, чтобы обеспечить целостность данных и как перестроили процессы, чтобы гарантировать предсказуемость SLA на новых мощностях.

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

Это вторая часть цикла про заметочник, который я пилю по вечерам (и ночам). В первой я рассказал, как терял заметки где‑то между Notepad++, Trello, OneNote и Obsidian, — а сейчас расскажу, как собираюсь их находить.

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

Приходится постоянно полагаться на традиционную документацию, спецификации по загрузке данных или Source-to-Target mapping-файлы. Эти артефакты, как правило, быстро устаревают, не отражая актуальной логики преобразований, зашитой в ETL-процессах и SQL-коде. В результате необходимо вручную поддерживать актуальность такой документации, или, что ещё ресурсозатратнее, проведить реверс-инжиниринг тысяч строк SQL-кода хранилища данных для понимания реальных зависимостей. 

Эти проблемы обостряются в контексте постоянных изменений ИТ-ландшафта, например, миграции в облако, замены устаревших систем-источников (legacy systems) или интеграции новых платформ. И если нет понимания «жизненного цикла» данных, то это превращается в прямую угрозу для бизнес-непрерывности. Критичной задачей становится безопасное и контролируемое переключение существующих решений — витрин, дашбордов и отчётов — на новые источники данных при строгом условии минимизации или полного исключения влияния на конечных потребителей.

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

- Какие витрины и отчёты зависят от этого источника? 

- Какие преобразования данных необходимо проверить или перенастроить?

- Откуда в новой системе взять актуальные и корректные данные?

Мы рассмотрим, как с помощью применения больших языковых моделей (LLM) для автоматического анализа SQL-кода и ETL-логики извлечь точный Data Lineage.

Привет, читатели Хабр!

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

Аналитика DWH всегда казалась мне чем‑то интересным, но недосягаемым. Я видела её со стороны — через вакансии, которые закрывала, через людей, которых нанимала. И в какой‑то момент пришло понимание: хочу не просто искать таких специалистов, а стать одной из них.

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

Звучит как успех? Да. Но на деле я столкнулась с неожиданной проблемой — потерей вектора развития. В новой сфере было непонятно, как реализовать свой управленческий потенциал и куда двигаться дальше. Технические сложности — это было трудно, но решаемо. Главная трудность оказалась в другом: отсутствие четких и осязаемых перспектив роста.

Заказывая бэкап облака, компания незаметно отдаёт наружу три вещи: доступ к данным, ключи шифрования и место хранения. Разбираю по пунктам, как вернуть контроль над каждой - end-to-end шифрование с закрытым ключом только у клиента, запись копий в свой S3, NAS или СХД на территории РФ, запирание выпуска сертификатов на роль owner - и как эта архитектура закрывает требования ФЗ-152. В конце - чек-лист, по которому имеет смысл проверять любой такой инструмент.

В связи с переездом перебирал дома старые коробки и нашёл NVIDIA Jetson Nano Developer Kit — сын всерьёз занимался робототехникой. Зная, сколько это стоило в своё время, решил поискать, куда его можно применить. Заодно проверил, насколько AI‑инструменты реально ускоряют такие проекты — не в маркетинговом смысле, а по факту.

У меня постоянно переполнялся аккаунт Google, поэтому возникла идея сделать локальное хранилище на базе Jetson. Провёл поиск похожих проектов и понял, что это реализуемо. Доступ к домашнему ресурсу из интернета организовал через имеющийся VPS.

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

«Bad CaRMa» — глава из Dreaming in Code Скотта Розенберга (каламбур на CRM и «карму») про CRM-систему Vision в компании Upstart. Архитектор задумал предельно гибкую схему: одна-единственная таблица DATA, куда сложили все 150+ бизнес-сущностей — 240+ колонок с именами вроде string82 и numeric31, метаданные и данные вперемешку. Схему ведь больше «никогда не придётся менять».

В этой статье я подготовил обзор широко известной и доступной в продаже микросхемы Flash NAND памяти GD5F1GQ5xExxG. Согласно маркировке, это микросхема энергонезависимой NAND-памяти GigaDevice емкостью 128 МБ с доступом по интерфейсу SPI. Во второй части я расскажу, как установить на эту микросхему LittleFS — отказоустойчивую файловую систему, разработанную специально для микроконтроллеров.

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто.

В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы.

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

В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях.

Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

Привет! Меня зовут Дима Левин, сейчас я работаю системным аналитиком в Петрович-Техе. Так уж сложилось, что в своей работе в нескольких проектах я плотно работал с персональными данными. Сегодня хочу рассказать о проекте по автоматизации обезличивания большой БД (30 000+ таблиц размером до 10 миллиардов строк). Надеюсь, мой опыт будет полезен.

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

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

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

Хабр, привет! На связи Антон Ботвинников, директор по продукту SDS TROK. 

S3 — модное слово. Его вставляют в питчи, роадмапы и презентации так часто, что даже человек, который не до конца понимает технологию, умудряется звучать убедительно, называя это вслух. Мы тоже решили быть в теме и в новом релизе SDS TROK добавили поддержку S3. Очень просили заказчики. Хочу рассказать, что получилось. 

Qdrant — это векторная база данных, которую используют для поиска похожих текстов, изображений и других объектов. Например, Qdrant часто применяют в чат-ботах, RAG-системах, рекомендательных сервисах и приложениях на базе искусственного интеллекта.

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

Раз в пару месяцев в любом железном чате кто-нибудь да спрашивает, сколько ещё протянет его SSD и не пора ли паниковать. Обычно такие вопросы задают после того, как паникёр открыл CrystalDiskInfo, увидел там цифры TBW, которые сверил с даташитом, и загрустил. Логика вроде железная. Ресурс у флеша конечный, ячейки безбожно изнашиваются, а значит, рано или поздно диск попросту сотрётся в труху, и следить за ним надо начинать ещё вчера. Но на практике почти вся эта цепочка разваливается. Твердотельники изнашиваются совсем не так быстро, как пугает даташит, а умирают SSD чаще по совсем другой причине.

Компания «Нанософт», ведущий российский разработчик САПР/ТИМ-решений, объявляет о выходе нового программного продукта для хранения и визуализации данных 3D-сканирования – PointCloudVault.

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

PointCloudVault – серверное решение для создания корпоративной инфраструктуры хранения данных лазерного 3D-сканирования. Продукт предназначен для проектных и изыскательских компаний, предприятий промышленности и строительства, а также других организаций, которым необходимо надежное и масштабируемое хранилище больших массивов данных.

Ключевые возможности

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

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

основные идеи по организации, структурированию и системному управлению знаниями и потоками знаний внутри компании / проекта / стартапа с учетом активного взаимодействия AI и людей в ежедневной рутине.

Артефакт нашей сборки — не бинарник, а код вместе с терабайтами рассчитанных таблиц. Рассказываем, как из штатных фич Airflow, Spark и Delta Lake у нас собрался настоящий CI/CD для данных и моделей — с релизами, стейджем и откатами. И почему кнопку «выкатить в прод» жмёт дежурный data scientist, а не инженер данных.

Привет, Хабр!

До этого я сравнивал интересные мне хостинги примерно раз в год — не видел смысла делать это чаще. После недавнего сравнения российских VPS/VDS-хостингов прошло не так много времени, но появился повод вновь вернуться к этой теме. А именно, в комментариях вполне ожидаемо спросили «а где остальные крупные игроки?», да и в личку написало несколько представителей компаний с предложением протестировать их услуги. Поэтому пока старые цифры не остыли, по просьбам трудящихся решил добавить к результатам тестов ещё несколько компаний, которые мне показались интересными. 

Под катом — результаты тестирования уже 9 серверов от следующих компаний: трёх новых (FirstVDS, AdminVPS, Рег.ру) и 6 старых (Timeweb, RUVDS, CLO, AEZA, VDSina и Selectel). Теперь, когда результатов стало больше, можно не только посмотреть на новичков, но и оценить, насколько они меняют в целом общую картинку.