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

Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.

С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций. 

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

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

Всем привет! Меня зовут Иван Привалов, я разработчик в команде BI Авито Финтеха и в этой статье расскажу, как мы сделали FIFO-сопоставление между N начислений и M списаний для бонусов. Заодно покажу подвох, без которого SQL быстро превращался в тыкву.

Статья будет полезна аналитикам и data-инженерам уровней мидл+, которые работают с финансовыми данными в Trino, Presto и Spark SQL.

Сквозная аналитика для B2C: связать клик в рекламе с оплатой и посчитать ROMI. Ядро MVP (реклама + веб + биллинг в Google Sheets, дашборд в BI) собирается за две недели с Claude Code. А честные цифры - атрибуция, когорты, грабли API - занимают месяцы и требуют головы, не LLM.

Запись вернула ошибку, но значение всё равно оказалось в базе. Именно такие сбои Jepsen вытаскивает из распределённых систем: в статье разбираем реальный баг CockroachDB, путь от странного симптома до причины и то, почему на расследование ушло два месяца.

Я работаю в компании GlowByte, а в целом в ИТ – более 20 лет. В последние годы в основном занимаюсь проектами и решениями в области AI, аналитики, больших данных, но приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков. По роду деятельности мне приходится много заниматься подготовкой, оценкой, запуском ИТ-проектов. Очень часто нормально проведенное предпроектное обследование становится залогом успешного проекта, поэтому решил, что мои мысли про предпроект, его цели и подводные камни могут быть интересны аудитории. 

Каждая команда аналитики рано или поздно сталкивается с одной и той же проблемой: SQL-скрипты начинают жить своей жизнью, lineage оказывается неполным, ручные расчеты теряются в ноутбуках и Python-файлах, а любое изменение в базе данных превращается в потенциальную аварию. Мы долго искали инструмент, который позволил бы хранить данные как код, автоматически управлять зависимостями и при этом не требовал построения очередного сложного зоопарка из Airflow, dbt и десятка вспомогательных сервисов.

В этой статье я расскажу о нашем опыте внедрения SQLMesh поверх ClickHouse: как мы получили воспроизводимые расчеты, изолированные окружения для разработки, автоматический backfill, lineage для ручных отчетов через seeds и почему в некоторых сценариях SQLMesh оказался удобнее привычного dbt. Разберем реальные примеры моделей, окружений и практические кейсы, с которыми столкнулись в работе.

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

В этой статье я познакомлю вас с реализацией бэкенд-сервиса, который решает эту проблему элегантно: S3 отвечает за хранение и отправку данных, а мое приложение — за проверку прав и генерацию одноразовых, короткоживущих ключей доступа (Pre-signed URL). Я разберу архитектуру решения, покажу, как настроить безопасное разграничение доступа между публичными и приватными объектами, а также продемонстрирую механизм, который позволяет клиентам скачивать файлы напрямую из хранилища, минуя сервер приложения.

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

Привет, Хабр! На связи команда Jay Guard — платформы, которая помогает безопасно использовать языковые модели и ИИ-агентов.

Недавно мы опубликовали статью про AI-агента для HR-процессов. В комментариях почти сразу появились вопросы про данные — куда уходят персональные данные, что из этого видит LLM, что пишется в логи (журнал событий) и как все это соотносится с требованиями ИБ, 152-ФЗ и внутренними регламентами.

Хорошие вопросы, и их можно дополнить. Персональные данные — это лишь один класс рисков. У агентных систем есть и другие уязвимости, которые важно учитывать при проектировании и эксплуатации. О них и поговорим.

А в конце статьи приготовили для вас практический чек-лист: можно пройтись по нему перед запуском агента и проверить, что уже закрыто, а что еще нет.

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. 

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

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

На рынке сейчас великое множество предложений VPS/VDS, но все они продают примерно одно и то же. Схожие конфигурации, обилие доступных образов ОС, возможность выбора ЦОДа — всё это есть у большинства современных хостингов. А вот стоимость за одинаковые услуги может значительно отличаться.

Под катом я постарался выяснить, насколько разница в цене оправдана на практике. Для этого я протестировал несколько серверов у популярных хостингов (Timeweb, RUVDS, CLO, AEZA, VDSina и Selectel) в средней ценовой категории, с максимально схожими конфигурациями (CPU 2, RAM 4 и SSD / NVMe).

Мы уже писали о том, как правильно смигрировать ЦОД: на что обратить внимание при планировании миграции и проектировании целевой архитектуры (тут и тут), как осуществить сам переезд максимально безболезненно (тут).

Теперь расскажем о том, как это бывает в реальной жизни – история одного проекта миграции глазами руководителя проекта. Человек с богатым, более чем 10-летним опытом, с сертификатом PMP и десятками реализованных проектов за плечами – казалось бы знает об управлении проектами все. Однако реальность показывает, что абсолютно все предусмотреть невозможно.

Как собрать 247 PDF медицинских выписок за 12 лет в локальный SQLite-архив и научить LLM-агента готовить из них проблем-лист для врача. Схема БД, pdfplumber + OCR, параллельные суб-агенты, дисциплина против галлюцинаций.

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

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

Western Digital в конце мая представила то, что можно считать первым в отрасли шагом к реальной интеграции постквантовой криптографии прямо в железо жестких дисков. Что именно? Новый жесткий диск, конечно, а чего вы ожидали? Свежие модели серии Ultrastar уже проходят тестирование у крупных заказчиков. Давайте разбираться, что у нас тут за технология.

OpenMediaVault, бот в Telegram и проблема с провайдером, которую пришлось решать через собственный десктоп.

Привет! Я — Аля, старший продакт-менеджер выделенных серверов в Selectel. Этой весной я побывала на экскурсии в CERN — и там я узнала, что за все время работы коллайдера на лентах архива накоплено более эксабайта данных. И это только то, что прошло фильтрацию — 99,99% уже было отброшено. 

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

В этом тексте я произвел обзор микросхемы SPI-NOR FLASH памяти MX25L6433F.
Показан код, который позволит запустить на микросхеме файловую систему LittleFS.

Предлагаем вашему вниманию пошаговый мануал, позволяющий за 15 минут из «чистого» инсталла получить рабочий кластер SpaceVM с общим хранилищем, сетями и ролями контроллеров. Все это — через понятный веб-интерфейс плюс пару CLI-команд там, где это действительно уместно. Поехали!

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

Привет, Хабр! Меня зовут Дмитрий Кравчук, я занимаюсь всем, что связано с данными в блоке AI&ML MAGNIT TECH. Расскажу про фундамент прибыльных проектов, которыми мы занимаемся в департаменте. Эта начало цикла статей о наших достижениях за 5 лет и планах на будущее.

В 2020 году мы выбирали формат для больших ML-хранилищ: Delta Lake, Iceberg или Hudi. В итоге остановились на Delta Lake. За 5 лет вокруг него у нас выросла полноценная платформа данных для ML-нагрузок: Spark, Kubernetes, S3, YDB, Airflow, Flink, OpenMetadata, Trino, StarRocks и собственные фреймворки.

Я не буду пересказывать документацию Delta Lake, а расскажу, как это работает у нас в промышленном контуре: доставка данных, слои хранения, оркестрация, хранилище метаданных, lineage, data quality, observability и governance, а также доступ к данным.

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

Материал будет полезен инженерам данных, ML-инженерам, Data scientist’ам, системным аналитикам, MLOps/DataOps/DevOps и всем, кто создаёт промышленную платформу данных под реальные нагрузки.