У S3-совместимого объектного хранилища другая логика: приложение обращается к объектам через API, а вопросы физического размещения и масштабирования решает сама система хранения. Для бэкапов, архивов и медиаданных модель такого рода подходит хорошо, однако перед переходом на нее важно проверить, как конкретное приложение работает с объектами и что произойдет с данными при нагрузке или восстановлении.

Как устроено S3

В объектном хранилище данные организованы в бакеты, где у объекта три составляющие: содержимое, уникальный ключ и метаданные. Вложенных директорий в привычном смысле здесь нет — папки в интерфейсах появляются потому, что ключ объекта разбирают по разделителю. Например, backups/2026/08/db-dump.tar.gz читается человеком как путь по папкам, а для хранилища — просто одна строка-идентификатор.

В отличие от файловой системы, где приложение может открывать файл, записывать данные частями, дополнять его и использовать блокировки, S3 работает с объектами через API. Объект загружается целиком, а изменения выполняются отдельными операциями API.

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

Управляется модель небольшим набором предсказуемых HTTPS-операций.

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

Где подходит модель

Зная, как устроена модель, проще понять, где S3 подходит лучше всего. Он хорошо работает с данными, которые сохраняются целыми объектами, хранятся независимо друг от друга и читаются по ключу. Например, так удобно хранить резервные копии, архивы, медиаконтент, логи и аналитические данные.

Для задач с частыми синхронными изменениями нужна другая модель хранения. Например, для дисков виртуальных машин, транзакционных логов СУБД, рабочих каталогов сборки и приложений с POSIX-блокировками подходит блочное или файловое хранилище. S3 при этом можно использовать для снапшотов, регулярных выгрузок и резервных копий.

Что защищает данные внутри S3 и где заканчивается эта защита

Для критичных данных в S3 используются versioning, Object Lock и репликация. Эти функции решают разные задачи и применяются в разных сценариях.

Versioning сохраняет предыдущие версии объектов. При повторной записи по тому же ключу создаётся новая версия с собственным version ID. DELETE добавляет delete marker, поэтому предыдущие версии остаются доступными для восстановления.

Versioning увеличивает объём хранения. Приложение, которое ежедневно переписывает крупный объект, создаёт последовательность его полных версий. Lifecycle-политика позволяет определить срок хранения старых версий и правила очистки незавершённых multipart-загрузок. Versioning переводится в состояние suspended, а полностью отключить его нельзя. При создании бакета с Object Lock versioning включается автоматически.

Object Lock реализует модель WORM, Write Once, Read Many. Для объекта задаётся срок retention, в течение которого система сохраняет его в защищённом состоянии.

В режиме Governance пользователь с расширенными правами может снять защиту вручную. В режиме Compliance защищённая версия сохраняется до окончания retention, включая случаи с root-аккаунтом. Срок хранения стоит рассчитывать заранее: установленный retention нельзя сократить, поэтому версия продолжит занимать место до окончания заданного периода.

Репликация создаёт дополнительные копии объектов и повышает устойчивость к отказам оборудования. В Linx Cloud используется фактор репликации 3, RF3, поэтому каждый объект хранится в трёх экземплярах.

Репликация переносит изменения вместе с объектами. Если исходные данные уже содержат логическую ошибку, она попадёт и в реплики. Для критичных данных поэтому требуется отдельный домен отказа, регулярная проверка восстановления и схема резервного копирования 3-2-1 или 3-2-1-1-0.

Своя инфраструктура или сервис провайдера

S3-сервис можно развернуть внутри собственной инфраструктуры или использовать как управляемую услугу провайдера. На уровне приложения подключение выглядит одинаково: endpoint, access key, secret key и S3 API — разница в эксплуатации инфраструктуры.

Перед выбором провайдера стоит свериться с матрицей ответственности — кто чинит платформу при сбое, кто управляет ключами и доступом, кто следит за квотами и кто в итоге отвечает за резервные копии данных. Такая матрица для S3 есть и у Linx Cloud — сверить её с внутренними регламентами команды стоит ещё до того, как сервис запущен в работу.

Как это устроено у Linx Cloud

Если выбор сделан в пользу провайдера, вот пример конкретной реализации. В основе сервиса Объектное хранилище (S3) в Linx Cloud — Ceph: мы выбрали его из-за совместимости с S3 API (по нашему опыту, полнее её реализует разве что сам AWS), а также из-за масштабируемости и гибкости для развития продукта.

Путь запроса такой: HTTPS endpoint → сетевой периметр с WAF и NGFW → балансировщики нагрузки → Ceph Object Gateway (RGW), который уже разбирает команды S3 API и передаёт операции в backend-кластер. Сами объекты лежат на OSD-узлах с репликацией в три копии (RF3), а управляющие компоненты кластера вынесены на отдельное оборудование.

Подключиться к сервису можно по интернету или по выделенному каналу точка-точка — из виртуального ЦОД Linx Cloud, серверной стойки в дата-центре Linx или с любой внешней площадки. По документации сервис поддерживает multipart upload, versioning, Object Lock/WORM, presigned URL, репликацию бакетов и lifecycle-правила удаления. Один PUT рассчитан максимум на 5 Гбайт — для объектов крупнее нужен multipart.

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

Что проверить на пилоте

Каким бы ни было решение — свой кластер или сервис вроде Linx Cloud — переводить на него прод стоит только после пилота, и строить его нужно на реальном потоке данных приложения: одна команда aws s3 cp с тестовым файлом ничего не покажет.

• Поэтому сначала измеряется профиль данных: средний и максимальный размер объектов, общее количество объектов, соотношение GET и PUT, частота LIST, пиковая нагрузка и допустимая задержка.
• Затем проверяется совместимость приложения с нужными функциями S3. В тест входят multipart, versioning, Object Lock, lifecycle, presigned URL и права доступа. Для каждого механизма важно проверить именно тот сценарий, который используется в рабочей системе.
• После этого оцениваются сеть и безопасность. Тест показывает поведение канала под нагрузкой, работу при обрыве соединения, доступные маршруты и стоимость исходящего трафика. На уровне безопасности проверяются разделение прав, хранение и ротация ключей, шифрование, аудит операций и сценарий компрометации учётной записи.
• Финальная часть пилота посвящена восстановлению и стоимости. Нужно выполнить возврат старой версии и полное восстановление данных, измерить объём накопленных неактуальных версий и рассчитать расходы на запросы, хранение и трафик с учётом ожидаемого роста данных.

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

Для data lake — скорость, с которой выбранный аналитический стек читает данные, и отсутствие «болезни мелких файлов», когда объектов становится очень много. Одна и та же платформа S3 может отлично закрывать один сценарий и требовать уже другого архитектурного решения в соседнем.

Вместо вывода

S3 подходит для бэкапов, архивов, медиаконтента и аналитических данных, которые хранятся и читаются как объекты. Для дисков ВМ, СУБД и рабочих каталогов с частыми изменениями больше подходят файловые и блочные хранилища.

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

При импортозамещении российские компании сталкиваются с одной проблемой: покупают серверы у одного производителя, программы у другого, а потом мучаются со стыковкой и поддержкой. «Гравитон» за 13 месяцев разработал ПАК виртуализации «Гелиус», где и аппаратная часть, и программная часть созданы, производятся и сопровождаются одной компанией.

Команда построила гиперконвергентное решение — в разработке участвовал весь департамент инженерных решений. Это решение сокращает стоимость инфраструктуры на 35-40% в перспективе 3-5 лет по сравнению со стандартным подходом.

Задача: частное облако без зависимости от нескольких вендоров

Бизнес-задача — снизить расходы на IT-инфраструктуру для российских компаний. Гиперконвергентное решение сокращает расходы на персонал за счёт упрощения обслуживания и позволяет эффективнее использовать имеющиеся ресурсы в модели IaaS.

Техническая задача — разработать программно-аппаратный комплекс на базе серверного и коммутационного оборудования российского производства (включённого в Единый реестр российской радиоэлектронной продукции) и программного обеспечения (включённого в Реестр российского программного обеспечения).

Параметры проекта

Срок разработки: март 2021 — апрель 2022 (13 месяцев)

Команда: около 25 инженеров и разработчиков

Экономический эффект: снижение стоимости владения инфраструктурой на 35-40% в перспективе 3-5 лет по сравнению с классической схемой (выделенные серверы, отдельные системы хранения данных, лицензии на ПО от разных вендоров и расходы на обслуживание)

Статус: внесён в Реестр Минпромторга (№10445375 от 07.05.2024, действует до 06.05.2027) и Реестр российского программного обеспечения (№23667 от 29.08.2024)

Архитектура: гиперконвергенция вместо классической инфраструктуры

Программно-аппаратный комплекс «Гелиус» построен по гиперконвергентной архитектуре. В отличие от классического подхода, где вычислительные мощности и системы хранения данных разделены физически, гиперконвергентная архитектура объединяет серверы в кластер, где каждый узел одновременно выполняет функции вычислительного узла и узла хранения данных.

Компоненты системы:

→ Серверы линейки «Гравитон» (объединены в кластер)

→ Среда виртуализации (управление виртуальными машинами и контейнерами)

→ Программно-определяемая система хранения данных (блочный, файловый, объектный доступ)

→ Программно-определяемая сеть (сегментирование через VXLAN, виртуальные маршрутизаторы, коммутаторы, межсетевые экраны)

