Предисловие

Предисловие На этот раз я хочу поговорить о чем-то кроме технологии работы.,DWD Этот уровень упоминался много раз при написании уровня CDM.,Предложение, которое недавно заставило меня осознать это, — это высказывание: «Я лучше совершу ошибку, чем ничего не сделаю».,Если ты сможешь это сделать,,Тогда способность исполнения намного превосходит другие,Способности и видение также будут полностью развиты с опытом. Но для этого также необходимо различать поля.,Вообще говоря, я думаю, что степень применимости этого предложения находится в моей собственной технической сфере деятельности.,Вы можете попробовать другую технологию,Смените тему или начните новую вторую карьеру,Вместо того, чтобы совершать ошибки в нынешних условиях,Потому что сейчас у тебя очень мало возможностей совершать ошибки.,Все равно придется во всем обращать внимание на количество и меру. Ладно, больше никаких глупостей.,Теперь приступим к моделированию данных слоя DWD.

Слой детальных фактов (DWD)

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

моделирование на основе бизнес-процессов：

• Уровень DWD берет за основу конкретные бизнес-процессы.,Анализируя характеристики и потребности бизнес-процессов,Постройте максимально подробную детализированную таблицу фактов. Этот метод моделирования может лучше отражать поток данных и изменения в реальном бизнесе.

Широкая обработка таблиц：

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

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

Основные этапы типичного торгового процесса включают в себя:

1. Объявление о тендере опубликовано：Предприятия публикуют объявления о тендерах,Пригласите поставщиков принять участие в торгах.
2. Подача тендерной документации：Поставщики подают тендерную документацию в соответствии с требованиями объявления.。
3. оценка предложения：Тендерная документация по оценке предприятия,Выберите подходящего поставщика.
4. подписание контракта：и Победа в тендере Поставщик подписывает договор。

1. Пример моделирования на основе бизнес-процесса

Дизайн таблицы фактов：

• детализация：Отдельные записи для каждой ставки
• Размеры:
  • измерение времени：Момент времени, в который фиксируется ставка（Дата подачи、Дата оценки предложения、дата подписания контракта）
  • размер поставщика：женьшеньинежныйизпоставщикинформация（Идентификатор поставщика、Имя поставщика）
  • Размеры проекта：Вовлеченныйпроектинформация（Идентификатор проекта、Название проекта）
  • измерение статуса：Статус ставка(отправлено、оценка предложениясередина、Победа в тендере、еще нет Победа в тендере）

структура таблицы фактов：

мера：

• Сумма ставки：Может обобщить статистику каждогопроектобщего количества Сумма ставка, Сумма от каждого поставщика ставкиждать。

2. Обработка широкой таблицы

Пример обработки широкой таблицы

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

Широкая обработка таблицпозжеструктура таблицы фактов：

• Название проектаиИмя поставщикаждать Резервное хранение важных атрибутовсуществоватьфактповерхностьсередина,чтобы ускорить запрос. Например,При запросе записей торгов конкретного поставщика по проекту,Нет необходимости в связанных запросахпроектиразмер поставщикаповерхность。

3. Проектирование таблицы фактов

3.1 Определение степени детализации

• Детализация представляет собой степень детализации бизнеса, выраженную записью в таблице фактов. Выбор правильной детализации является ключом к разработке таблицы фактов, и ее обычно можно определить следующими двумя способами:
  • Комбинация атрибутов измерения：за счет комбинации многомерных атрибутовопределениедетализация。
  • Конкретное деловое значение：Непосредственно на основе бизнес-процессовизнуждаться Приходитьопределениедетализация。

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

• Идентификатор проекта：определить, какойпроекттолькосуществовать Нежный。
• Идентификатор поставщика：определить, какойпоставщик提交了нежный。
• Дата тендера：Определите конкретное время подачи заявок。

Такое детальное определение гарантирует, что каждая запись представляет заявку конкретного поставщика на проект.

Конкретное деловое значение

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

3.2 Типы фактов

• Факт аддитивности：Можетсуществовать Собирайте во всех соответствующих измеренияхобщий,Такие как продажи、количествождать。
• Половина Факт аддитивности：может толькосуществовать Обмен в определенных измеренияхобщий,Например, запасы можно суммировать только по аналитике местоположения или продукта.
• Нет Факт аддитивности：Например, данные о соотношении,Агрегация необходима путем разложения на аддитивные компоненты.

В процессе торгов разные данные метрик могут принадлежать разным типам фактов:

• Факт аддитивности：
  • Сумма ставки：Может对Нетто же измерение（например, время、проект、Поставщики) суммируются для определения общей суммы ставок.
