Многоуровневое хранение данных DWD, DWB, DWS [просто для понимания]
Многоуровневое хранение данных DWD, DWB, DWS [просто для понимания]

Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

DW :data warehouse переведено наданныесклад DWМногоуровневое хранение данные, снизу вверх DWD,DWB,DWS DWD:data warehouse detail Уровень детальных данных, иногда также называемый Уровень ODS — это уровень изоляции между бизнес-уровнем и хранилищем данных. DWB:data warehouse base Базовый уровень данных хранит объективные данные и обычно используется в качестве промежуточного уровня. Его можно рассматривать как уровень данных для большого количества показателей. DWS:data warehouse service Уровень служебных данных, основанный на базовых данных DWB, интегрируется и суммируется в служебные данные для анализа определенной предметной области, обычно в виде широкой таблицы.

Нулевой уровень загрузки данных: ETL (Извлечение-Преобразование-Загрузка) 1. Уровень операций с данными: ODS (хранилище операционных данных). 2. Уровень хранилища данных: DW (Хранилище данных).

  1. Уровень детализации данных: DWD (данные Warehouse Detail)
  2. Средний уровень данных: DWM (данные WareHouse Middle)
  3. Уровень службы данных: DWS (данные WareHouse Servce) 3. Прикладной уровень данных: APP (приложение). 4. Размерный поверхностный слой: (Размер)

Многоуровневое хранение данных

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

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

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

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

0x02 Универсальное Многоуровневое хранение данныхдизайн Для удовлетворения вышеупомянутого Многоуровневого хранение Преимущества, которые приносят данные, мы делим модель данных на три уровня: уровень операций с данными ( ODS ), уровень хранилища данных (DW) и уровень приложений данных (APP). Как показано ниже. Проще говоря, мы можем понимать это так: ** Уровень ODS хранит исходные данные, к которым осуществляется доступ, уровень DW хранит данные среднего уровня хранилища данных, на разработке которых мы хотим сосредоточиться, а APP — это данные приложения, адаптированные для бизнеса. **Конструкция этих трех слоев подробно описана ниже.

1. Уровень операций с данными: ODS (хранилище операционных данных).

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

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

2. Уровень хранилища данных: DW (Хранилище данных).

Уровень хранилища данных является основным уровнем проектирования при создании хранилища данных. Здесь данные, полученные из уровня ODS, создают различные модели данных в соответствии с темами. Уровень DW далее подразделяется на уровень DWD (детали хранилища данных), уровень DWM (средний уровень хранилища данных) и уровень DWS (служба хранилища данных).

1. Уровень детализации данных: DWD (детализация хранилища данных).

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

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

2. Средний уровень данных: DWM (средний уровень хранилища данных).

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

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

3. Уровень службы данных: DWS (Служба хранилища данных).

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

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

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

3. Прикладной уровень данных: APP (приложение).

Здесь данные в основном предоставляются для продуктов данных и анализа данных. Обычно они хранятся в ES, PostgreSql, Redis и других системах для использования онлайн-системами. Они также могут храниться в Hive или Druid для анализа и интеллектуального анализа данных. Например, сюда обычно помещаются данные отчета, о которых мы часто говорим.

4. Размер

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

0x03 Дать каштан

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

1. На уровне ODS из-за различных команд разработчиков на каждом конце или различных других проблем журналы доступа пользователя делятся на несколько таблиц и передаются на наш уровень ODS. 2. Чтобы облегчить всем использование, мы создали таблицу поведения доступа пользователей на уровне DWD. Здесь мы собрали веб-страницы ПК, H5, небольшие программы и собственные журналы доступа приложений в одну таблицу, а также унифицировали имена полей. Улучшите качество данных, чтобы у вас была подробная таблица, которой каждый мог бы легко пользоваться. 3. На уровне DWM мы выберем основные измерения бизнес-задачи из уровня DWD для операций агрегирования, таких как сохранение только измерений людей, продуктов, оборудования и областей страниц. Аналогичным образом мы сделали это для создания множества промежуточных таблиц DWM. 4. Затем на уровне DWS мы помещаем данные о поведении людей по всему веб-сайту в таблицу. Это наша общая таблица. С помощью этой таблицы мы можем быстро удовлетворить большинство общих потребностей бизнеса. 5. Наконец, на уровне приложения APP данные могут быть извлечены из одной или нескольких таблиц на уровне DWS и объединены в таблицу приложения в соответствии с требованиями.

Примечание. Этот пример призван кратко проиллюстрировать роль каждого слоя. Это не самое разумное решение. Вы можете просто посмотреть на него диалектически.

0x04 Техническая практика

Теперь, когда мы говорим о Многоуровневом хранение данных,Итак, какие вычислительные механизмы и системы хранения будут использоваться на разных уровнях?,Давайте кратко поделимся этим в этом разделе.

Хранение уровня данных обычно выглядит следующим образом:

  1. Data Источник: источниками данных обычно являются бизнес-библиотеки и пункты захоронения. Конечно, существуют также различные методы получения данных, такие как покупка данных третьими лицами. Хранилищем бизнес-библиотеки обычно является Mysql. и PostgreSql。
  2. ODS Слой:ОДС Объем данных, как правило, очень велик, поэтому большинство компаний предпочитают хранить их на HDFS, то есть Hive и Hbase, чаще всего Hive. DW Слой: Общий и
  3. ODS Хранилище является последовательным, но для удовлетворения большего количества потребностей также будет хранилище в PG и ES ситуация в. APP Уровень: данные уровня приложения обычно требуют более высокой скорости отклика, поэтому их обычно размещают MySQL, PG, Redis.
  4. слова вычислительной машины,Вы можете просто обратиться к тому, что указано на картинке. В настоящее время технические обновления, связанные с большими данными, происходят относительно быстро.,Перечисленные в этом разделе предназначены только для справки.