→ Единая веб-консоль управления с ролевой моделью доступа

Архитектура предусматривает простое и предсказуемое масштабирование: достаточно добавить унифицированные вычислительные узлы на базе серверов линейки «Гравитон», и система автоматически включит их в кластер, распределив нагрузку.

Семь ключевых технических возможностей «Гелиус»

1. Широкая комплектация под разные задачи

Каждый узел кластера поддерживает процессоры Intel или AMD до 5-го поколения включительно, до 3 терабайт оперативной памяти на один узел, различные варианты накопителей HDD, SSD или NVMe — до 25 штук на один узел. Это позволяет компаниям собирать конфигурации под конкретные сценарии использования: от высокопроизводительных вычислений с большим объёмом оперативной памяти до массивов с приоритетом на объём хранения данных.

2. Высокая отказоустойчивость по схеме N+1

Резервирование аппаратных компонентов обеспечивает работу кластера даже при выходе из строя отдельных узлов. Целостность и доступность данных, хранящихся в кластере, обеспечивается тройной репликацией. Благодаря этому данные остаются доступными в случае выхода из строя до 40% от общего числа накопителей в кластере. Это критично для центров обработки данных, где простой инфраструктуры измеряется в миллионах убытков.

3. Развитая среда управления виртуальными машинами

ПАК «Гелиус» поддерживает живую миграцию виртуальных машин между узлами без остановки работы приложений, создание мгновенных снимков для быстрого отката к предыдущим состояниям, резервное копирование по расписанию, перенос виртуальных машин, созданных в импортных продуктах VMware, Hyper-V, Citrix и KVM. Последнее особенно важно для компаний, которые мигрируют с западных решений — не нужно разворачивать инфраструктуру с нуля, можно перенести существующие виртуальные машины.

4. Программно-определяемая система хранения данных со встроенным ML и поддержкой AI

Встроенная система хранения поддерживает три типа доступа к данным: блочный (для баз данных и виртуальных машин), файловый (для общих ресурсов) и объектный (для неструктурированных данных и резервных копий). Реализованы технологии компрессии и дедупликации для экономии дискового пространства, зеркалирования для повышения надёжности. Возможно построение тиринговых массивов, в которых автоматическая миграция «холодных» и «горячих» данных между медленными и быстрыми накопителями обеспечивается алгоритмами искусственного интеллекта. Система анализирует частоту обращения к данным и переносит редко используемые файлы на медленные, но объёмные HDD-накопители, а часто запрашиваемые — на быстрые NVMe, оптимизируя производительность и стоимость хранения.

5. Программно-определяемая сеть с полной изоляцией

Среда виртуализации работает в окружении программно-определяемой сети с сегментированием трафика виртуальных машин посредством VXLAN. Администраторы могут создавать виртуальные маршрутизаторы, коммутаторы и межсетевые экраны с индивидуальными настройками для каждого проекта или подразделения. Поддерживается технология vNAT и создание изолированных сетей в стиле DMZ для размещения публично доступных сервисов без риска для внутренней инфраструктуры. Реализованы балансировщики нагрузки по протоколам TCP, UDP, HTTP и HTTPS для распределения трафика между несколькими серверами приложений.

6. Встроенный мониторинг инфраструктуры и оборудования

В состав ПАК «Гелиус» входят средства мониторинга как виртуальной инфраструктуры (загрузка процессоров, использование памяти и дисков виртуальных машин, сетевой трафик), так и аппаратных компонентов кластера (температура, состояние накопителей, работа блоков питания, загрузка физических серверов). Единая веб-консоль с ролевой моделью доступа позволяет управлять всеми компонентами программно-аппаратного комплекса с рабочего места администратора без необходимости переключаться между разными интерфейсами.

7. Поддержка геораспределенных кластеров

ПАК «Гелиус» поддерживает возможность создания геораспределенных кластеров, когда узлы находятся в разных физических локациях — разных городах или дата-центрах. Это обеспечивает географическую отказоустойчивость: даже если один из дата-центров станет недоступен из-за аварии или стихийного бедствия, виртуальные машины продолжат работу на узлах в других локациях. Репликация данных между географически распределёнными узлами происходит автоматически.

Главная трудность: выбор архитектуры и конфигураций

🔴 Проблема: определить оптимальную архитектуру

Требовалось выбрать архитектуру для программно-аппаратного комплекса виртуализации и создать типовые конфигурации для узлов (серверов) кластера с учётом одновременного выполнения задач высокой отказоустойчивости, производительности и простоты управления. Гиперконвергентный подход требует тщательного баланса между вычислительными ресурсами и ресурсами хранения на каждом узле, а также продуманной схемы репликации данных.

✅ Решение: анализ реальных задач и опыт команды

Провели анализ типовых задач информационно-технологических отделов заказчиков, которые хорошо знакомы с серверным оборудованием «Гравитон», для формирования требований к программно-аппаратному комплексу виртуализации. Изучили функционал существующих продуктов в области виртуализации и хранения данных — как западных, так и российских — для дополнения требований к ПАК виртуализации. Использовали многолетний опыт инженеров и разработчиков компании «Гравитон» для выбора конфигураций узлов и создания программного обеспечения. Команда из более чем 100 специалистов объединила экспертизу в аппаратной части (производство серверов) и разработке программного обеспечения, что позволило создать сбалансированное решение.

Результаты: экономика и отзывы клиентов

Снижение совокупной стоимости владения инфраструктурой до 8 миллионов рублей в год по сравнению с затратами на классическую инфраструктуру. Традиционный подход требует закупки выделенных серверов, отдельных систем хранения данных, лицензий на программное обеспечение от разных вендоров и затрат на интеграцию и обслуживание всех этих компонентов. Гиперконвергентная архитектура ПАК «Гелиус» объединяет всё в одном решении от единого производителя.

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

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

Планы развития: расширение платформ и автоматизация

«Гравитон» продолжает развитие ПАК «Гелиус» по трём направлениям.

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

Дополнение конфигурации программно-аппаратного комплекса тонкими клиентами линейки «Гравитон» для виртуальных рабочих столов. Это позволит компаниям полностью перевести сотрудников на работу с виртуальными десктопами, централизованно управляя всей вычислительной средой из единой консоли.

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

Реклама. ООО «Ревотех», ИНН 9731071780, erid: 2W5zFHppVN9

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

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

Что такое бэкапы

Итак, бэкап сайта (с англ. backup — запасной) — это резервное копирование файлов, папок, данных проекта на отдельный сервер. Таким образом можно избежать потери информации в случае атаки, сбоев в работе сервера или базы данных, плановых работ или даже неудачных изменений на сайте.

Главная идея резервного копирования — возможность в любой момент откатить версию проекта до более старой.

Бэкапы делятся на несколько видов. Разберём их в зависимости от механизма копирования:

• Полный

Такая резервная копия сохраняет все данные. Она требует больше всего памяти и времени для создания.

• Инкрементальный

Сохраняет только те данные, которые изменились с момента последнего бэкапа.

• Дифференциальный

Включает только те файлы, которые изменились относительно последнего полного бэкапа.

• Обратное инкрементальное копирование

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

• Синтетическое копирование

За основу берётся последний полный бэкап, на который «наслаиваются» инкрементные копии — пока система не соберёт актуальную версию. Когда эта версия устаревает, цикл повторяется: создаётся новый синтетический бэкап поверх предыдущего полного.

Бэкапы также могут храниться на разных носителях, вот основные из них:

Сетевое хранилище (NAS)

Локальный сервер, где можно централизованно хранить бэкапы разных устройств и/или пользователей, объединяя их в одну сеть. Работает через LAN (локальное соединение) или интернет.

Другой компьютер

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

Внешний (жёсткий) диск

Компактный внешний диск удобно брать с собой, быстро получать доступ к данным, загружать и восстанавливать их. Однако из-за малого объема памяти он не подойдёт для сложных задач.

Облачное хранилище

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

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

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

Почему люди не делают бэкапы

В России лишь 13% работающих россиян выполняют бэкапы регулярно, тогда как, например, в Европе 37% пользователей делают резервные копии еженедельно.

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

• Халатность или недостаток технической грамотности. Многие думают, что резервное копирование не требует особых настроек и работает фоново. 43% IT-руководителей и вовсе уверены, что бэкап данных на сервере — полностью ответственность провайдера.

Теперь рассмотрим, как предупредить ошибки при организации резервного копирования и поставить этот процесс на поток.

Ошибки при организации резервного копирования

Еще в 2021 году разработчик программного обеспечения Veeam выяснил, что 58% бэкапов проваливаются, не выполнив своей основной функции. Разберём несколько возможных причин, почему так происходит.

• Нерегулярность

62% пользователей в РФ копируют и сохраняют рабочие данные, но большинство делают это нерегулярно.

• Хранение всех копий в одном месте

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

• Хранение только одной копии

Иметь одну резервную копию рискованно – если она повредится или вы случайно сохраните неверную версию, данные пропадут безвозвратно. Поэтому существует правило «3-2-1»: лучше иметь не менее трех копий данных, хранить их на двух и более физических носителях и не менее одной копии – удалённо.

• Отсутствие тестирования восстановления

По статистике, лишь 30% компаний проводят комплексное тестирование резервного копирования.

• Незащищенность бэкапов

Хотя бэкапы не требуются ежедневно, защищать их очень важно: 96% всех атак программ-вымогателей направлены на заражение резервных копий.