• Половина Факт аддитивности：
  • Сумма ставки：Хотя это нормальнопроектиразмер поставщика не обобщать, а измерять Агрегирование (например, по месяцам) не всегда может иметь смысл, поскольку торги могут быть ограничены определенными периодами времени.
• Нет Факт аддитивности：
  • Доля успешных ставок：Например,Процент победителей предложений поставщика по проекту. Эти коэффициенты невозможно рассчитать простым сложением,Вместо этого его необходимо разложить на аддитивные компоненты.,нравитьсяуспехинеудачаиз Количество ставки для расчета.

3.3 Ухудшение размеров

Пример ухудшения размерности

При разработке таблицы фактов некоторая информация об измерениях может храниться непосредственно в таблице фактов в виде вырожденных измерений, чтобы повысить эффективность запросов. Например:

• Название проекта：и Идентификатор проекта хранятся вместе в таблице фактов для быстрого выполнения запросов без необходимости обращаться к размерам. проектаповерхность。
• Имя поставщика：и Идентификатор поставщика хранятся вместе.

Вырожденная размерная структура таблицы фактов：

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

Сценарии применения

• 快速获取某个поставщиксуществоватьвсепроектсерединаиз Сумма ставки。
• Подсчитайте все данные за определенный период временипроектобщего количества Сумма ставкии Победа в тендере Ставка。
• анализировать Неттакой жепроектконкурентная ситуация,проходить Количество Ставки и суммы для оценки популярности на рынке。

4.Слой детальных фактов (DWD)тип

В тендерном бизнесе мы можем определить Слой в соответствии с различными потребностями бизнеса. детальных фактов (DWD) тип для удовлетворения требований анализа Различные требования к данным.

4.1. Таблица фактов транзакций.

определение：

• Таблица фактов транзакций используется для описания элементарных событий в бизнес-процессе торгов и записи подробной информации о каждом действии торгов.

Пример：

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

Сценарии применения：

• Анализируйте поведение каждого поставщика на торгах, например, все записи предложений определенного поставщика за прошедший период.
• Рассчитайте каждыйпроектизобщая сумма ставкии Количество ставок。

4.2. Таблица фактов периодического снимка.

определение：

• В таблице фактов периодических кадров фиксируется состояние торгового бизнеса в течение фиксированного интервала времени. Например,每月记录一次всетолькосуществоватьруководитьиз Нежныйпроектизсостояние。

Пример：

в тендерном бизнесе,Статус ставок и суммы по всем предметам можно записывать ежемесячно,контролироватьпроектпрогресси Динамика рынка。поверхность Структура может включать в себя：

Сценарии применения：

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

4.3. Таблица фактов совокупного снимка.

определение：

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

Пример：

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

Сценарии применения：

• Отслеживайте жизненный цикл каждого тендерного проекта, выявляя критические этапы и узкие места.
• Статистика о среднем времени, которое занимает проект от начала до завершения, для оптимизации процесса торгов.

Общий процесс разработки подробной таблицы фактов детализации показан на рисунке ниже:

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

5. Принципы построения подробных таблиц фактов детализации

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

5.1 Детализированная таблица фактов связана только с одним измерением

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

Применение в тендерном бизнесе：Например,ставкатаблица фактов транзакций Может仅иРазмеры проектаассоциация,Поскольку каждая запись о ставках посвящена конкретномупроект Расширять。другие размеры（Например, поставщик、время) как вспомогательное измерение.

5.2 Включите как можно больше всех фактов, имеющих отношение к бизнес-процессу.

понимать：фактповерхность Бизнес-процесс должен быть отражен максимально полносерединаизвсе重要数据,Для поддержки разнообразных потребностей анализа.

Применение в тендерном бизнесе：нежныйтаблица фактов транзакций должны включать все меры, относящиеся к предложению, например сумму ставки、Количество ставок、Статус ставки и т. д. для всестороннего анализа.

5.3 Выбирайте только факты, имеющие отношение к бизнес-процессу

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

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

5.4. Разложение фактов неаддитивности на аддитивные компоненты.

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

Применение в тендерном бизнесе：ВоляДоля успешных ставокавариядляуспех Количество ставокиобщий Количество ставок,这样Можетпроходитьэти двое Факт аддитивность рассчитывает вероятность успеха.