0x05 Мышление

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

Лично я понимаю разделение многоуровневого хранения данных с такой точки зрения:

Что касается поддержки приложений, мы надеемся, что чем выше уровень, тем более дружелюбной она будет для приложений. Например, уровень APP в основном предназначен для приложений и его очень легко понять. Для уровня DWS, условно говоря, потребуется небольшая стоимость понимания. Тогда уровни DWM и DWD сложнее понять, потому что их размеры могут быть разными. Их относительно много, и для выполнения одного требования может потребоваться несколько таблиц и очень сложные вычисления.

Что касается объема возможностей, мы надеемся, что 80% требований будут поддерживаться 20% таблиц. Проще говоря, большинство (более 80%) требований могут быть поддержаны таблицами DWS. Для тех, которые не могут быть поддержаны DWS, можно использовать таблицы DWM и DWD. Очень небольшая часть данных, которые не могут быть поддержаны. их необходимо получить из Получено из исходного журнала. В сочетании с первым пунктом мы хотим поддерживать 80% требований таким образом, чтобы это было удобно для приложения, вместо того, чтобы напрямую предоставлять исходные журналы стороне приложения.

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

Сводка по 0xFF

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

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

Некоторые друзья спрашивали непрофессионалов, какие инструменты они используют для ведения блогов. Вот мой ответ: Текущие инструменты для ведения блогов — это Typora (редактирование текста Markdown) + Draw.io (рисование) + Github (хранилище) + Hexo (развертывание блога в Tencent Cloud). Иногда Xmind будет использоваться для рисования интеллект-карт, а Excel — для обработки табличных данных.

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/153201.html Исходная ссылка: https://javaforall.cn

boy illustration
Неразрушающее увеличение изображений одним щелчком мыши, чтобы сделать их более четкими артефактами искусственного интеллекта, включая руководства по установке и использованию.
boy illustration
Копикодер: этот инструмент отлично работает с Cursor, Bolt и V0! Предоставьте более качественные подсказки для разработки интерфейса (создание навигационного веб-сайта с использованием искусственного интеллекта).
boy illustration
Новый бесплатный RooCline превосходит Cline v3.1? ! Быстрее, умнее и лучше вилка Cline! (Независимое программирование AI, порог 0)
boy illustration
Разработав более 10 проектов с помощью Cursor, я собрал 10 примеров и 60 подсказок.
boy illustration
Я потратил 72 часа на изучение курсорных агентов, и вот неоспоримые факты, которыми я должен поделиться!
boy illustration
Идеальная интеграция Cursor и DeepSeek API
boy illustration
DeepSeek V3 снижает затраты на обучение больших моделей
boy illustration
Артефакт, увеличивающий количество очков: на основе улучшения характеристик препятствия малым целям Yolov8 (SEAM, MultiSEAM).
boy illustration
DeepSeek V3 раскручивался уже три дня. Сегодня я попробовал самопровозглашенную модель «ChatGPT».
boy illustration
Open Devin — инженер-программист искусственного интеллекта с открытым исходным кодом, который меньше программирует и больше создает.
boy illustration
Эксклюзивное оригинальное улучшение YOLOv8: собственная разработка SPPF | SPPF сочетается с воспринимаемой большой сверткой ядра UniRepLK, а свертка с большим ядром + без расширения улучшает восприимчивое поле
boy illustration
Популярное и подробное объяснение DeepSeek-V3: от его появления до преимуществ и сравнения с GPT-4o.
boy illustration
9 основных словесных инструкций по доработке академических работ с помощью ChatGPT, эффективных и практичных, которые стоит собрать
boy illustration
Вызовите deepseek в vscode для реализации программирования с помощью искусственного интеллекта.
boy illustration
Познакомьтесь с принципами сверточных нейронных сетей (CNN) в одной статье (суперподробно)
boy illustration
50,3 тыс. звезд! Immich: автономное решение для резервного копирования фотографий и видео, которое экономит деньги и избавляет от беспокойства.
boy illustration
Cloud Native|Практика: установка Dashbaord для K8s, графика неплохая
boy illustration
Краткий обзор статьи — использование синтетических данных при обучении больших моделей и оптимизации производительности
boy illustration
MiniPerplx: новая поисковая система искусственного интеллекта с открытым исходным кодом, спонсируемая xAI и Vercel.
boy illustration
Конструкция сервиса Synology Drive сочетает проникновение в интрасеть и синхронизацию папок заметок Obsidian в облаке.
boy illustration
Центр конфигурации————Накос
boy illustration
Начинаем с нуля при разработке в облаке Copilot: начать разработку с минимальным использованием кода стало проще
boy illustration
[Серия Docker] Docker создает мультиплатформенные образы: практика архитектуры Arm64
boy illustration
Обновление новых возможностей coze | Я использовал coze для создания апплета помощника по исправлению домашних заданий по математике
boy illustration
Советы по развертыванию Nginx: практическое создание статических веб-сайтов на облачных серверах
boy illustration
Feiniu fnos использует Docker для развертывания личного блокнота Notepad
boy illustration
Сверточная нейронная сеть VGG реализует классификацию изображений Cifar10 — практический опыт Pytorch
boy illustration
Начало работы с EdgeonePages — новым недорогим решением для хостинга веб-сайтов
boy illustration
[Зона легкого облачного игрового сервера] Управление игровыми архивами
boy illustration
Развертывание SpringCloud-проекта на базе Docker и Docker-Compose