Когда бэкапы пригодились: кейсы компаний

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

Google Cloud

В 2024 году пенсионный фонд UniSuper обнаружил, что его учетная запись в Google Cloud удалена. Из-за сбоя пострадали около 620 000 пенсионеров — доступ к их счетам оказался заблокирован на неделю.

Решить проблему помог другой партнер UniSuper — хостинг-провайдер, которому фонд отдал свои резервные копии на хранение. Они помогли компании восстановить данные и доступ к аккаунтам.

Hycu

Одна медицинская компания и клиент Hycu уделяла кибербезопасности огромное внимание, но в её инфраструктуре всё равно нашлось слабое место. Через электронное письмо систему поразила программа-вымогатель, а когда проблему заметили, заражены уже были все файлы.

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

Samsung

Когда в 2014 году в дата-центре Samsung произошёл крупный пожар, большая часть данных пропала безвозвратно из-за отсутствия удалённых бэкапов.

Как показывают эти и другие подобные кейсы, создание резервных копий сервера — один из главных инструментов защиты данных.

Кто обычно отвечает за бэкапы

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

Мы в Beget тоже придерживаемся такой практики и внедрили для пользователей как автоматическое резервное копирование, так и бэкапы по требованию. Автоматический бэкап сайта на хостинге создается в среднем раз в 3 дня, на VPS – раз в 2–5 дней. Полный бэкап сервера VPS хранится в среднем 10 суток, после чего заменяется более свежей версией. Точного срока хранения бэкапов на виртуальном хостинге нет: на каждом аккаунте может храниться единовременно только 10 бэкапов, а когда место заканчивается, более старые копии удаляются.

Заключение

Утечка данных — проблема, которая почти всегда приходит без предупреждения. Пожалуй, именно поэтому, несмотря на все затраченные на системы безопасности средства, данные теряются постоянно: например, в 2023 году более 90% компаний оказались в ситуации, когда им пришлось обратиться к бэкапам, и при этом только 27% компаний смогли восстановить все данные, так как резервное копирование было организовано неправильно.

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

А зря.

За свою практику я встречала разные подходы к организации Data QA. В этой статье я расскажу про самый простой и быстрый вариант, который можно «собрать на коленке», а потом уже развивать. С примерами кода и тем, зачем SQL нам нужен в этой жизни.

И небольшой дисклеймер. Если вы знаете, как сделать это на Python стильно модно молодежно, обязательно напишите мне об этом в комментариях, я с удовольствием почитаю про ваш подход.

Также подписывайтесь на мой ТГ, который я почти не веду.

Базовый сценарий

1. Есть таблица-источник source_table.
2. Разработчик запускает свой код (Spark, Airflow или что у него там), и данные магическим образом перекладываются + преобразуются.
3. На выходе получаем result_table.

Вопрос: как это тестировать?

Самый быстрый и простой путь

Подготовка:

1. Создаём таблицу-источник.
2. Наполняем её данными (синтетика или реальные примеры с прода).

Действие:

1. Запускаем ETL код.
2. Сравниваем данные «как было» и «как стало».

После теста:

1. Удаляем таблицу-источник.
2. Удаляем таблицу-приёмник.

На коленке это можно собрать так:

1. CREATE TABLE …
2. INSERT INTO …
3. Ручной запуск пайплайна (Spark/Airflow).
4. Какой-нибудь скрипт для сравнения результатов.

Рабочая схема? Да.

Удобная? Нет.

Где хранить эти скрипты?

Можно, конечно, прилепить их к задаче в Jira в виде файликов. Но выглядеть это будет как «фигня на палке». Через месяц никто не вспомнит, что это было и зачем.

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

Архитектура проекта

Минимальный стек

1. Utils — мелкие, но полезные

Здесь мы храним всякую мелочёвку. Например, функцию для открытия JSON:

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

2. APIClient — для триггеров

Здесь всё максимально тривиально: клиент для вызова API и запуска ETL джоб.

3. PostgreSQLClient — основной игрок

Класс для подключения, запросов, создания таблиц, вставки данных и удаления.

Фикстуры (conftest.py)

API фикстуры

Я показываю пример, как поднимаю один API клиент. Но у вас их может быть много: например, разные сервисы или разные перекладчики.

DB фикстура

Пример для дефолтной PostgreSQL, но вы можете добавить фикстуры для поднятия GreenPlum или ClickHouse.

Как хранить данные?

А теперь самый сок, которым я обмазываюсь сейчас.

Конечно, можно создать отдельный скрипт на чистом sql для создания и редактирования своих табличек: больших и маленьких. Но, если честно, это так *цензура* неудобно.

Поэтому я придумала хранить схему и данные в отдельных json файлах и налету генерить скрипты. Да, Америку я вновь не открываю, и очень жаль.

В директории тестов я создала папку resources, где храню эти файлы.

Конечно, в таком виде вы не передадите ничего в Postgres и ничего не слепите. Так что я услужливо предоставляю вам код, чтобы вы его копировали и вдохновлялись.

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

Отдельное удовольствие мне даёт вот эта строчка кода db_client:PostgreSQLClient.Она значит, что если так вышло, что у меня есть куча разных PostgesSql, я могу в эту фикстуру прокинуть нужный мне клиент без дополнительных приседаний. И это, конечно, прекрасно.

Пример: подготовка данных

Самые внимательные уже заметили, что в примере выше я поднимала postgres-клиента.

Так что разницы почти никакой (ну, кроме тех случаев, когда внезапно очень даже есть 🙃).

И сам тест

Конечно, можно сравнивать всё это дело через всякие прослойки типа Pandas.

Но, камон, у меня что, куча времени сидеть, читать доки и писать суперсложные датафреймы ради пары простых проверок? Нет.

Позвольте мне радостно строчить свой первозданный код с дефолтными проверками и быть довольной этим минимализмом.

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

Итог

• Ручные скрипты → боль и страдания.
• Автоматизация через Python+pytest → быстро, удобно, воспроизводимо.
• JSON-файлы позволяют хранить схемы и данные в читаемом виде.
• Allure даёт красивые отчёты.

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

Это крупнейшее обновление формата за всю его историю.

Что нового в PNG

1. Поддержка HDR

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

2. Анимация (APNG)

В формате официально закреплена поддержка анимаций. Ранее Animated PNG использовался неофициально и поддерживался не всеми браузерами. Теперь это часть спецификации.

3. Метаданные EXIF

В PNG теперь можно сохранять стандартные метаданные камеры и устройства съёмки: дата, настройки экспозиции, модель устройства и другие параметры — как это давно работает в JPEG и других форматах.

Почему обновление важно

PNG остаётся одним из самых популярных форматов сжатия без потерь. Его используют для хранения графики, интерфейсов, скриншотов и архивных изображений. В США, Канаде и Австралии PNG официально рекомендован для цифровой архивации.

До сих пор формат уступал более современным аналогам вроде WebP и AVIF в функциональности — особенно из-за отсутствия поддержки анимаций и HDR. Теперь этот разрыв сокращается.

Кто участвовал

Обновление спецификации инициировала рабочая группа W3C, занимающаяся текстами с таймкодами — вроде субтитров и аудиоописаний. Им понадобилась поддержка HDR, и с этой задачей они обратились к формату PNG.

В проекте приняли участие крупные игроки индустрии: Adobe, Apple, Google, BBC, Comcast, NBCUniversal и MovieLabs.

Что дальше

W3C уже планирует следующее обновление. В нём хотят улучшить совместимость между SDR и HDR-изображениями, а также поработать над эффективностью сжатия.

Теперь, когда PNG официально поддерживает HDR, анимации и EXIF, формат получает второй шанс в эпоху WebP, AVIF и HEIC.

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

Тем не менее, есть несколько важных шагов, которые придется учитывать при переносе вашего ХД, чтобы ваш заказчик был доволен.

Шаг 1: Определить цели миграции

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

Необходимо проанализировать, какие основные задачи закрывало старое ХД. Новое хранилище должно не только выполнять те же функции, но и обладать актуальной документацией и оптимизированной структурой без излишних данных. Если не решить эти задачи заранее, то вместо миграции вы будете заниматься рефакторингом: то есть поменяете код, но оставите старые ошибки.

Шаг 2: Проверить качество данных

Качество данных в ХД является одним из критических аспектов для получения консистентной информации, которой можно доверять. Несмотря на то, что существуют специализированные инструменты Data Quality, которые обеспечивают качество данных, необходимо помнить, что со 100% вероятностью какая-то информация в старое ХД заливалась из Excel, что-то подправлялось вручную, а что-то корректировалось прямо в интерфейсе. Это приводит к тому, что данные в старом и новом хранилищах не «сойдутся».

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

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

Шаг 3: Провести предпроектное обследование

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

Шаг 4: Выбрать модель данных

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

Поэтому при выборе модели для будущего ХД надо вспомнить о цели, ради которой оно строится. Если это просто хранение с возможным последующим масштабированием данных, то data vault подойдет. Однако если это подготовка агрегатов, витрин данных и аналитической отчетности, лучше делать комбинацию data vault с третьей нормальной формой.

Шаг 5: Обучить команду

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

Если в организации есть собственная сильная ИТ-команда, то можно строить ХД самостоятельно. Однако многие компании решают эту задачу приглашением консультантов-интеграторов или вендоров, которые уже реализовывали миграцию и проводят полноценное обучение.

Куда мигрировать хранилища данных сегодня