5.5 Детализация должна быть заявлена ​​перед выбором измерений и фактов.

понимать：明确фактповерхностьиздетализациядля обеспечения данныхизуникальностьичестность,Не допускайте смешивания различных фактов детализации.

Применение в тендерном бизнесе：существоватьсоздаватьнежныйтаблица фактов транзакций До,Заявить о своей детализации как «единая заявка от поставщика для каждого проекта».,Убедитесь, что уровень детализации, записанный в таблице, соответствует.

5.6 В одной таблице фактов не может быть несколько фактов разной степени детализации.

понимать：保持фактповерхностьиздетализацияпоследовательный,во избежание путаницы данных и ошибок анализа.

Применение в тендерном бизнесе：убеждатьсянежныйтаблица фактов транзакцийсерединавсе记录издетализацияпоследовательный,Например, каждая запись представляет собой определенное событие торгов.,а не несколько записей, представляющих одну ставку,некоторые поколенияповерхностьпроектобщий。

5.7 Единицы фактов должны быть последовательными

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

Применение в тендерном бизнесе：убеждатьсявсеи Сумма, связаннаяизмера（нравиться Сумма ставка, сумма бюджета) используют одну и ту же денежную единицу.

5.8 Обращайтесь с нулевыми значениями с осторожностью

понимать：иметь дело сNullНужно быть осторожным при оценке,чтобы избежать проблем при расчете и анализе данных.

