Хаос — естественное состояние Вселенной. В закрытых системах постепенно растет энтропия, и этого не изменить. Хранилище данных по своей природе тоже тяготеет к хаосу, но можно поддерживать в нем порядок.
Хаос — естественное состояние Вселенной. В закрытых системах постепенно растет энтропия, и этого не изменить. Хранилище данных по своей природе тоже тяготеет к хаосу. Если не поддерживать в нем порядок, то в конечном счете вы получите мешанину из объектов, в которых будет сложно ориентироваться и которыми будет невозможно управлять, и не решитесь их удалить. Некогда обслуживанием баз данных занимались специальные администраторы, но теперь в большинстве случаев за порядок в данных не отвечает никто (то есть кто угодно).
Регулярное обслуживание хранилища чрезвычайно важно для команды специалистов по обработке данных. В хранилище данных с плохим обслуживанием:
В этой статье, опираясь на свой многолетний опыт работы с информацией в разных организациях и стеках данных, мы приводим самые эффективные методы обслуживания аналитических хранилищ данных. Мы постарались уложить эти знания в пять правил, которые, с нашей точки зрения, подойдут для любого обслуживаемого хранилища данных.
В хранилище данных есть множество объектов, которым нужно присвоить имя: базы данных, схемы, отношения, столбцы, пользователи и общие роли. В Snowflake, например, в именах также нуждаются хранилища (warehouses; то есть вычислительные ресурсы), стадии (stages) и каналы (pipes).
Последовательный подход к именованию позволяет реже задумываться при создании объектов и облегчает пользователям понимание структуры хранилища. Только без фанатизма! Мне встречались хранилища, где напридумывали столько правил именования, что без знания этих правил было сложно ориентироваться (например, вариант d_account_v.f_active использовался вместо интуитивно понятного accounts.is_active). Поэтому очень важно использовать осмысленные имена.
Вот несколько наших правил именования объектов в хранилище.
Типовые элементы обозначаются с помощью префиксов и суффиксов, например все столбцы с временными метками заканчиваются на _at, все таблицы измерений начинаются с dim_, а столбцы метаданных начинаются с символа подчеркивания.
Приоритет — удобочитаемость, а не краткость. Например, вариант customer_account_id лучше чем cust_acc_id.
В именах используется только стиль snake_case (подчеркивания вместо пробелов).
После выбора метода именования мы рекомендуем оформить его в виде правил и распространить среди всех пользователей хранилища. Мы включили все наши правила именования в руководство по стилю dbt.
Очень сложно давать рекомендации, не привязанные к конкретному хранилищу данных. В дальнейшем в этой публикации я буду использовать для обозначения пользователей, групп и ролей два абстрактных понятия:
Если пользователей много, точечно управлять их привилегиями очень трудно. Поэтому мы предоставляем привилегии общим ролям (об этом далее), а пользователи наследуют их путем членства в этих ролях. Мы стремимся создавать как можно меньше общих ролей с именами loader, transformer и reporter — и даже если ваше хранилище данных допускает это, не следует использовать многоуровневую иерархию общих ролей, так она зачастую усложняет администрирование.
Слишком свободная в плане привилегий схема может привести к непоправимым ошибкам, а излишне строгая схема будет тормозить работу рядовых пользователей базы данных, которые хотят просто выполнять свою работу.
Следует избегать усложнения схемы привилегий. Чем она мудренее, тем сложнее ее поддерживать, — будет непросто определить, кто и к чему имеет доступ и какие привилегии следует давать при добавлении нового пользователя или схемы.
Мы обнаружили, что упрощенная структура привилегий в сочетании с общими ролями обеспечивает оптимальный баланс между уровнем контроля и простотой обслуживания. В наших хранилищах данных мы реализуем следующие два стиля привилегий.
Пользователи должны наследовать привилегии путем членства в общих ролях. Следовать такой схеме чрезвычайно просто — при добавлении пользователя в хранилище данных достаточно сделать его членом надлежащей общей роли. Аналогично, при добавлении схемы в хранилище данных достаточно назначить привилегии соответствующим общим ролям.
Во-первых, мы ограничиваем доступ к учетной записи root-пользователя в Postgres и Redshift и к роли AccountAdmin в Snowflake. Пароль к ним предоставляется только в случае необходимости (но важно проследить, чтобы он не был утерян при увольнении сотрудников из организации).
Во-вторых, мы следим, чтобы пользователи не получали права суперпользователя по умолчанию. Реализация этого правила зависит от типа хранилища данных и от того, как в нем работает наследование прав.
Источник статьи: https://habr.com/ru/company/otus/blog/569102/
Хаос — естественное состояние Вселенной. В закрытых системах постепенно растет энтропия, и этого не изменить. Хранилище данных по своей природе тоже тяготеет к хаосу. Если не поддерживать в нем порядок, то в конечном счете вы получите мешанину из объектов, в которых будет сложно ориентироваться и которыми будет невозможно управлять, и не решитесь их удалить. Некогда обслуживанием баз данных занимались специальные администраторы, но теперь в большинстве случаев за порядок в данных не отвечает никто (то есть кто угодно).
Регулярное обслуживание хранилища чрезвычайно важно для команды специалистов по обработке данных. В хранилище данных с плохим обслуживанием:
- Столбцы, таблицы, схемы и базы данных имеют несогласованные, а порой нелогичные имена.
- Многие пользователи выполняют простые выборки данных из учетной записи root-пользователя.
- Активно используются публичные схемы и роли.
- Объекты в схемах имеют несогласованные права владения, привилегии и происхождение.
- Как те или иные данные попали в это хранилище?
- У кого есть доступ к этим данным?
- Что случится, если удалить эту таблицу? Ею вообще кто-то пользуется? Зависят ли от нее нижестоящие процессы?
- Кто сделал этот ресурсоемкий запрос?
- Как мне назвать нового пользователя, схему, таблицу, столбец?
В этой статье, опираясь на свой многолетний опыт работы с информацией в разных организациях и стеках данных, мы приводим самые эффективные методы обслуживания аналитических хранилищ данных. Мы постарались уложить эти знания в пять правил, которые, с нашей точки зрения, подойдут для любого обслуживаемого хранилища данных.
- Используйте схемы для логической группировки объектов.
- Именуйте объекты в хранилище согласованно и осмысленно.
- Используйте разные учетные записи для каждого человека и каждого приложения, которые подключаются к хранилищу данных.
- Систематизируйте привилегии.
- Ограничьте доступ к привилегиям суперпользователя.
Используйте схемы для логической группировки объектов
Схемы позволяют логически объединять объекты в группы, подобно группировке файлов в каталогах. В пределах одной схемы:- Все отношения (то есть таблицы и виды) должны создаваться одним процессом.
- Все отношения должны иметь одного владельца.
- Ко всем отношениям следует применять одинаковые привилегии (см. ниже).
- Не нужно использовать публичную схему.
- Для источников данных каждому источнику должна соответствовать своя схема с осмысленным именем, например: stripe или zendesk. В Snowflake мы часто группируем их в необработанной базе данных, в то время как в Redshift мы нередко дополняем имена схем источников данных префиксом raw, например: raw_stripe.
- Для рабочих преобразований, которые запрашиваются инструментами бизнес-аналитики, группируйте модели по бизнес-направлениям, например: core (общая модель данных), marketing или finance.
- Для проектных преобразований группируйте модели по их владельцу, например в схеме с именем dbt_claire.
Именуйте объекты в хранилище согласованно и осмысленно
Об этом вы уже не раз слышали: придумывать имена очень тяжело.В хранилище данных есть множество объектов, которым нужно присвоить имя: базы данных, схемы, отношения, столбцы, пользователи и общие роли. В Snowflake, например, в именах также нуждаются хранилища (warehouses; то есть вычислительные ресурсы), стадии (stages) и каналы (pipes).
Последовательный подход к именованию позволяет реже задумываться при создании объектов и облегчает пользователям понимание структуры хранилища. Только без фанатизма! Мне встречались хранилища, где напридумывали столько правил именования, что без знания этих правил было сложно ориентироваться (например, вариант d_account_v.f_active использовался вместо интуитивно понятного accounts.is_active). Поэтому очень важно использовать осмысленные имена.
Вот несколько наших правил именования объектов в хранилище.
Типовые элементы обозначаются с помощью префиксов и суффиксов, например все столбцы с временными метками заканчиваются на _at, все таблицы измерений начинаются с dim_, а столбцы метаданных начинаются с символа подчеркивания.
Приоритет — удобочитаемость, а не краткость. Например, вариант customer_account_id лучше чем cust_acc_id.
В именах используется только стиль snake_case (подчеркивания вместо пробелов).
После выбора метода именования мы рекомендуем оформить его в виде правил и распространить среди всех пользователей хранилища. Мы включили все наши правила именования в руководство по стилю dbt.
Используйте разные учетные записи для каждого человека и каждого приложения, которые подключаются к хранилищу данных
Прежде чем перейти к этому пункту, стоит отметить, что в разных хранилищах данных пользователи, группы и роли могут рассматриваться по-своему (если не боитесь углубиться в эту тему, прочтите мою статью в Discourse).Очень сложно давать рекомендации, не привязанные к конкретному хранилищу данных. В дальнейшем в этой публикации я буду использовать для обозначения пользователей, групп и ролей два абстрактных понятия:
- Пользователь: одиночный набор учетных данных для входа.
- Общая роль: группа (в Redshift) или роль (в Postgres и Snowflake), членом которой может быть пользователь.
Если пользователей много, точечно управлять их привилегиями очень трудно. Поэтому мы предоставляем привилегии общим ролям (об этом далее), а пользователи наследуют их путем членства в этих ролях. Мы стремимся создавать как можно меньше общих ролей с именами loader, transformer и reporter — и даже если ваше хранилище данных допускает это, не следует использовать многоуровневую иерархию общих ролей, так она зачастую усложняет администрирование.
Систематизируйте привилегии
Хранилища данных позволяют настраивать привилегии очень точно. Пользователю или общей роли можно назначить любую комбинацию из следующих привилегий (фактически это лишь поднабор возможных вариантов):- Для базы данных: использование, создание.
- Для схемы: использование, создание.
- Для таблицы: выбор, вставка, обновление, удаление, обрезание, создание связей и ссылок.
Слишком свободная в плане привилегий схема может привести к непоправимым ошибкам, а излишне строгая схема будет тормозить работу рядовых пользователей базы данных, которые хотят просто выполнять свою работу.
Следует избегать усложнения схемы привилегий. Чем она мудренее, тем сложнее ее поддерживать, — будет непросто определить, кто и к чему имеет доступ и какие привилегии следует давать при добавлении нового пользователя или схемы.
Мы обнаружили, что упрощенная структура привилегий в сочетании с общими ролями обеспечивает оптимальный баланс между уровнем контроля и простотой обслуживания. В наших хранилищах данных мы реализуем следующие два стиля привилегий.
- read-schema: возможность делать выборку из схемы и всех входящих в нее отношений.
- create-schema: возможность создавать схему в базе данных, а значит, создавать входящие в нее отношения и иметь все привилегии в них.
- loader: create-schema.
- transformer: read-schema, create-schema.
- reporter: read-schema (ограничено схемами преобразований).
Пользователи должны наследовать привилегии путем членства в общих ролях. Следовать такой схеме чрезвычайно просто — при добавлении пользователя в хранилище данных достаточно сделать его членом надлежащей общей роли. Аналогично, при добавлении схемы в хранилище данных достаточно назначить привилегии соответствующим общим ролям.
Ограничьте доступ к привилегиям суперпользователя
Привилегии суперпользователя (такие как создание пользователей и удаление отношений, которые ему не принадлежат) должны применяться ограниченно. Пользователи не должны иметь учетную запись или роль с расширенными привилегиями, если им не нужно выполнять команды, требующие таких привилегий.Во-первых, мы ограничиваем доступ к учетной записи root-пользователя в Postgres и Redshift и к роли AccountAdmin в Snowflake. Пароль к ним предоставляется только в случае необходимости (но важно проследить, чтобы он не был утерян при увольнении сотрудников из организации).
Во-вторых, мы следим, чтобы пользователи не получали права суперпользователя по умолчанию. Реализация этого правила зависит от типа хранилища данных и от того, как в нем работает наследование прав.
- Postgres: создайте отдельную роль с привилегиями суперпользователя и назначайте ее только нужным пользователям. Убедитесь, что для этой роли отключено наследование, чтобы пользователи получали роль с повышенными привилегиями в явном виде.
- Redshift: создайте отдельного пользователя <имя_пользователя>_super (например, claire_super) для каждого, которому нужны привилегии суперпользователя (их можно назначать только пользователям, но не группам). По умолчанию пользователи должны подключаться к хранилищу данных с учетными данными обычного пользователя.
- Snowflake: создайте отдельную роль с привилегиями суперпользователя и назначьте ее нужным пользователям. В качестве роли по умолчанию каждому пользователю нужно назначать роль, отличную от роли суперпользователя.
Дополнительное конфигурирование
- В большинстве хранилищ данных можно реализовать белый список IP-адресов. Если есть такая возможность, рекомендуем ее использовать.
- Если вы планируете создать хранилище данных Snowflake, у моего коллеги Джереми Коэна (Jeremy Cohen) есть отличное руководство по этой теме.
- Что касается оптимизации производительности Postgres и Redshift, то это тема настолько обширная, что требует отдельной статьи.
В заключение
Если подытожить вкратце, то правильное администрирование базы данных должно следовать двум ключевым принципам:- Простота
- Согласованность
Источник статьи: https://habr.com/ru/company/otus/blog/569102/