Сегодня выбор технологий для ХД в России не так велик — это может быть Greenplum, Hadoop или Spark, то есть решения на базе open source.

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

К сожалению, нет «супертаблетки», которая поможет сделать отличное ХД: в каждом конкретном случае надо смотреть на цели и задачи. В любом случае важно помнить, что успех миграции определяется не только техническими решениями, но и четким пониманием бизнес-потребностей и организационной подготовленностью компании. Тщательное планирование и внимание к деталям могут обеспечить плавный переход к современным решениям для работы с данными.

Data Office в «Ростелекоме» стал зарождаться в 2017-2018 годах после появления единого технологического хранилища. Получив первые успешные проекты на централизованной платформе, мы задумались о такой же централизации работы с данными. До этого данными в разных подразделениях занимались обособленно.

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

Как мы выстраивали Data Office

Шаг № 1. Провели инвентаризацию всех проектов и создали единый контур

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

У каждого отдельного бизнеса уже было собственное хранилище данных, и нам потребовалось разобраться во всех внутренних процессах, завязанных на эти хранилища (продажи, техподдержка, обслуживание клиентов) прежде, чем переключать всё на единую систему.

Важно подумать над технической архитектурой централизованного контура, на котором будет развиваться отчётность. Продумывать его нужно не только под сиюминутные задачи, но и на перспективу: заложить возможности для масштабирования, понять, какие аналитические кейсы на нём можно будет разворачивать. Даже если сейчас у вас есть живая потребность только в аналитическо-регулярной отчётности, пакетной доставке и обработке, завтра на этих же данных нужно будет подключать команды для подготовки данных для ML-моделей, для realtime отчётности и так далее.

Шаг № 2. Объяснили подразделениям и командам плюсы перехода

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

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

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

Шаг № 3. Определились с технологическим стеком и подготовили специалистов

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

Решить задачу построения платформы, опираясь на классическую модель построения DWH с участием крупных вендорных appliance, не получилось бы. Мы стали смотреть в сторону software-based и open-source based решений. В качестве ядра системы выбрали Hadoop и Greenplum — гибкие и хорошо масштабируемые инструменты, со взаимной совместимостью и большой экосистемой сопутствующих технологий.

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

Шаг № 4. Предусмотрели решение текущих задач по данным

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

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

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

Шаг № 5. Формирование data-driven культуры в компании

Мы уделяем много времени и сил обучению сотрудников работе с данными и формированию data-driven мышления. Проводим «мягкие» программы, где разбираем, как Amazon и Google поднимают рентабельность своего бизнеса с помощью анализа данных. Запускаем «хардовые» программы, где учим работать с BI-дашбордами, базами данных, Hadoop и другими техническими инструментами. Так, после программы по работе с нейросетями у нас на портале зарегистрировалось 600 новых пользователей.

Есть и внешняя история: в 2019 году мы создали бесплатный общедоступный проект DataTalks. Изначально мы планировали обучать работе с данными студентов, но в итоге на программу пришли и действующие дата-специалисты, и даже CDO нескольких компаний.

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

Как определить, что всё получилось

По этим метрикам мы определяем, что подразделение устоялось и Data Office стал эффективной функцией бизнеса.

Количество обращений растёт. С нашим внутренним порталом данных работает в среднем шесть тысяч пользователей ежемесячно.

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

Отсутствует текучка кадров. Если люди не понимают целей и задач, не понимают, какую пользу приносят бизнесу, они быстро увольняются. В нашем случае основная команда не менялась с 2019 года: то есть люди, которые начинали Data Office, остались и продолжают расти внутри подразделения.

Продукт обновляется. Мы совершенствуем доступность системы, скорость подготовки регулярных данных и ряд других технических характеристик: мы начинали с ежемесячных отчётов, но сейчас практически все дата-продукты переведены на ежедневное обновление.

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

• автоматизировали процессы, создав шаблоны загрузки данных и прописав логику выбора шаблона на основе метаданных;
• разбили процессы на атомарные этапы, описав в репозитории шаги по загрузке, проверке, синхронизации, сбору статистики и так далее;
• определили порядок выполнения задач по принципу FIFO, чтобы они регистрировались, а не выполнялись немедленно;
• настроили дискретно-непрерывные загрузки.

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

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

Сейчас за месяц мы обрабатываем 300 тыс. процессов и 1,5 млн операций. Около 85% загрузок из источников в ODS реализуются на готовых процессах. На разработку новых процессов загрузок в DDS и витрин разработчики тратят считаные минуты, уделяя основное время реализации и отладке бизнес-логики.

Есть финансовый эффект. Каждый дата-продукт и сервис мы измеряем с точки зрения отдачи инвестиций. Самый простой пример с Data Science: DS-модели позволяют нам продавать больше услуг клиентам или улучшать сервис.

О чём важно помнить, создавая Data Office?

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

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

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

Остались ли у вас вопросы по выстраиванию Data Office в компании? С радостью ответим на них в комментариях.

1. Что такое таблицы в SQL
2. Обычные таблицы
3. Секционированные таблицы
4. Временные таблицы SQL
5. Системные таблицы
6. Широкие таблицы
7. Основные операции над таблицами в SQL

Что такое таблицы в SQL

В SQL (Structured Query Language) таблица представляет собой структурированную коллекцию данных, представленную в виде строк и столбцов. Она используется для хранения и организации данных в реляционных базах данных.

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

Пример создания таблицы в SQL:

В этом примере мы создаем таблицу “employees” с четырьмя столбцами: “id”, “name”, “age” и “email”. Тип данных каждого столбца указан после его имени. Первый столбец “id” устанавливается в качестве первичного ключа с помощью ключевого слова “PRIMARY KEY”, что означает, что значения в этом столбце должны быть уникальными и не могут быть пустыми.

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

Типы таблиц в SQL

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

Обычные таблицы SQL

Обычная таблица в SQL – это структурированная коллекция данных, представленных в виде строк и столбцов. Она используется для хранения и организации данных в реляционных базах данных.

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

Пример создания таблицы в SQL:

В приведенном выше примере создается таблица “employees” с пятью столбцами: “id” (целочисленный тип данных), “firstname” и “lastname” (строковые типы данных с максимальной длиной 50 символов), “age” (целочисленный тип данных) и “salary” (число с фиксированной точностью и масштабом). Каждая новая запись, добавленная в эту таблицу, будет содержать значения для каждого из этих столбцов.

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

Секционированные таблицы SQL

Секционированные таблицы в SQL позволяют разделить данные таблицы на разделы или разделы, каждый из которых может храниться в отдельной физической секции. Каждый раздел имеет одинаковые столбцы, но разные наборы строк. Это особенно полезно для работы с большими таблицами, такими как таблицы с миллионами записей.

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

Пример создания секционированной таблицы в SQL Server:

В этом примере создается секционированная таблица с именем MyPartitionedTable. Есть три столбца: Column1 (целочисленный тип), Column2 (строковый тип с максимальной длиной 50 символов) и Column3 (тип даты и времени).

Сначала мы создаем функцию разбиения с именем MyPartitionFunction, которая разбивает данные по левому способу значениями 100, 200 и 300.

Затем мы создаем схему разбиения с именем MyPartitionScheme, которая использует функцию разбиения MyPartitionFunction и указывает, что все данные будут храниться в основной файловой группе ([PRIMARY]).

Затем мы создаем таблицу MyPartitionedTable и указываем, что она будет использовать схему разбиения MyPartitionScheme и разбиваться по столбцу Column1. Это означает, что данные будут автоматически разделены на разделы в соответствии с функцией разбиения и схемой разбиения.

После создания секционированной таблицы вы можете вставлять, обновлять и выбирать данные, как обычно. Система автоматически распределит данные между разделами в соответствии с определенными параметрами разбиения.

Временные таблицы SQL

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

Пример создания временной таблицы в SQL:

В приведенном выше примере создается временная таблица с именем #TempTable. Она содержит столбцы ID типа INT и Name типа VARCHAR(50). Затем мы вставляем несколько строк в таблицу с помощью оператора INSERT INTO. В конце мы выбираем все строки из временной таблицы с помощью оператора SELECT.

После завершения работы с временной таблицей, мы можем удалить ее с помощью оператора DROP TABLE.

Временные таблицы можно разделить на два типа: локальные временные таблицы и глобальные временные таблицы.

