Эта статья разделена на два раздела, первый раздел посвящен построению хранилища данных, второй раздел посвящен управлению данными, содержание длинное, пожалуйста, прочитайте его терпеливо!
Прежде чем говорить о количестве складов, давайте рассмотрим следующие вопросы:
Почему хранилища данных должны быть многоуровневыми?
- Обменяйте пространство на время и улучшите взаимодействие с пользователем (эффективность) системы приложений за счет большого объема предварительной обработки, поэтому в хранилище данных будет много избыточных данных; если нет многоуровневости, если бизнес-правила изменить исходную бизнес-систему, это повлияет на весь процесс очистки данных является огромной рабочей нагрузкой.
- Процесс очистки данных можно упростить за счет иерархического управления данными, потому что разделение исходной одношаговой работы на несколько шагов эквивалентно разделению сложной работы на несколько простых задач, преобразованию большого черного ящика в белый. логика обработки каждого слоя относительно проста и понятна, поэтому нам легче обеспечить правильность каждого шага.Когда возникают ошибки данных, нам часто нужно только настроить определенный шаг локально.
Отец хранилища данных, Билл Инмон, определил хранилище данных как предметно-ориентированный, интегрированный, относительно стабильный набор данных, который отражает исторические изменения для поддержки управленческих решений. С точки зрения определения, ключевые слова хранилища данных являются предметно-ориентированными, интегрированными, стабильными, отражают исторические изменения и поддерживают принятие управленческих решений, а реализация этих ключевых слов отражается в многоуровневой архитектуре.
Хорошая многоуровневая архитектура имеет следующие преимущества:
- четкая структура данных: Каждый уровень данных имеет соответствующую область действия, что облегчает поиск и понимание при использовании данных.
- Отслеживание родословной данных: службы данных, предоставляемые бизнес-персоналу или нижестоящим системам, являются целевыми данными, а источники данных целевых данных обычно поступают из данных нескольких таблиц. Если целевые данные ненормальны, чистое кровное родство может быстро определить проблему. Более того, управление родословными также является важной частью управления метаданными.
- Уменьшите повторяющееся развитие: принцип послойной обработки данных, нижний уровень содержит полный объем данных, необходимых для обработки данных верхнего уровня, этот метод обработки позволяет каждому разработчику данных повторно извлекать данные из исходной системы для обработки.
- Организация отношений данных: Существуют сложные отношения данных между исходными системами. Например, информация о клиентах существует одновременно в базовой системе, кредитной системе, системе управления активами и системе управления капиталом. Как принимать решения при получении данных? Хранилище данных будет единообразно моделировать данные одного и того же субъекта и упорядочивать сложные отношения данных в согласованную модель данных, что позволяет избежать вышеуказанных проблем при его использовании.
- Маскируйте влияние необработанных данных: Принцип послойной обработки данных, данные верхнего слоя получаются путем обработки данных следующего слоя, при этом не допускается пропуск уровней. Исходные данные расположены в нижней части хранилища данных, и существует несколько уровней обработки данных из данных прикладного уровня, поэтому в процессе обработки данных прикладного уровня изменения исходных данных будут исключены для сохранения стабильность прикладного уровня.
Сколько слоев лучше для количества складов?
В настоящее время основные методы наслоения на рынке ослепительны.Однако, глядя на вещи, вы должны смотреть не только на поверхность, но и видеть внутренние законы.Нельзя наслаивать ради наслоения.Нет лучшего, только самое подходящее.
Цель расслоения состоит в том, чтобы решить проблему быстрой поддержки данных текущего бизнеса, абстрагировать общую структуру для будущего и расширить возможности других направлений бизнеса, и в то же время обеспечить стабильную и точную поддержку данных для развития бизнеса и может быть основано на существующих Новые модели развития бизнеса задают направление, то есть опираются на данные и расширяют возможности.
Как построить хороший номерной склад?
- стабильность: Вывод данных стабилен и гарантирован.
- заслуживающий доверия: Данные чистые и качественные.
- Богатый: Бизнес, охватываемый данными, достаточно широк.
- прозрачный: Система компоновки данных достаточно прозрачна.
Дизайн хранилища данных
3 измерения дизайна хранилища данных:
- Функциональная архитектура: Уровень структуры ясен.
- схема данных: Качество данных гарантировано.
- Технологическая архитектура: Простота расширения и использования.
Архитектура хранилища данных
В зависимости от процесса поступления и оттока данных архитектуру хранилища данных можно разделить на:источник данных,база данных,Приложение данных.
база данных
Данные хранилища данных поступают из разных исходных данных и предоставляют различные приложения данных.Данные поступают в хранилище данных снизу вверх, а затем открывает приложение на верхний уровень, а хранилище данных является лишь платформой для промежуточных интегрированное управление данными.
источник данных: данные этого уровня не изменяются, структура данных и данные периферийной системы используются напрямую, и они не открыты для внешнего мира; это уровень временного хранения, который является областью временного хранения данные интерфейса для подготовки к следующему шагу обработки данных.
база данных: также известный как уровень детализации, данные слоя DW должны быть согласованными, точными и чистыми, то есть данные после очистки (удаления примесей) из данных исходной системы.
Приложение данных: Источник данных, напрямую считываемый интерфейсным приложением, данные создаются в соответствии с требованиями отчета и тематического анализа.
Хранилище данных получает данные из различных источников данных, а преобразование и поток данных в хранилище данных можно рассматривать как ETL (Извлечь лишнее, преобразовать передачу, загрузить загрузку) процесс, ETL является сборочной линией хранилища данных, и его также можно рассматривать как кровь хранилища данных.Он поддерживает метаболизм данных в хранилище данных и большую часть энергии в повседневном управлении и обслуживании. хранилища данных заключается в том, чтобы поддерживать ETL в нормальном и стабильном состоянии.
Построение хранилища данных похоже на создание новой жизни, а многоуровневая архитектура — всего лишь логический скелет этой жизни. Если вы хотите нарастить плоть и кровь на скелет, вы должны провести соответствующее моделирование данных, от результатов моделирования зависит сила или слабость хранилища данных, пригодность или уродство.
Метод моделирования хранилища данных
Существует множество способов моделирования хранилища данных.Каждый подход к моделированию представляет точку зрения в философии, представляет собой способ обобщения и обобщения мира. ОбщиеПарадигмальное моделирование, многомерное моделирование, моделирование сущностейЖдать,Каждый подход по существу будет рассматривать проблемы в бизнесе с другой точки зрения..
1. Парадигмальное моделирование
Парадигмальное моделирование на самом деле является распространенным методом, который мы используем для построения моделей данных.Этот метод в основном пропагандируется Inmon, и он в основном решает проблемы хранения данных реляционных баз данных и использует технический метод. В настоящее время большинство наших методов моделирования в реляционных базах данных используют метод трехпарадигмального моделирования.
Парадигма — это набор реляционных схем, соответствующих определенному уровню. Построение базы данных должно следовать определенным правилам, и в реляционных базах данных это правило является парадигмой, процессом, также известным как нормализация. В настоящее время существует шесть нормальных форм для реляционных баз данных: первая нормальная форма (1NF), вторая нормальная форма (2NF), третья нормальная форма (3NF), нормальная форма Бойса-Кодда (BCNF), четвертая нормальная форма (4NF) и пятая нормальная форма. (5НФ) .
При моделировании хранилища данных обычно используется третья парадигма. Отношение в третьей нормальной форме должно удовлетворять следующим трем условиям:
- Каждое значение атрибута уникально и не имеет неоднозначности;
- Каждый непервичный атрибут должен полностью зависеть от всего первичного ключа, а не от его части;
- Каждый непервичный атрибут не может зависеть от атрибутов в других отношениях, потому что тогда атрибут должен быть атрибутирован другим отношениям.
Моделирование парадигмы
По словам Инмона, метод построения модели хранилища данных аналогичен модели корпоративных данных бизнес-системы. В бизнес-системе модель данных предприятия определяет источник данных, а модель данных предприятия также делится на два уровня, а именно модель предметной области и логическую модель. Точно так же модель предметной области можно рассматривать как концептуальную модель бизнес-модели, тогда как логическая модель является воплощением модели предметной области в реляционной базе данных.
2. Метод твердотельного моделирования
Метод моделирования сущностей не является распространенным методом моделирования хранилища данных, он исходит из школы философии. С философской точки зрения объективный мир должен быть подразделен, а объективный мир должен быть разделен на сущности и отношения между сущностями. Тогда мы можем полностью внедрить этот абстрактный метод в процесс моделирования хранилища данных, а также весь бизнес можно разбить на сущности одну за другой, а связь между каждой сущностью и описание этих связей и есть наша работа по моделированию данных. нужно сделать.
Хотя материальное право может показаться несколько абстрактным, на самом деле его довольно легко понять. То есть любой бизнес-процесс мы можем разделить на 3 части,сущность, событие, описание,Как показано ниже:
твердотельное моделирование
Вышеприведенная картинка выражает абстрактный смысл, если описать простой факт: «Сяо Мин едет в школу». Взяв этот деловой факт в качестве примера, мы можем рассматривать «Сяо Мин» и «школу» как сущность, «посещение школы» описывает бизнес-процесс, мы можем абстрагироваться здесь как конкретное «событие» и «ехать в». Его можно рассматривать как описание события «идти в школу».
3. Объемное моделирование
Многомерную модель поддерживает Ральф Кималл, еще один мастер в области хранилищ данных.Его "Data Warehouse Toolbox" является наиболее популярным классическим пособием по моделированию хранилищ данных в области проектирования хранилищ данных. Многомерное моделирование строит модели на основе потребностей анализа и принятия решений, а построенные модели данных служат потребностям анализа.Поэтому оно фокусируется на том, как пользователи могут быстрее выполнить потребности анализа, и в то же время оно также имеет лучший ответ. производительность для крупномасштабных сложных запросов.
звездная схема
Типичными представителями являются известная звездная схема (Star-schema) и Снежная схема (Snow-schema), применимые в некоторых особых сценариях.
Наиболее важными понятиями в многомерном моделировании являются таблица фактов и таблица измерений. Самое простое описание — это создание хранилищ данных и киосков данных в соответствии с таблицами фактов и таблицами измерений.
В настоящее время наиболее часто используемым методом моделирования в интернет-компаниях является многомерное моделирование.
Как построить объемное моделирование:
В реальном бизнесе нам предоставляется множество данных. Как мы используем эти данные для создания хранилища данных? Автор инструментария хранилища данных обобщил для нас следующие четыре шага, основываясь на своем более чем 60-летнем реальном опыте ведения бизнеса. .
Четыре шага многомерного моделирования в наборе инструментов хранилища данных:
Объемное моделирование в четыре шага
Эти четыре шага взаимосвязаны и связаны шаг за шагом. Ниже подробно описано, как выполнить каждый шаг.
1. Выберите бизнес-процесс
- Многомерное моделирование тесно связано с бизнесом, поэтому его необходимо моделировать на основе бизнеса.Затем выбор бизнес-процесса, как следует из названия, заключается в выборе бизнеса, который нам нужно моделировать во всем бизнес-процессе, в соответствии с потребностями. обеспечивается операция и будущая масштабируемость.и так далее, чтобы выбрать бизнес. Например, в торговом центре весь процесс торгового центра делится на сторону продавца, сторону пользователя и сторону платформы.Операционные требования — это общий объем заказа, количество заказов, статус покупки пользователей и т. д. Когда мы выбираем бизнес-процесс, мы выбираем данные стороны пользователя. Выбор бизнеса очень важен, потому что все последующие шаги основаны на этих бизнес-данных.
2. Декларативная детализация
- Давайте сначала возьмем пример: для пользователя, если у пользователя есть номер удостоверения личности, адрес регистрации домохозяйства, несколько номеров мобильных телефонов и несколько банковских карт, тогда атрибуты детализации, которые совпадают с детализацией пользователя, включают детализацию удостоверения личности. , детализация адреса регистрации домохозяйства и Более точная детализация пользователей включает детализацию номера мобильного телефона и детализации банковской карты.Существует отношение один к одному с той же степенью детализации. Зачем упоминать ту же самую степень детализации, ведь размерное моделирование требует от нас, вта же таблица фактов, должен иметьта же степень детализации, Не смешивайте разные степени детализации в одной таблице фактов и создавайте разные таблицы фактов с данными разной степени детализации. А при выборке данных из заданного бизнес-процесса настоятельно рекомендуется начинать проектирование с упора на атомарную гранулярность, то есть начиная с самой тонкой гранулярности, потому что атомарная гранулярность может выдержать непредсказуемые запросы пользователей. Однако гранулярность сводного агрегирования очень важна для повышения производительности запросов, поэтому для данных с четкими требованиями мы устанавливаем гранулярность сводного агрегирования для требований и устанавливаем атомарную гранулярность для данных с неясными требованиями.
3. Подтвердите размер
- Таблица измерений используется в качестве входа и описательной идентификации бизнес-анализа, поэтому ее также называют «душой» хранилища данных. Как подтвердить, какой атрибут измерения в куче данных?Если столбец является описанием определенного значения, текста или константы, участником ограничения и идентификацией строки, то атрибут часто является атрибутом измерения, а данные сообщают нам в панели инструментов binИмейте четкое представление о степени детализации таблицы фактов, чтобы разделить все возможные измерения., и кЧтобы гарантировать отсутствие повторяющихся данных в таблице измерений, первичный ключ измерения должен быть уникальным.
4. Подтвердите факты
- Таблица фактов используется для измерения, которое в основном представлено количественным значением.Каждая строка в таблице фактов соответствует показателю, а данные в каждой строке представляют собой данные определенного уровня детализации, называемого степенью детализации. Один из основных принципов объемного моделированиязаключается в том, что все показатели в одной таблице фактов должны иметь одинаковую степень детализации. Это гарантирует отсутствие проблем с мерами двойного учета. Иногда бывает невозможно определить, являются ли данные столбца атрибутом факта или атрибутом измерения. ПомнитеНаиболее практичными фактами являются числовые типы и факты аддитивного класса.. Таким образом, вы можете проанализировать, является ли столбец мерой, содержащей несколько значений, и является ли он участником вычисления, и в этом случае столбец часто является фактом.
где детализация очень важна, степень детализации используется для определения того, что представляют строки таблицы фактов.Рекомендуется начинать проектирование с сосредоточения внимания на гранулярных данных на атомарном уровне, поскольку атомарная гранулярность может выдерживать непредсказуемые запросы пользователя, а атомарные данные могут быть свернуты различными возможными способами, в то время как после выбора высокой степени детализации потребность пользователя в детализации не может быть удовлетворена.
Факты лежат в основе всего многомерного моделирования, в которой модель «снежинка» или «звезда» основана на таблице фактов и расширяется с помощью таблицы измерений, связанных с внешним ключом, для создания общей таблицы модели, которая может поддерживать предсказуемые требования запросов, а окончательный запрос также выполняется в таблице фактов.
Многоуровневое хранилище данных в реальном бизнесе
Стратификация хранилища данных должна выполняться в сочетании с бизнесом компании, и обязанности каждого уровня должны быть четко определены.Для обеспечения стабильности уровня данных и защиты от последующих воздействий обычно используется следующая иерархическая структура:
Архитектура уровня данных
Реализация уровня данных
Используйте четыре диаграммы, чтобы проиллюстрировать конкретную реализацию каждого уровня.
- Уровень источника данных ODS
уровень источника данных
Уровень источника данных в основном импортирует все бизнес-данные в платформу больших данных в качестве моментального хранилища бизнес-данных.
- Хранилище данных уровня детализации данных
уровень детализации данных
Каждая строка в таблице фактов соответствует показателю, а данные в каждой строке представляют собой данные определенного уровня детализации, называемого степенью детализации. Один из основных принципов многомерного моделирования заключается в том, чтоВсе показатели в одной таблице фактов должны иметь одинаковую степень детализации.. Это гарантирует отсутствие проблем с мерами двойного учета.
Таблица измерения, как правило, представляет собой один первичный ключ, а некоторые из них являются совместными первичными ключами.Будьте осторожны, чтобы не иметь повторяющихся данных в таблице измерения, иначе появится ассоциация с таблицей фактов.расхождение данныхпроблема.
Иногда бывает невозможно определить, являются ли данные столбца атрибутом факта или атрибутом измерения. ПомнитеНаиболее практичными фактами являются числовые типы и факты аддитивного класса.. Таким образом, вы можете проанализировать, является ли столбец мерой, содержащей несколько значений и является участником расчета, и в этом случае столбец часто является фактом; если столбец является описанием определенного значения, текстом или константой , определенный участник ограничений и идентификации строк, и в этом случае атрибут часто является атрибутом измерения. Тем не менее, все же необходимо объединить бизнес, чтобы вынести окончательное решение, является ли это измерением или фактом.
- DM уровня агрегации света данных
Слой агрегации данных
Этот слой называется слоем легкой агрегации, что означает, что этот уровень начал агрегировать данные, но это не полная агрегация, а только агрегация данных с одинаковой степенью детализации.Также могут агрегироваться данные с разной степенью детализации, но связанные данные. степень детализации унифицируется с помощью таких операций, как агрегация.
- Приложение прикладного уровня данных
Уровень приложения данных
Таблица прикладного уровня данных предоставляется пользователям.Строительство хранилища данных подходит к концу.Затем, в соответствии с различными потребностями, будут извлекаться разные числа, например, для прямого отображения отчета или предоставления коллегам по анализу данных. . данных или другой деловой поддержки.
На картинке показан общий процесс построения хранилища данных.:
Общий процесс хранилища данных
управление данными
Настоящая сложность построения хранилища данных заключается не в дизайне хранилища данных, а в управлении данными после последующего развития бизнеса и огромного направления бизнеса., включая управление активами, мониторинг качества данных, построение системы индикаторов данных и т.д.
На самом деле сфера управления данными очень широка, включая управление самими данными, безопасность данных, качество данных, стоимость данных и т. д. существуетРуководство по своду знаний по управлению данными DAMAУправление данными находится в центре «колесной диаграммы» управления данными. Это общая схема 10 областей управления большими данными, таких как архитектура данных, моделирование данных, хранение данных, безопасность данных, качество данных, управление метаданными и мастер-данные. Управление данными Эта деятельность по управлению данными обеспечивает общую руководящую стратегию.
Что такое управление данными?
1. Управление данными требует построения системы
Чтобы осознать ценность данных, необходимо выполнить три элемента:Разумная архитектура платформы, отличные услуги управления и систематические методы работы.
Выберите подходящую архитектуру платформы в соответствии с масштабом предприятия, отраслью, к которой оно принадлежит, и объемом данных; службы управления должны выполняться на протяжении всего жизненного цикла данных, чтобы гарантировать целостность, точность и согласованность данных на всем протяжении. процесс сбора, обработки, совместного использования, хранения и применения, производительность и эффективность, оперативные средства должны включать стандартную оптимизацию, организационную оптимизацию, оптимизацию платформы и оптимизацию процесса.
2. Для управления данными нужна прочная основа
Управление данными должно быть постепенным, но на ранней стадии построения необходимо уделить внимание по крайней мере трем аспектам:Спецификация данных, качество данных, безопасность данных. Стандартизированное управление моделями является предпосылкой для обеспечения возможности управления данными, высокое качество данных является предпосылкой для доступности данных, а управление и контроль безопасности данных являются предпосылкой для совместного использования и обмена данными.
3. Управление данными требует расширения возможностей ИТ
Управление данными — это не куча нормативных документов, а нормы, процессы и стандарты, созданные в процессе управления, должны быть реализованы на ИТ-платформе, а данные должны обрабатываться перспективным способом «начиная с конца». в процессе производства данных.Управление и предотвращение увеличения различных пассивных и эксплуатационных и эксплуатационных расходов, вызванных аудитами после события.
4. Управление данными должно быть сосредоточено на данных
Суть управления данными заключается в управлении данными, поэтому необходимо усилить управление метаданными и мастер-данными, управлять данными из источника и дополнять соответствующие атрибуты и информацию данных, такие как: метаданные, качество, безопасность, бизнес-логика, кровное родство и т. д. с помощью метаданных Основанный на данных подход к управлению производством, обработкой и использованием данных.
5. Управление данными требует интеграции построения и управления
Согласованность родословной модели данных и планирования задач является ключом к интеграции построения и управления, что помогает решить проблему несогласованных калибров управления данными и производства данных и позволяет избежать неэффективного режима управления двумя оболочками.
Говоря об управлении данными
Как упоминалось выше, объем управления данными очень широк, наиболее важным из них является управление качеством данных, и объем управления качеством данных также очень широк и охватывает весь жизненный цикл хранилища данных, начиная сГенерация данных->доступ к данным->хранение данных->обработка данных->вывод данных->отображение данных, управление качеством требуется на каждом этапе, а параметры оценки включаютЦелостность, нормативность, последовательность, точность, уникальность, релевантностьЖдать.
На всех этапах построения системы должна проводиться проверка и спецификация качества данных в соответствии со стандартами, а управление должно осуществляться вовремя, чтобы избежать последующей очистки.
Проверка качества может относиться к следующим измерениям:
| измерение | Метрики |
|---|---|
| честность | Отсутствуют ли необходимые данные для бизнес-спецификации, нулевые символы или нулевые значения не допускаются. Например, полный ли источник данных, полные ли значения измерений, полные ли значения данных и т. д. |
| Своевременность | Отражают ли данные текущие факты, когда это необходимо. То есть данные должны быть своевременными и соответствовать требованиям системы к времени передачи данных. таких как своевременность обработки (приобретение, сортировка, очистка, погрузка и т.д.) |
| уникальность | Является ли значение данных уникальным в указанном наборе данных |
| ссылочная целостность | Определен ли элемент данных в родительской таблице |
| Согласованность зависимостей | Удовлетворяет ли значение элемента данных зависимостям с другими элементами данных |
| правильность | Соответствуют ли содержание данных и определение |
| точность | Достигает ли точность данных количества цифр, требуемого бизнес-правилами |
| техническая достоверность | Организованы ли элементы данных в соответствии с определенным стандартом формата |
| эффективность бизнеса | Соответствует ли элемент данных определенным |
| достоверность | Получено из опросов клиентов или предложений клиентов |
| Доступность | Соотношение времени, в течение которого данные доступны, и времени, когда данные должны быть доступны |
| доступность | Легко ли данные считываются автоматически? |
Ниже приведены некоторые конкретные методы управления, обобщенные в соответствии с техническими статьями Meituan:
1. Нормативное управление
Спецификации являются гарантией строительства складов. Во избежание повторного построения показателей и низкого качества данных стандартизированное построение осуществляется в соответствии с наиболее детализированными и реализуемыми методами.
(1) корень
Корни являются основой для управления измерениями и индексами и делятся на общие основы и собственные основы для повышения удобства использования и релевантности основ.
- Обыкновенный корень: Наименьшая единица, описывающая вещи, например: транзакция - торговля.
- Собственный корень: имеет обычное или отраслевое описание, например: доллар США-доллар США.
(2) соглашение об именовании таблиц
Общая спецификация
- В именах таблиц и именах полей используется корень, разделенный символом подчеркивания (пример: clienttype->client_type).
- В каждой части используются английские слова нижнего регистра, а те, которые относятся к общим полям, должны соответствовать определению информации общего поля.
- Имена таблиц и полей должны начинаться с буквы.
- Имена таблиц и имена полей не могут содержать более 64 английских символов.
- Отдавайте приоритет использованию существующих ключевых слов в корне (управление корнем в стандартной конфигурации хранилища данных) и регулярно проверяйте нецелесообразность нового именования.
- Использование нестандартных сокращений в пользовательской части имени таблицы запрещено.
соглашение об именовании таблиц
- имя таблицы= тип + бизнес-тема + подтема + значение таблицы + формат хранения + частота обновления + конец, как показано на следующем рисунке:
Единое соглашение об именовании таблиц
(3) Соглашение об именах индикаторов
В сочетании с характеристиками индикаторов и спецификациями корневого управления индикаторы структурированы.
- Базовые корни индикатора, то есть все индикаторы должны содержать следующие базовые корни:
- Бизнес-модификаторы, слова, используемые для описания бизнес-сценариев, таких как торговая сделка.
3. Модификаторы даты используются для изменения временного интервала, в котором происходит бизнес.
4. Агрегируйте модификаторы для агрегирования результатов.
5. Базовый индикатор, один бизнес-модификатор + корень базового индикатора для построения базового индикатора, например: сумма сделки - trade_amt.
6. Производные индикаторы, мультимодификатор + базовый корень индикатора для построения производных индикаторов. Производный индекс наследует характеристики базового индекса, например: количество установленных магазинов - install_poi_cnt.
7. Соглашение об именах общих индикаторов согласуется с соглашением об именах полей, которые могут быть преобразованы с помощью словаря.
2. Управление архитектурой
(1) многоуровневость данных
Отличная и надежная система хранилища данных часто требует четкой многоуровневой структуры данных, то есть для обеспечения стабильности уровня данных и защиты от воздействия на нисходящий поток, а также для предотвращения чрезмерно длинных ссылок.Общая многоуровневая архитектура выглядит следующим образом:
(2) поток данных
Стабильный бизнес развивается в соответствии со стандартным направлением потока данных, а именно ODS-->DWD-->DWA-->APP. Для нестабильных деловых или исследовательских потребностей вы можете следовать двум модельным потокам данных: ODS-> DWD-> APP или ODS-> DWD-> DWT-> APP. После обеспечения рациональности канала передачи данных на этом основании подтверждается принцип послойной привязки модели:
- Обычный поток: ODS>DWD->DWT->DWA->APP Когда появляется отношение ODS>DWD->DWA->APP, это означает, что предметный домен не полностью покрыт. Данные DWD должны попадать в DWT, позволяя использовать DWD->DWA для очень редко используемых таблиц.
- Старайтесь избегать расширенных таблиц DWA, использующих DWD и DWT (домен объекта, к которому принадлежит DWD).
- В принципе, следует максимально избегать таблиц DWT, сгенерированных DWT, в одной и той же предметной области, иначе это повлияет на эффективность ETL.
- Прямое использование таблиц ODS запрещено в DWT, DWA и APP, а на таблицы ODS может ссылаться только DWD.
- Обратные зависимости запрещены, например, таблица DWT зависит от таблицы DWA.
3. Управление метаданными
Метаданные можно разделить на технические метаданные и бизнес-метаданные:
технические метаданныеИспользуется ИТ-персоналом, который разрабатывает и управляет хранилищами данных, он описывает данные, связанные с разработкой, управлением и обслуживанием хранилища данных, включая информацию об источниках данных, описания преобразования данных, модели хранилища данных, правила очистки и обновления данных, сопоставление данных и права доступа. Ждать.
Общие технические метаданные:
- Хранить метаданные: информацию, такую как таблицы, поля, разделы и т. д.
- Запуск метаданных: например, вся информация о выполнении заданий на платформе больших данных: аналогично журналу заданий Hive, включая тип задания, имя экземпляра, ввод и вывод, SQL, параметры выполнения, время выполнения, механизм выполнения и т. д.
- Синхронизация данных, вычислительные задачи, планирование задач и другая информация в платформе разработки данных: включая входные и выходные таблицы и поля для синхронизации данных, а также информацию об узлах самой задачи синхронизации: вычислительные задачи в основном включают в себя ввод и вывод, а также информацию об узлах Планирование задач в основном включает в себя задачи Типы зависимостей, зависимости и т. д., а также журналы выполнения различных типов запланированных задач.
- Качество данных и метаданные, связанные с эксплуатацией и обслуживанием: такие как мониторинг задач, аварийные сигналы эксплуатации и обслуживания, качество данных и сбои, включая журналы операций мониторинга задач, журналы конфигурации аварийных сигналов и операций, а также информацию об ошибках.
метаданные бизнесаОбслуживание руководства и бизнес-аналитиков, описание данных с точки зрения бизнеса, включая бизнес-термины, какие данные находятся в хранилище данных, расположение данных, доступность данных и т. д., чтобы помочь деловым людям лучше понять, какие данные доступны в хранилище данных и как его использовать.
- Общие бизнес-метаданные включают измерения и атрибуты (включая код измерения, тип поля, создатель, время создания, статус и т. д.), бизнес-процесс и индикаторы (включая имя индикатора, код индикатора, бизнес-калибр, тип индикатора, ответственное лицо, время создания ), состояние, sql и т. д.), нормализованные определения уровней безопасности, логики вычислений и т. д. для лучшего управления и использования данных. Метаданные приложений данных, такие как метаданные конфигурации и операций отчетов данных, продуктов данных и т. д.
Метаданные не только определяют схему, источник, правила извлечения и преобразования данных в хранилище данных, но и являются основой для работы всей системы хранилища данных.Метаданные связывают разрозненные компоненты в системе хранилища данных, образуя органическое целое..
Управление метаданными в основном решает три проблемы:
- Благодаря созданию соответствующих организаций, процессов и инструментов будет способствовать внедрению бизнес-стандартов, будет реализовано стандартизированное определение индикаторов и устранена неоднозначность понимания индикаторов;
- Основываясь на статусе бизнеса и будущем развитии, абстрагируйте бизнес-модель, сформулируйте четкие темы, бизнес-процессы и направления анализа, создайте полные технические метаданные, точно и полностью опишите физическую модель и соедините технические метаданные и бизнес-метаданные. Отношения между данными и полное описание физической модели;
- Благодаря построению метаданных мы можем повысить эффективность использования данных и решить проблемы «поиска, понимания и оценки», а также «получения чисел и визуализации данных».
4. Управление безопасностью
Сосредоточив внимание на стандартах безопасности данных, прежде всего, должны быть классификация данных и стандарты классификации, чтобы гарантировать, что данные имеют точный уровень безопасности, прежде чем они будут переданы в сеть. Во-вторых, для пользователей данных должны существовать четкие стандарты авторизации ролей, а посредством классификации и авторизации ролей важные данные не могут быть украдены. В-третьих, для конфиденциальных данных должны существовать стандарты управления конфиденциальностью, чтобы гарантировать безопасное хранение конфиденциальных данных.Даже если неавторизованные пользователи обходят управление полномочиями для получения конфиденциальных данных, они должны гарантировать, что они не смогут их понять. В-четвертых, формулируя стандарты аудита, он обеспечивает основу для последующих аудитов, чтобы гарантировать, что данные не могут ускользнуть.
5. Управление жизненным циклом данных
Все имеет определенный жизненный цикл, и данные не исключение. Должен существовать научный метод управления созданием, обработкой, использованием и даже уничтожением данных.Данные, которые редко или больше не используются, удаляются из системы и сохраняются на проверенных устройствах хранения, что может не только повысить эффективность работы система, лучше обслуживать клиентов и может значительно снизить стоимость хранения, вызванную долгосрочным хранением данных. Жизненный цикл данных обычно включает три этапа: этап онлайн, этап архивирования (иногда далее подразделяемый на этап онлайн-регистрации и этап офлайн-регистрации) и этап уничтожения.Срок хранения, носители данных, правила и методы очистки, меры предосторожности и т. д.
Из отношения между параметрами в жизненном цикле данных, приведенном выше, мы можем видеть, что управление жизненным циклом данных может значительно повысить эффективность запросов к ценным данным, а также можно значительно сократить покупку дорогостоящих носителей данных. использование данных уменьшается, данные постепенно архивируются, а время запроса постепенно увеличивается; наконец, поскольку частота использования и ценность данных в основном исчезают, их можно постепенно уничтожать.
Ссылка на ссылку:
Tickets.WeChat.QQ.com/Yes/Return to 6HN KR oz…
zhuanlan.zhihu.com/p/137454121
Woo Woo.info Q.Can/article/KJ находится в…
blog.CSDN.net/me групповая техника…