Применение в тендерном бизнесе：существоватьнежныйтаблица фактов В транзакциях для полей, где могут появляться значения Null (например, Дата оценки предложения）,Может обрабатываться с использованием значений по умолчанию или аннотаций.,обеспечить точность результатов анализа.

5.9. Используйте вырожденные измерения для повышения удобства использования таблиц фактов.

понимать：Вырожденные размеры сохраняются напрямуюсуществоватьфактповерхностьсерединаиз Размерыинформация,Может ускорить запросы и упростить модели данных.

Применение в тендерном бизнесе：ВоляНазвание проектаиИмя поставщикаделатьдля退化Размеры存储существоватьнежныйтаблица фактов транзакцийсередина,Это устраняет необходимость часто связывать таблицы измерений во время запросов.,Повышение эффективности запросов.

Следуя этим принципам проектирования, можно создать эффективную и простую в использовании детальную таблицу фактов в тендерном бизнесе, что поможет компаниям лучше анализировать и оптимизировать свою тендерную деятельность.

6.Правила именования таблиц DWD

Например: dwd_asale_trd_ordcrt_trip_di (таблица фактов заказа авиабилетов компании электронной коммерции, ежедневное обновление) и dwd_asale_itm_item_df (таблица фактов снимка продукта электронной коммерции, полная сумма ежедневного обновления).

• Таблица фактов информации об элементе транзакции: dwd_asale_trd_itm_di.
• Таблица фактов с информацией об участниках торгов: dwd_asale_trd_mbr_di.
• Таблица фактов информации о заказе транзакции: dwd_asale_trd_ord_di.

7. Разработка таблицы фактов для транзакции подачи заказа в сфере торгов.

7.1 Определите степень детализации

• Детализация: каждая запись представляет событие отправки заказа.
  • Каждый заказ состоит из одной заявки от конкретного поставщика на конкретный товар.

7.2 Ключевые параметры

• измерение времени: подача заказа на захват、обзор、Время одобрения.
• размер поставщика: Описывает информацию о поставщике, представленную для заказа.
• Размеры проекта：Зафиксировать право собственности на заказизпроект。
• Размеры продукта: Содержит информацию о продукте, включенном в заказ.
• измерение последствий: отслеживание статуса заказа в процессе (например, отправленный、ужеобзор、одобрено и т. д.)

7.3 Факты

• Сумма заказа: Общая сумма заказа.
• Количество продукт: Количество разработано для того, чтобы продукта。
• Сумма скидки: любая применимая сумма скидки。
• налоги: налоги, участвующие в заказе.
• Статус заказ: Текущий статус заказа.

7.4 Вырожденное измерение

• Идентификатор заказа: используется для уникальной идентификации каждого заказа.
• Имя Поставщик: Удобен для быстрого запроса без ассоциации размера. поставщикаповерхность。
• Название проект: Удобен для быстрого запроса без привязки. проектаповерхность。

7.5 Структура таблицы фактов транзакций

Детали дизайна:

7.5.1 Гранулированная консистенция:

• Каждая запись представляет только определенное событие отправки заказа, что обеспечивает единообразие детализации.

7.5.2 Полнота данных

• Содержит всю необходимую информацию, связанную с процессом подачи заказа (например, сумму、количество、Скидкаждать）,для поддержки комплексного бизнес-анализа.

7.5.3 Вырожденное измерение

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

7.5.4 Обработка значений NULL

• Убедитесь, что поле даты (например, Дата рассмотрения、Дата заявление) может корректно обрабатывать значения Null для незавершенных шагов и предотвращать анализ, устанавливая значения по умолчанию или комментарии. данныхошибка。

7.5.5 Согласованность единиц фактов

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

7.6 Сценарии применения

• Анализ эффективности подачи заказов:
  • Анализируя материалы, отзывы и дату положения, оценить эффективность обработки заказов и узкие места.
• Оценка работы поставщика:
  • Статистика объемов подачи заказов и успешности различных поставщиков помогает выбирать качественных поставщиков.
• Управление стоимостью проекта:
  • Анализ суммы для каждого проекта заказаиколичество,мониторпроект Бюджети Расходы。

7.7 Оператор создания таблицы SQL

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

7.7.1 Оператор создания таблицы SQL

Таблица фактов транзакции подачи заказа:

CREATE TABLE order_submission_facts (
    order_id INT PRIMARY KEY,
    project_id INT,
    project_name VARCHAR(255),
    supplier_id INT,
    supplier_name VARCHAR(255),
    submission_date DATE,
    review_date DATE,
    approval_date DATE,
    order_amount DECIMAL(18, 2),
    product_quantity INT,
    discount_amount DECIMAL(18, 2),
    tax_amount DECIMAL(18, 2),
    order_status VARCHAR(50),
    FOREIGN KEY (project_id) REFERENCES projects(project_id),
    FOREIGN KEY (supplier_id) REFERENCES suppliers(supplier_id)
);
​

7.7.2 Направление потока данных

Описание потока данных

1. Источник данных:

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

2. Процесс ETL:

• Извлечение: Извлечение данных, связанных с заказом, проектом и поставщиком, из исходной системы.
• Преобразование:
  • Стандартизируйте форматы данных, данные, связанные с проектами и поставщиками.
  • Рассчитать необходимую меру,Такие как скидки и налоги.
• нагрузка:
  • Загрузка очищенных и преобразованных данных в хранилище Таблица транзакций отправки заказов данных.

Схема потока данных

[Бизнес-система] --> [Инструменты ETL] --> [хранилище данных: order_submission_facts]

7.7.3 Загрузка первого дня

Загрузка в первый день означает первую загрузку исторических данных в хранилище данных.

insert overwrite table dwd_order_submission_facts partition (dt)(
    order_id,project_id,project_name,supplier_id,supplier_name,
    submission_date,review_date,approval_date,order_amount,
    product_quantity,discount_amount,tax_amount,order_status
)
SELECT
    o.order_id,
    o.project_id,
    p.project_name,
    o.supplier_id,
    s.supplier_name,
    o.submission_date,
    o.review_date,
    o.approval_date,
    o.order_amount,
    o.product_quantity,
    o.discount_amount,
    o.tax_amount,
    o.order_status
FROM
    source_order o
JOIN
    source_projects p ON o.project_id = p.project_id
JOIN
    source_suppliers s ON o.supplier_id = s.supplier_id
WHERE
    o.submission_date <= CURDATE();

7.7.4 Ежедневная загрузка

Ежедневная загрузка означает периодическую (обычно ежедневную) дополнительную загрузку новых данных.

insert overwrite table dwd_order_submission_facts partition (dt)(
    order_id,project_id,project_name,supplier_id,supplier_name,
    submission_date,review_date,approval_date,order_amount,
    product_quantity,discount_amount,tax_amount,order_status
)
SELECT
    o.order_id,
    o.project_id,
    p.project_name,
    o.supplier_id,
    s.supplier_name,
    o.submission_date,
    o.review_date,
    o.approval_date,
    o.order_amount,
    o.product_quantity,
    o.discount_amount,
    o.tax_amount,
    o.order_status
FROM
    source_order o
JOIN
    source_projects p ON o.project_id = p.project_id
JOIN
    source_suppliers s ON o.supplier_id = s.supplier_id
WHERE
    o.submission_date = CURDATE();

На этом этапе мы завершили построение таблицы DWD и так далее, чтобы построить все таблицы фактов слоя DWD.