Настоящий CTO: думай как технический директор - Алан Уильямсон

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

Заметки с полей

Ограниченные знания опасны

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

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

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

8.5.2. Типы данных

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

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

• Система учета – данные, которые считаются ключевыми для вашей компании, обычно они содержатся в БД. Данные этой категории считаются «истиной» для организации.

• Конфиденциальные/охраняемые данные – в эту категорию попадают данные, требующие дополнительной защиты. Примеры: паспортные данные, номера водительских прав, банковская информация, данные кредитной карты.

• Транзакционные данные – данные, которые генерируются в процессе продаж или оказания основных услуг; их часто называют операционными данными.

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

• Данные журналов – данные, генерируемые различными компонентами и программами, обеспечивающими работу системы. Эти данные используются для расследования ошибок/сбоев и аудита, а также для анализа производительности.

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

• Права собственности. Кто владеет данными этого класса? Проще всего предположить, что владелец – вы. Наличие прав собственности означает, что вы можете делать с данными все, что пожелаете (продать, удалить или даже сделать общедоступными, если захотите). Проведя анализ, вы, вероятно, обнаружите, что у вас есть данные клиентов/пользователей, которыми вы просто управляете. Также данные могли быть арендованы вами на ограниченный период времени (например, списки рассылки или наборы данных для анализа). Определение истинного владельца данных позволит вам выяснить, для чего и как разрешено их использовать.

• Хранение. Как долго предполагается хранить данные? Этот вопрос касается как оперативных хранилищ, так и резервных копий (если правами собственности это предусмотрено). Сюда же относится политика устаревания: как долго хранить данные до перемещения в долгосрочное (более дешевое) хранилище? В каких случаях можно удалить все данные, включая резервные копии (например, если клиент уходит от вас)?

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

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

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

Особо следует выделить данные, для которых необходимо обеспечить соответствие нормативным требованиям. В основе любых ограничений (PII, HIPAA, PCI и др.) лежит требование безопасного и бережного обращения с данными. Если у вас есть такие данные, то, управляя ими, внедряйте все возможные способы защиты. Хотя для некоторых типов данных это может быть излишним, но это гарантирует, что вы выработаете в команде привычку относиться к этим данным ответственно, поэтому возможный аудит не станет потрясением и неожиданностью. Также планирование архитектуры с учетом обеспечения безопасности данных и возможности аудита обеспечит страховку на случай любых будущих изменений.

8.6. Микросервисы или монолит

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

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

Рассмотрим таблицу 8.4. Если вы отметите «да» для трех или более признаков, то, скорее всего, вы работаете с монолитной архитектурой.

Таблица 8.4. Признаки микросервисной и монолитной архитектуры

Микросервисы – это искусство разделения системы на отдельные «мини-приложения» с узкой областью применения, выполняющие определенное действие или функцию. Взаимодействие между ними осуществляется через API, служебную шину (service bus) или очередь сообщений. Надежный микросервис – это независимый компонент со своим собственным хранилищем данных, средой выполнения (на основе подходящего языка/библиотеки) и релизным циклом, который не влияет на другие части системы.

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

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

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