От разрозненных хранилищ — к платформам данных

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

Прозрачность данных

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

Рис. 1. Многообразие источников данных

В большинстве компаний представление о том, какими дата-активами она обладает, как правило, имеет только специалист по аналитике соответствующего бизнес-блока или разработчик отчетов бизнес-аналитики. Это особенно актуально для таких систем, как Qlik Sense или QlikView, включающих в себя все этапы работы с данными. При этом дата-активы редко бывают описаны — подобные описания объектов обычно появляются только при проведении тендеров, когда требуется сформировать техническое задание внешним или внутренним подрядчикам. В случае компаний, для которых данные представляют безусловную ценность [2] (финансовый сектор, телеком-ретейл), прозрачность данных — краеугольный камень, определяющий весь дата-ландшафт. Для этого требуется развернуть и наполнить дата-каталог, определить дата-стюардов, выполняющих роль евангелистов изменений и отвечающих за развитие решения.

Порядок и процедуры

В компаниях, управляемых данными, обычно имеется картина того, как формируются показатели, как они рассчитываются и из каких источников собираются. А об уровне культуры работы с данными свидетельствует наличие у компании дата-каталога, поддерживаемого и наполняемого в полуавтоматическом режиме. Но этого еще не достаточно — каждому домену данных назначается ответственный сотрудник, отвечающий за поддержку каталога данных по своему домену (обычно такую роль выполняет дата-стюард). Он же формирует data-lineage — схему, показывающую путь формирования объекта на конечном слое (рис. 2).

Рис. 2. Пример data-lineage

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

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

Хорошей практикой можно считать формирование собственного фреймворка разработки, такого как «Гармония ETL» — набора вспомогательных утилит и модулей, закрывающих недостающие звенья в инструментах работы с данными категории Open Source (Apache Airflow, Apache NiFi, Apache Flink и пр.). Например, формируется структура таблиц, ETL-процедуры для загрузки и обогащения данных, подключаются технические проверки — все это только на основе описания целевой таблицы. По факту для всех стандартных случаев дата-инженеру достаточно указать поля таблицы и типы данных, а все пакеты для их наполнения, последовательность загрузок для системы AirFlow и код на Python сформируются автоматически. Применение фреймворка позволяет за счет автоматизации рутинных задач существенно сократить время на подключение источника к слою необработанных данных, а также уменьшить затраты на перегрузку данных между слоями. В готовые процедуры включаются и модули проверки данных на целостность, полноту и отсутствие дубликатов.

При помощи фреймворка, подобного «Гармония ETL», можно также подключать аудит и журналирование процессов ETL. Сведения о сформированных потоках отправляются в каталог данных (OpenMetaData, Arenadata Catalog и др.). Таким образом формируется прозрачный data lineage от системы-источника до слоя витрин в хранилище.

Безопасность

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

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

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

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

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

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

***

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

Литература

1. Михаил Зырянов. Развитие управления данными в России: факторы и векторы // Открытые системы.СУБД. — 2024. — № 1. — С. 26–32. URL: https://www.osp.ru/os/2024/01/13058244 (дата обращения: 21.06.2024).

2. Мария Аверина. Красной строкой: как данные завоевали бизнес // Открытые системы.СУБД. — 2023. — № 3. — С. 17–18. URL: https://www.osp.ru/os/2023/03/13057587 (дата обращения: 21.06.2024).

Мария Аверина (MAverina@navicons.com) – директор по стратегическому развитию, компания Navicon (Москва). Статья подготовлена на основе материалов выступления на конференции «Качество данных 2024».