1. Локальные временные таблицы привязаны к текущему сеансу пользователя и доступны только для этого сеанса. Их имена начинаются с одной решетки (#). Локальные временные таблицы видны только в пределах текущего сеанса подключения.
2. Глобальные временные таблицы видны для всех сеансов на сервере баз данных. Их имена начинаются с двух решеток (##). Глобальные временные таблицы полезны в ситуациях, когда необходимо обмениваться данными между разными сеансами пользователей или хранить данные на время, пока выполняется долгая операция.

Обратите внимание Временные таблицы в каждом сеансе соединения уникальны и недоступны для других сеансов пользователей. Если требуется обмен данными между сеансами, вам может потребоваться использовать глобальные временные таблицы, предварительно проверив документацию своей СУБД для более подробной информации и синтаксиса создания.

Системные таблицы в SQL

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

Существуют некоторые системные таблицы, которые уникальны для базы данных master и содержат всеобъемлющую информацию о самом сервере SQL. Некоторые из этих таблиц включают:

1. sys.objects: Эта таблица содержит информацию о каждом объекте базы данных, включая таблицы, представления, процедуры и триггеры.
2. sys.columns: В этой таблице содержится информация о каждом столбце в базе данных, включая имя столбца, тип данных, ограничения и другие свойства.
3. sys.tables: Эта таблица содержит информацию о каждой пользовательской таблице в базе данных, включая имя таблицы, схему, тип индексов и другие детали.

Пример создания системной таблицы в SQL:

Широкие таблицы SQL

Широкие таблицы в SQL – это таблицы, которые имеют очень большое количество столбцов или содержат столбцы с большим объемом данных. Широкие таблицы могут быть полезными в ситуациях, когда требуется хранить большое количество данных для каждой записи или когда требуется поддерживать гибкую схему данных с переменным количеством столбцов.

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

Пример создания широкой таблицы:

Основные операции над таблицами в SQL

Основные операции над таблицами в SQL включают создание таблиц, вставку данных, выборку данных, обновление данных и удаление данных.

Создание таблицы

Операция создания таблицы позволяет определить структуру и схему таблицы, включая названия столбцов и их типы данных. Пример создания таблицы в SQL:

Вставка данных

Операция вставки данных позволяет добавить новые строки в таблицу. Пример вставки данных в SQL:

Выборка данных

Операция выборки данных позволяет извлечь определенные строки и столбцы из таблицы с помощью оператора SELECT. Пример выборки данных из таблицы в SQL:

Обновление данных

Операция обновления данных позволяет изменить значения определенных столбцов в таблице. Пример обновления данных в SQL:

Удаление данных

Операция удаления данных позволяет удалить определенные строки из таблицы. Пример удаления данных в SQL:

Заключение

Таблицы являются важной составляющей SQL и предоставляют надежный и эффективный способ организации данных.

Различные типы таблиц в SQL обеспечивают гибкость и функциональность при выполнении операций с данными.

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

Разработчик компании IT_One Анна Зверькова рассказывает о нюансах этой процедуры и способах обработки большого объема данных невысокого уровня качества на примере из финансовой отрасли.

Общие сведения

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

Пример абсолютных дубликатов:

Пример дубликатов с неидентичными полями:

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

Обозначим три причины, которые делают дедупликацию насущной необходимостью:

1. упрощение использования данных, чтобы конечные потребители при виде трех похожих записей не ломали голову, имеют ли они дело с одной и той же сущностью, или с тремя разными;
2. упрощение анализа данных, в том числе при использовании ML, когда большое количество дубликатов может привести к некорректной работе модели, ее «переобучению»;
3. повышение эффективности хранения данных, сокращение объема хранимых данных.

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

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

Факторы, осложняющие дедупликацию:

1. Отсутствие уникальных идентификаторов, ошибки в заполнении уникальных идентификаторов. Например, ИНН человека, который должен быть уникален, на самом деле для регулирующего органа не всегда может быть таким уникальным идентификатором: известны случаи, когда по ошибке одному человеку присвоили несколько ИНН. Ошибки при наборе ИНН оператором, вносящим данные, также зачастую делают это поле непригодным для того, чтобы быть уникальным идентификатором, которого достаточно для того, чтобы отделить одного заемщика от другого.
2. Изменение параметров сущности при сохранении ее тождественности. Например, меняя номер паспорт или фамилию при замужестве, заемщик по факту остается тем же самым человеком.
3. «Мусорное» заполнение некоторых полей операторами. Например, номер телефона вместо номера паспорта, “test test test” вместо ФИО, “1111111111” вместо номера телефона.
4. Незаполненные поля.
5. Опечатки, в том числе одни из самых распространенных, когда соседние символы меняются местами.
6. Записи в полях перепутаны местами. Например, фамилия в поле «Имя», имя в поле «Фамилия».
7. Системы-источники предоставляют данные в разных форматах. Например, номера телефонов с +7 или без префикса.
8. Неверно используются регистры в строчных данных – «пЕтров» и «иванов», не тождественны «Петрову» и «Иванову».
9. Замена символов – ‘ч’ и ‘4’, ‘е’ и ‘ё’, английское и русское ‘с’.
10. Лишние пробелы и спецсимволы.

Работая с дубликатами данных в кредитной информации, можно использовать от одного до трех шагов, описанных ниже, в зависимости от качества, полноты и объема имеющихся данных. Приведем пример на СУБД Apache Hive, однако описанные методы применимы также для других технологий хранения и типов данных.

Первый этап: предочистка, нормализация

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

Так же простыми командами мы можем избавиться от разногласий, связанных с различными регистрами написания строковых данных (Иванов и иванов – команда UPPER или LOWER), лишними пробелами в начале или конце строки (TRIM), лишними спецсимволами, по ошибке добавленными операторами в строковые данные.

На этом же этапе происходит унификация форматов (даты, номера телефонов).

Для того, чтобы «Аксёнов» и «Аксенов» не воспринимались как два разных человека, зачастую все «Ё» полезно привести к «Е». Вопрос английского и русского «С» менее очевиден: если операторы вводят всю информацию на русском, никогда не переключаясь на английский, приведение английского «с» к русскому может только избыточно занять мощности, не дав никакого результата.

Второй этап: работа с ошибками в данных

После первичной дедупликации полезно «посмотреть глазами» на переобъединенные группы – такие группы, куда при первичной группировке попало максимальное количество записей. Необходимо определить, корректно ли такое объединение. Зачастую оно оказывается неверным из-за «мусорного» заполнения – объединения данных по значениям, которые операторы вносят, когда у них нет реальных значений.

Например, в отсутствие паспорта у заемщика оператор вводит «1111 111111» или номер телефона вместо номера паспорта. Пустые или «мусорно» заполненные поля не должны быть использованы для дедупликации, это приведет к переобъединению – то есть отнесению разных записей к одной сущности, тогда как в реальности они являются разными сущностями. Такие записи необходимо будет дедуплицировать по сочетанию других полей.

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

Например, контрольное число можно использовать для проверки корректности, в том числе, банковских счетов, штрих-кодов, банковских карт, СНЛС, ОКПО, ОКАТО, ISBN, ОГРН, VIN. Контрольное число – разновидность контрольной суммы, добавляется обычно в конец длинных номеров с целью первичной проверки их правильности. Это чаще всего либо последняя цифра суммы всех чисел номера, либо результат другой математической операции над цифрами.

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

Расстояние Левенштайна – это минимальное количество односимвольных операций (вставка, удаление, замена), которые нужно произвести для того, чтобы одну последовательность символов превратить в другую. Формула Левенштайна встроена в ряд диалектов SQL и в зависимости от характера строк может быть заменена на Jaro-Winkler.

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

Третий этап: таблицы дедупликации и поиск вершин в графах

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

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

Например, у нас есть 7 значимых полей, в части из которых допущены ошибки, часть пусты:

Очевидно, что запись №3 нельзя пускать в дедупликацию по полям «Отчество» и «ИНН», запись №5 – по полю «СНИЛС».

Соответственно в приведенном случае дедупликацию можно было бы провести каждому из сочетаний 4-5 полей из имеющихся 7 полей – 35 в разных сочетаниях. Однако имеет смысл с учетом бизнес-логики и опытным путем определить имеющие смысл сочетания и проводить дедупликацию только по ним. Например, в приведенном случае нет смысла дедуплицировать по сочетанию полей: «фамилия», «имя», «отчество», так как высока вероятность наличия полных тезок. В приведенном примере будет достаточно примерно 16 таблиц дедупликации.

Пример скрипта – таблица дедупликации:

Основная цель составления таблиц дедупликации – присвоить каждому «сырому id», то есть тому, с которым к нам попала запись, с неким «групповым id». Общий «групповой id» присваивается всем тем записям, которые мы определяем как дубликаты. Причем «групповым id» будет минимальный сырой по группе – то есть такой, с которым данная сущность попала к нам в первый раз.

Например:

При составлении таблиц дедупликации важно проверять «глазами» пере-объединенные и недо-объединенные группы для поиска аномалий. Переобъединенные группы – такие, в которых было объединено больше всего записей. Зачастую именно в них оказываются записи с мусорным заполнением, вроде “test test test” вместо ФИО, “1111111111” вместо номера телефона, которые надо будет исключить из дедупликации по данным полям в дальнейшем.

Пример использования формулы Левенштайна для нивелирования ошибок в таблицах дедупликации:

Получившиеся таблицы дедупликации объединяем простым UNION. Мы получили одну большую таблицу, в которой каждому изначальному («сырому») ID в записи соответствует вновь присвоенный некий групповой ID. Фактически таким образом мы получили много ребер графа, которые нужно связать между собой, чтобы отнести комплект дублирующихся записей к одной сущности (в нашем примере – субъекту персональных данных).

Чтобы объединить имеющиеся ребра графа в группы, мы используем инструмент Apache Spark GraphX – Connected Components. GraphX – компонент Apache Spark для манипулирования и анализа структурированных данных в виде графов.

GraphX предоставляет API для вычисления графов, которое включает в себя традиционные графовые операции и операции над RDD. ConnectedComponents – это алгоритм, используемый для определения связанных компонентов в графе.

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

Пример: определение вершин в графах.

Заключение

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

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

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

Для ЭВМ перфокарты ввели в 1928 году, и с тех пор они почти не менялись, и использовали их вплоть до 1980-х годов, пока не заменили магнитными лентами.

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

В этой статье мы расскажем, как собрать собственный ридер для перфокарт. Это — адаптированный перевод оригинального гайда DIY Paper Tape/Punch Card Maker and Reader с сайта Instructables.

Что понадобится для сборки привода

1. Плоский кабель.
2. Провода.
3. Два 1х10 соединителя с пинами, male-разъём.
4. Пара деревяшек.
5. 10 фоторезисторов.
6. 10 LED-светодиода диаметров по 3 мм.
7. Одна большая перфоплата или две платы 4х20.
8. Паяльник и припой.
9. Стриппер для снятия изоляции с проводов.
10. Резистор на 10 Ом.
11. Плата Parallax Propeller Activity Board.
12. Плоттер или принтер.

Начинаем паять ридер для перфокарт

Припаяйте фоторезисторы к перфоплате в один ряд. С другой стороны соедините выводы фоторезисторов между собой.

Возьмите плоский кабель с 10 линиями, зачистите провода с обоих концов на 3 мм и залудите их. Припаяйте их к 1х10-коннектору.

Первые 9 проводов должны быть припаяны к перфоплате, а не к фоторезисторам. Выводы не должны касаться их.

Последний десятый вывод будет питать фоторезисторы. Припаяйте его к другой стороне перфокарты от первых девяти выводов.

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

Возьмите ленточный кабель и припаяйте один провод к стороне платы с LED, а другой провод — к другой стороне. К концу кабеля прикрепите male-коннектор на 2 пина.

Возьмите 1х10-коннектор и припаяйте 9 резисторов сопротивлением 10 кОм по одному к каждому выводу. Другой вывод каждого резистора должен быть соединён к следующему резистору. Последний резистор припаивается к 10 выводу.

Для светодиодов понадобится резистор не менее 100 Ом, который будет ограничивать ток, чтобы не перегрузить LED.

Собираем наше устройство воедино:

Готовим деревянный корпус для ридера

Подготовьте деревянный корпус для считывателя перфокарт: наметьте отверстия для фоторезисторов и LED. Между двумя половинами устройства должен быть паз высотой в 1.5 миллиметра: он понадобится для того, чтобы вставлять в него будущую перфокарту.

Подсоедините платы с фоторезисторами и LED к корпусу и приклейте их.

Программируем чтение перфокарт в Propeller

Propeller Tool — это инструмент, который позволяет программировать микроконтроллеры Propeller 1 и 2. В нём мы напишем код, который поможет нашему устройству читать перфокарты.

Создаём свою перфокарту

В качестве основы для перфокарты нужно взять плотный картон. Отлично подойдёт обложка старой картонной папки.

Для того, чтобы нанести перфорацию на картон, используйте программу Silhouette Studio. В ней можно либо запрограммировать резку по картону, если у вас есть плоттер. Если у вас простой принтер, то можно разметить перфорацию, а затем вырезать её самому.

Придётся попотеть с тем, чтобы подобрать размеры перфокарты. Он зависит от того, какие у вас получились габариты паза в ридере перфокарт и как расположены LED и фоторезисторы. Приблизительная ширина перфокарты из гайда — 5 сантиметров.

Читаем перфокарту

Подключите плату Parallax Propeller к компьютеру и запустите её. Все светодиоды должны загореться. Если Propeller показывает странные сообщения, убедитесь, что выводы фоторезисторов подключены в правильном направлении.

Проведите первокарту через паз ридера. Наше сообщение гласит:

Заключение

Если вам понравился этот гайд, посмотрите другие статьи этого автора — у него много крутых проектов. ? Или прочтите другие материалы по DIY на Tproger:

1. Как сварить своё крафтовое пиво с Arduino
2. Проект на Raspberry Pi — полноценный ноутбук в компьютерной мышке
3. Как сделать умный дом своими руками на Arduino и Яндекс.Алиса — пошаговая инструкция

localStorage и связанное с ним sessionStorage являются частью API веб-хранилища. Мы узнаем о них подробнее ниже.

API веб-хранилища предоставляет методы, с помощью которых браузеры могут сохранять пары ключ/значение данных (например, объекты).

Пары ключ/значение, сохраняемые в API веб-хранилища, всегда представлены в виде строк (целочисленные ключи автоматически преобразуются в строки).

Существует набор методов, предоставляемых API веб-хранилища, которые вы можете использовать для доступа, удаления и изменения пар ключ/значение.

В API веб-хранилища доступны два типа хранилища:

1. sessionStorage,
2. localStorage.

Что такое LocalStorage

LocalStorage – это часть API веб-хранилища. Он позволяет сохранять постоянные данные (данные сохраняются при перезагрузке браузера и даже при закрытии и повторном открытии браузера) в объекте Window браузера в виде пар ключ/значение строк.

Существует пять методов для работы с LocalStorage:

1. setItem – устанавливает значение для указанного ключа,
2. getItem – возвращает значение, связанное с указанным ключом,
3. removeItem – удаляет пару ключ/значение по указанному ключу,
4. clear – удаляет все пары ключ/значение из LocalStorage,
5. key – возвращает имя ключа по указанному индексу.

Разница между sessionStorage и localStorage

И sessionStorage, и localStorage являются частью API веб-хранилища.

sessionStorage доступно только до закрытия браузера, после чего данные удаляются. sessionStorage доступно при перезагрузке, но данные удаляются при закрытии браузера.

localStorage сохраняет данные даже после закрытия браузера, они остаются в нем.

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

И sessionStorage, и localStorage предоставляют схожие методы для доступа и сохранения данных в браузере.

Мы узнаем подробнее о методах LocalStorage ниже.

Методы LocalStorage

В LocalStorage доступно пять методов. С помощью этих методов вы можете сохранять, получать, удалять и очищать данные.

1. setItem(): Сохранение данных в LocalStorage

С помощью метода localStorage.setItem() вы можете сохранять пары ключ/значение в локальном хранилище. Вот пример, как можно сохранить данные.

В данном примере candy name является ключом, а Mars Bar – значением. Обратите внимание, что LocalStorage сохраняет только строки.

Существует несколько способов сохранения данных в LocalStorage с использованием метода setItem. Вы можете осуществлять доступ к данным в виде объекта:

Это разрешено, но не рекомендуется, так как пользовательский ключ может быть чем угодно, например, toString или length, или любым другим встроенным методом имени в LocalStorage.

В этом случае методы getItem и setItem будут работать нормально, но метод в виде объекта будет работать некорректно.

2. getItem(): Получение данных из LocalStorage

С помощью метода getItem() мы можем получить значения ключ/значение, сохраненные в LocalStorage.

Метод getItem() принимает ключ и возвращает значение в виде строки.

Этот пример вернет значение “Mars Bar”.

С помощью нотации в виде объекта также можно получить данные, хотя это не рекомендуется.

3. removeItem(): Удаление элемента из LocalStorage

С помощью метода removeItem() вы можете удалить любой элемент из LocalStorage.

Передайте ключ элемента, который необходимо удалить, в метод removeItem(), и он будет удален из LocalStorage.

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

Как видите, при использовании свойства length показывается, что в LocalStorage есть 2 элемента. После удаления одного элемента остается только один элемент в локальном хранилище.

4. clear(): Очищает LocalStorage

Метод clear() API LocalStorage позволяет очистить всё хранилище и удалить все данные из LocalStorage.

Давайте воспользуемся консолью, чтобы увидеть, как работает метод clear в LocalStorage.

Мы будем использовать свойство length, чтобы проверить количество элементов в LocalStorage.

5. key(): Возвращает ключ n-го элемента хранилища

Метод key() может принимать любое целое число и возвращает ключ, сохраненный в n-м элементе объекта хранилища.

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

Мы добавили пары ключ/значение в LocalStorage:

Давайте воспользуемся свойством length для проверки содержимого localStorage.

Как вы знаете, индексация начинается с 0. Посмотрим, что находится по индексу 0.

И давайте посмотрим, что находится по индексу 1.

Свойство хранилище

length : количество пар ключ/значение, сохраненных в локальном хранилище

Свойство length доступно только для чтения и только через интерфейс localStorage. Оно возвращает количество пар ключ/значение, сохраненных в локальном хранилище.

Мы можем использовать свойство length для проверки, заполнено ли локальное хранилище.

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

Теперь свойство length также можно использовать для проверки, пусто ли локальное хранилище. Давайте очистим локальное хранилище и посмотрим, что произойдет, если мы используем свойство length.

Оно вернет 0. Таким образом, если свойство length возвращает 0, это означает, что локальное хранилище пустое.

Событие хранилища

Событие хранилища срабатывает каждый раз, когда происходит изменение в объекте хранилища.

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

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

Конструктор

StorageEvent() возвращает новый объект StorageEvent.

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

Создание нового экземпляра StorageEvent:

Он возвращает:

Свойства экземпляра

Keys (только для чтения)

Возвращает строку, представляющую ключ, который был изменен. Атрибут ключа равен null, когда изменение вызвано методом clear().

newValue (только для чтения)

Возвращает строку с новым значением измененного ключа. Оно равно null, когда был использован метод clear() или ключ был удален.

oldValue (только для чтения)

Возвращает строку с исходным значением ключа. Оно равно null, когда новый ключ был добавлен там, где раньше его не было.

storageArea (только для чтения)

Возвращает объект хранилища, представляющий затронутую область хранилища.

url (только для чтения)

Возвращает строку с URL-адресом документа, ключ которого был изменен.

LocalStorage: Интересные факты

localStorage всегда хранится в формате строки UTF-16. Целочисленные ключи преобразуются в строки и сохраняются в localStorage.

Данные localStorage определены для протокола браузера и веб-сайта. Например, данные будут разными для протоколов HTTP и HTTPS.

Для документов, загруженных из файла, требования к localstorage не определены и будут разными для разных браузеров.

Данные localStorage для инкогнито-режима или приватных браузеров будут удалены при закрытии браузера.

Ограничения localStorage

Вот некоторые ограничения для использования localStorage:

1. Ограничение до 5 МБ данных.
2. Не храните чувствительные данные в localStorage, так как они могут быть легко получены через использование cross site scripting (межсайтового сценария).
3. localStorage работает синхронно, значит, к нему обращаются последовательно.

Совместимость localStorage с браузерами

LocalStorage совместим с последними версиями браузеров. Только очень старые браузеры, такие как Internet Explorer 6 или 7, не поддерживают localStorage.

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

Пользователь также может отключить localStorage.

Исключения

securityError — это ошибка безопасности, которая возникает в следующих случаях:

1. Ошибка недопустимой схемы/хоста/порта происхождения. Это происходит, когда происхождение использует схемы file: или data:. Многие современные браузеры считают происхождение file: непрозрачным происхождением. Это означает, что файлы, находящиеся в одной папке, считаются разными источниками и могут вызывать ошибку CORS.
2. Запрос нарушает решение политики. Например, пользователь отключил использование localStorage в браузере.

Заключение

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

Файловая хранилка

Как правило, файловое хранилище — это сетевые папки на сервере с доступом по SMB, в лучшем случае располагающееся на RAID-массиве. Какие основные опасности подстерегают:

• пользователь с правом записи случайно удалил/фатально изменил файл;
• атака робота-шифровальщика;
• сбой или выход из строя железа.

Это самый простой случай и вариантов резервирования данных здесь масса. Например, скрипты, утилиты (в том числе и бесплатные) бэкапирования папок на другой носитель, снапшоты и так далее. Когда количество таких папок измеряется сотнями, а объём данных — терабайтами, остро встаёт вопрос, как этим управлять, узнавать о неудачных бэкапах и быстро их восстанавливать. Мы в «Кнопке» уже много лет пользуемся Open Source решением Bareos. Это решение для централизованных бэкапов корпоративного класса. Система работает с файлами, хотя есть возможность научить её работать, например, с базами данных.

Система состоит из:

1. Директора — управляющий демон, который запускает задания и следит за их выполнением.
2. Демонов хранения (Storage Daemon) — служба, предоставляющая устройства хранения (это может быть лента, папка на диске).
3. Файловых демонов — служб на бэкапируемых машинах, которые выполняют команды директора. Они существуют для различных ОС, поэтому решение годится не только для инфраструктуры *nix.

Хранение и управление развёрнуто на специально выделенном сервере с большим количеством дисков, объединённых в RAID-массив. Наличия инструмента для резервирования недостаточно, не менее важен план резервного копирования. Мы очень дорожим своими данными, поэтому поступаем так:

• первого числа каждого месяца создаём полную копию — её храним 3 месяца;
• еженедельно создаём дифференциальные копии — их храним месяц;
• ежедневно создаём инкрементальные копии — их храним неделю.

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

Файловые базы 1С

Для файловых баз подходит Bareos — он отлично работает с теневыми копиями, поэтому может копировать и заблокированные файлы. Если баз не так уж много, подойдёт инструмент «Обновлятор 1С». Мы резервируем файловые базы 1С так же, как и файловые ресурсы.

Базы данных

В «Кнопке» мы используем PostgreSQL, поэтому примеры будут для неё, хотя в общем смысле они подходят и для других СУБД.

В самом начале мы использовали Bareos, но в настройках клиента указывали плагин, который запускал pg_dump для базы. Полученный файл забирался на сервер архивации, ротация обеспечивалась настройкой архива, схожей с настройками для файловых ресурсов. Но базы росли, pg_dump был всё медленнее, а однажды тестовое восстановление показало неконсистентность архива: некоторые таблицы в базе стали слишком большого размера для pg_dump. К этому времени размер баз 1С у нас перевалил за 500 Гб и намекал, что будет расти и дальше.

А ещё жизнь нам подсказывала, что «помнить» только одно состояние в день недостаточно.

Мы стали использовать pg_basebackup и архивацию wal. Логи хранили неделю. Этот подход позволял нам восстанавливать состояние на любой момент времени. Однако были и минусы. За возможность восстанавливаться на произвольный момент времени потребовалось огромное количество места на сервере с бэкапами.

Нашу проблему решила утилита pg_probackup. Она даёт возможность делать дифференциальные и инкрементальные бэкапы, гибко управлять планом бэкапа, проверять консистентности бэкапа без его восстановления.

Какие копии баз 1С у нас имеются на текущий момент:

• копия на начало года;
• копия на первое число каждого квартала (последние четыре квартала);
• копия на начало каждого месяца;
• полная копия на каждый день за последнюю неделю;
• архив WAL за последнюю неделю.

Настройки сетевых устройств

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

В «Кнопке» мы используем RANCID. Эта утилита работает с различными сетевыми устройствами, собирает с них конфиги по расписанию, её можно подружить с SVN и видеть историю изменений в конфигах.

Бэкап судного дня

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

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

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

Проверка бэкапов

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

О чём важно не забыть при резервировании данных

• организуйте мониторинг успешности бэкапов;
• периодически проверяйте развёртывание критичных данных;
• следите за схематичной документацией о резервном копировании.

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

Будет здорово, если эта статья поможет улучшить работу с резервными копиями. А если вы не согласны с нашим выбором, то пишите в комментариях о наших ошибках 🙂

Содержание:

0:17 Знакомство с MinIO

3:54 MinIO docker-compose.yml

5:43 Разработка микросервиса на Golang

28:08 Текущее состояние системы заметок

Знакомство с хранилищем MinIO

MinIO создано для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии, а также образы виртуальных машин и контейнеров. Небольшой размер позволяет включать его в состав стека приложений. В MinIO также поддерживается распределённый режим (Distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.

MinIO крайне минималистичо, у него нет красивого и функционального UI. Но по части использования ресурсов оно крайне жадное — оперативную память и процессор кушает достаточно много. Также хочу отметить, что такие известные решения, как FreeNAS и TrueNAS под капотом используют именно MinIO.

В MinIO используется внутренний механизм избыточного кодирования (Erasure coding), обеспечивающий системе достаточную устойчивость, чтобы она оставалась работоспособной даже при отказе половины дисков. Также хранилище управляет целостностью и безопасностью данных, используя собственное хеширование и шифрование на стороне сервера.

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

Использование MinIO Erasure Coding

Erasure Coding — это программная защита данных от повреждения и потери. Как рейд, только намного надёжней. Если классический RAID 6 может позволить себе потерять 2 диска, то MinIO спокойно переживает потерю половины.

Вся информация хранится в виде блоков данных, к которым есть блоки чётности. И вроде это всё уже было сделано много раз, только есть важное «но»: мы можем явно указывать соотношение блоков чётности к блокам данных для хранимых объектов.

Хотите 1:1? Пожалуйста! Хотите 5:2? Без проблем! Очень важная функция, если вы используете сразу несколько нод и хотите найти свой собственный баланс между максимальной безопасностью данных и количеством затраченных ресурсов.

Из коробки MinIO использует формулу N/2 (где N — общее количество дисков), т.е. делит ваши данные между N/2 дисками данных и N/2 дисками чётности. Перевожу на человеческий: можно потерять половину дисков и восстановить данные. Это соотношение задаётся через Storage Class, позволяя вам самостоятельно выбрать, что важнее — надёжность или ёмкость.

Предположим, что у вас инсталляция на 16 дисков и вам надо сохранить файл размером 100 Мб. Если используются настройки по умолчанию (8 дисков под данные, 8 под блоки чётности), то файл в итоге займёт практически двойной объём т.е. 200 Мб. Если отношение дисков будет 10/6, то понадобится 160 Мб. 14/2 — 114 Мб.

Настройка и запуск MinIO

Cкачиваем файлы docker-compose.yml и nginx.conf, после чего можно запускать.

Давайте поближе посмотрим docker-compose файл.

По дефолту здесь 4 сервиса MinIO. Их количество можно увеличить до 16, но мы уменьшим до 2, чтобы сохранить кластер. Большее количество узлов для нас сейчас избыточно. Также здесь описан сервис NGINX, для которого мы скачивали конфигурацию. Он нужен для балансировки запросов между узлами кластера.

Описание сервисов MinIO по сути одинаковое. Давайте посмотрим на minio1:

• image с тегом релиза от определенной даты;
• два volume, их можно распределить по разным физическим дискам, чтобы обеспечить отказоустойчивость;
• наружу выставляется 9000 порт для обращения к API;
• указываются переменные среды с логином и паролем доступа к MinIO;
• команда для запуска сервера MinIO в URL  которой используется синтаксис указания множества серверов: [http://minio{1…2}](http://minio{1…2})/data{1…2} раскрывается как массив http://minio1/data1 и http://minio2/data2;

Далее описан healthcheck, который позволяет мониторить здоровье сервиса. У него есть параметр test. Это Shell-команда, которая вызывает Curl и передает ему URL для проверки того, живёт ли сервис. Делать такую проверку мы будем каждые 30 секунд. Если за 20 секунд сервис не ответит, он будет помечен как нездоровый.

Запустив compose-файл, открываем интерфейс в браузере. Слева в сайдбаре отображены бакеты — корзины, в которых хранятся файлы, справа — список файлов в бакете. Функционал здесь минимален: можно загрузить, расшарить или удалить файл и создать или удалить бакет.

На этом знакомство с MinIO завершено, далее — продолжение разработки системы заметок с нуля. В предыдущих частях мы:

• спроектировали микросервисную архитектуру;
• разработали RESTful API Service на Golang cо Swagger и авторизацией;
• познакомились с графовой БД Neo4j и работали над микросервисами CategoryService и APIService;
• разработали микросервисы NoteService, TagService и UserService.

Исходный код проекта на GitHub

Какая текущая ситуация? Мы разработали все сервисы. Осталось реализовать веб-клиент в виде приложения на Vue.js, а также заняться инфраструктурой системы, такой как Service Discovering и OpenTracing, упаковать все сервисы в docker-контейнеры и настроить CI/CD.

Хранение информации

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

Однако любое изменение в трафике вызывает осложнения. В случае перегрузки запросами одного дата-центра, трафик перенаправляется в соседний. В то же время представители компании сообщают, что пользователи преимущественно заходят в соцсеть из двух-трёх регионов. Необходимость хранения трафика в 2−3 дата-центрах обусловлена выполнением требований устойчивости к ошибкам. При этом, данные занимают меньше места и требуется меньше соглашений о качестве предоставляемых услуг. Несмотря на некоторые минусы, для Facebook плюсов оказалось гораздо больше.

Кэширование

По словам специалистов Facebook, распределённое кэширование неэффективно для компании, поскольку:

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

Архитектура Akkio

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

Хранение расположения данных. Решение о хранении или перемещении данных в один из дата-центров принимается на основе трёх последних запросов. Возникает вопрос о перегруженности сети для каждого из таких запросов. Однако данные для одного пользователя объединены в группы с другими. Поэтому микросегмент с новостной лентой пользователя окажется проводником для определения будущего расположения остальных данных.

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

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

Учёт вместительности. Происходит расчёт факторов (наличие свободного места, загруженность сети и т.д.), после чего DPS генерирует значение для каждого доступного дата-центра. Если расположение микросегмента неоптимально, служба перемещает его в соответствии с полученным значением.

Умное мапирование. Размещение в ZippyDB происходит при помощи определённой хэш-функции. Во избежание одновременного перемещения одинаковой информации, она упорядочена и блокируется на уровне метаданных. Служба DPS обращается к данным и в случае их недоступности отменяет любые действия до следующего обращения к микросегменту.

Помимо вопросов о распределении данных, Facebook продолжает развивать направление виртуальной реальности. В конце сентября 2018 года на пятой ежегодной конференции Oculus Connect по виртуальной реальности в Сан-Хосе компания представила свою новую автономную VR-систему Oculus Quest. Новинка обеспечивает шесть степеней свободы и не нуждается в компьютере или смартфоне.

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

Особенности нового способа хранения данных

По утверждению доктора Ника Рисена (Nick Riesen) из Университета Южной Австралии, флуоресценция нанокристаллов соли может представлять собой перспективную альтернативу традиционному магнитному жесткому диску, твердотельным носителям информации или Blu-Ray дискам. В частности, в процессе экспериментов была продемонстрирована возможность перезаписываемого оптического хранения данных в нанокристаллах, которые в 100 раз меньше, чем может различить человеческий глаз.

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

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

Ведущими IT-компаниями проводятся активные изыскания в области увеличения способов хранения больших объемов данных. Так, компания Microsoft разрабатывает систему хранения, которая будет работать на основе ДНК. Ее запуск запланирован на 2020 год.

Популярный инструмент

MPEG-2 применяется в эфирном вещании по стандартам ATSC и DVB-T, охватывающим практически весь земной шар. Несмотря на активное развитие и распространение цифрового вещания, за которое отвечает уже стандарт MPEG-4 AVC, его предшественник до сих пор массово применяется в оборудовании для ведения прямых трансляций. Это связано с низкой задержкой кодирования по сравнению с более современными технологиями.

Напомним, что в мае 2017 года истёк патент на MP3 — один из самых популярных форматов хранения аудиофайлов. Тогда же его создатели заявили о прекращении поддержки этого кодека.

Представители организации утверждают:

Каждая точка кодирует 8 бит информации в пяти плоскостях. Объем одного диска — примерно 360 терабайт, а срок службы — более 14 миллиардов лет. Ни одно другое устройство не может обеспечить такие показатели.

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

Послание в будущее

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

Создание и запуск дисков отдаленно напоминает миссию корабля Voyager в 1977 году, когда в космос были отправлены аудио- и видео-фрагменты жизни людей.

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

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

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

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

Зачем ДНК, если есть облака?

Согласно результатам недавнего исследования, спрос на хранилища информации вырастет на 40% за год. А через 10 лет потребуется в 50 раз больше места для хранения данных. Всё это подразумевает постоянное обновление, исправление и замену устаревающего программного аппарата, необходимого для сохранения данных.

По словам Карина Стросса, доктора наук и старшего исследователя в компании Microsoft:

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

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

В чем преимущества ДНК-хранилищ?

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

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

HVIF был создан разработчиками HaikuOS, открытой операционной системы, вдохновлённой BeOS. Этот формат используется в качестве основного для системных иконок. Основной целью, которая была поставлена при разработке формата, было сделать файлы иконок как можно меньшими по весу. Векторный формат позволяет отображать иконки в хорошем качетсве,в отличии от bitmap форматов, сохраняя малый вес. Настолько малый, что иконку можно включить в метаданные файла, и таким образом ограничить количество обращений к диску.

В отличии от других операционных систем, HaikuOS не показывает миниатюры pdf файлов или изображений, вместо этого используются абстрактные иконки. Обычно иконки представляют из себя bitmap, и BeOS перенял этот стандарт не глядя. В нём были иконки двух размеров — 16×16 и 32×32. Посколько bitmap-изображения содержат лишь информацию о том какой пиксель в какой цвет должен быть окрашен, изменение их размера приводит либо к размытостям, либо к сильной шакалпикселизации. Изображения каждого разрешения представляет из себя отдельный файл, и хранится так же отдельно. Вместе они занимают 1280 байтов (1024 — для 32×32 и 256 — для 16×16). С тех пор (с 1990-х) иконки стали больше, в современных операционных системах используются изоображения 64×64 и даже 128х128. Даже если забыть про 128×128, то 64×64 это уже больше 5 килобайт веса. Каждый такой шажок по удвоению размеров иконки увеличивает количество байт для bitmap-изображения в четыре раза, и это ужасно.

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

Таким образом, HVIF примерно в десять раз (файлы HVIF имеют средний рамер от 500 до 700 байт, а при желании можно уместиться и в 256) выигрывает по размерам как у bitmap изображения 64×64 (которое, к тому же, не может красиво масштабироваться), так и у самого популярного векторного формата SVG, который проигрывает HVIF из-за использования обычного текста в XML формате, а не бинарных файлов. Обратная сторона медали заключается в том, что структура бинарного файла HVIF накладывает определённые ограничения (256 элементов) на сложность изображения. Предполагается, что для иконок этого более чем достаточно.

К слову, идея использовать для отображения иконок векторный формат сама по себе не нова — такой подход был осуществлён в IRIX, а так же поддерживается в популярных оболчках для Linux — Gnome и KDE.

Вы можете сказать, что несколько килобайт для современных дисков (или даже для RAM) это очень и очень мало. Это так. Почему же тогда разработчики HVIF так заботятся о размере? Ведь иконок в системе не миллионы (даже не сотни или не десятки тысяч), чтобы несколько килобайтов как-то могли повлять на загруженность диска. Оказывается, дело в скорости. Один цикл ЦП составляет около четверти наносекунды; чтение из оперативной памяти — 60 наносекунд; чтение из относительно быстрого современного SSD — 20 микросекунд (т.е. 20 000 наносекунд); чтение с медленного диска — 10 миллисекунд (10 000 000 наносекунд). Обращения к диску — самые затратные по времени операции для операционной системы. Создатели HaikuOS вместо двух вызовов к диску (к метаданным и к файлу иконки) хотят оставить один — к метаданным, в которых сможет поместиться иконка. Это должно давать ощутимый прирост к скорости отображения, даже при условии того, что векторные форматы отображаются дольше (ведь перед отображениям они, фактически, должны быть конвертированы в bitmap-изображения, подогнанные под конкретный размер).

Похожую работу проводили в Facebook для быстрого отображения миниатюр изображений. Правда, тогда дело свелось не к полноценному новому формату, а к подредактированному размытому JPEG.

Больше технических подробностей про формат можно узнать в обзорной статье.

При этом Facebook приводит убедительные графики тестов, которые подтверждают эффективность стандарта:

Zstd придётся бороться с двумя другими открытыми стандартами сжатия — LZFSE от Apple и Brotli от Google. В LZFSE создатели постарались оптимизировать скорость сжатия и энергопотребления, оставив степень сжатия без изменения, в то время как Brotli борется за повышение эффективности сжатия, чтобы его можно было использовать для веба и APK-файлов для Android.

Технические подробности можно узнать на странице проекта на GitHub.