Что такое склад
Буквально хранилище данных — это хранилище для хранения данных, в нем хранятся различные данные, и эти данные нужно организовывать и хранить по некоторым структурам и правилам. Здесь мы столкнемся с проблемой, которая также является хранилищем для хранения данных: база данных и хранилище данных — это одно и то же?
База данных против хранилища данных
База данных — это наша обычно используемая реляционная база данных (MySQL, Oracle, PostgreSQL...), но есть и другие нереляционные базы данных, которые в основном хранят бизнес-данные Какие данные содержит хранилище данных? Говоря об их различиях, мы обычно упоминаем OLTP и OLAP.
-
OLTP: онлайн-обработка транзакций, онлайн-обработка транзакций, в основном бизнес-данные, необходимо учитывать высокий параллелизм, учитывать транзакции
-
OLAP: аналитическая обработка в режиме онлайн, аналитическая обработка в режиме онлайн, основное внимание уделяется анализу, который будет генерировать большое количество запросов, как правило, редко связанных с добавлениями, удалениями и изменениями.
Их отличия также будут упомянуты в интервью, и достаточно рассказать о них с нескольких пунктов.
Хранилище данных на самом деле представляет собой систему, а не технологию, а объединяет множество существующих технологий для лучшей организации данных и управления ими. Традиционные хранилища данных в основном основаны на реляционных базах данных, за которыми следуют некоторые распределенные базы данных, такие как Greenplum, и многие компании предоставляют полный набор аппаратных решений. При разработке традиционных хранилищ данных из-за ограниченной производительности оборудования возникает много требований.С падением цен на оборудование, широким использованием облачных серверов и зрелым развитием технологии больших данных многие сценарии хранилищ данных изменились. , некоторые правила не нужно строго соблюдать, так что можно оставить много затрат.
Несколько лет назад хранилище данных было немного загадочным, и это казалось очень высоким.Сейчас, по крайней мере, для интернет-компаний, все знают о хранилище данных, все знают о платформе данных, и каждый может сказать несколько слов. стал популярным. Помните, что если вы считали склады раньше, всегда есть несколько обязательных вопросов на собеседовании:
-
Что такое склад?
-
Каковы характеристики хранилища данных?
-
Что такое ОЛАП? Что такое OLTP? В чем разница?
-
Что такое стол на молнии? Как реализовать застежку-молнию?
-
Сколько способов синхронизации?
-
Зачем делать приращения? Как делать прибавки?
-
Что такое ЭТЛ?
Что касается текущего положения Интернет-хранилища данных, я чувствую, что оно больше ориентировано на бизнес + идеи моделирования. Нелегко изучить это содержание в интервью. Когда я нанял в прошлом году, я просто задал несколько основных вопросов, рассказал о основное содержание работы в прошлом, а также заданные вопросы.Вопросы по SQL, если вы действительно хотите понять моделирование, по-прежнему очень полезно искать эту книгу для справки.
Традиционное хранилище данных и интернет-хранилище данных
За традиционной платформой данных стоит полноценная команда хранилища данных, обслуживающая бизнес-сторону, и бизнес-сторона ждет пассивного способа удовлетворения. Данные среднего и низкого уровня в основном закрыты для деловых сторон, поэтому независимо от того, какой метод моделирования использует модель данных, она может в основном соответствовать планированию архитектуры данных в то время.
Быстрое развитие интернет-бизнеса заставило всех сместить акцент с операций и анализа на усовершенствованные операции на основе данных. Возникает вопрос, как хорошо выполнять усовершенствованные операции. Когда ресурсов недостаточно, пользователи будут кричать и некоторые деловые круги даже закатывают рукава, приходят и участвуют в этапах обработки, обработки и анализа данных.
В настоящее время несколько ролей в конструкции исходной платформы данных (разработка данных, проектирование моделей) могут быть переданы другим непрофессиональным пользователям данных, обучению, консультированию и внедрению, а также написанию некоторых решений и разработок, которые больше подходят для текущего предприятия. приложения данных некоторые продукты данных и т. д.
В платформе данных Интернета, поскольку платформа данных стала бесплатной и открытой, и каждый, кто использует данные, также участвует в построении системы данных, это в основном приведет к проблемам с качеством данных, дублированию данных, растрате хранилища и ресурсов, и диверсификация калибра из-за непрофессионализма., непоследовательного кодирования, проблем с неймингом и т.д. Качество данных постепенно стало особенно важной проблемой.
Архитектура хранилища данных
Теперь, когда дело доходит до хранилищ данных, больше будет подключено к платформе данных или инфраструктуре, которая была интегрирована в построение всей инфраструктуры. Здесь мы не будем говорить о взаимодействии между различными компонентами Hadoop, мы просто поговорим о многоуровневой архитектуре хранилища данных.
Говоря о моделировании хранилища данных, мы должны упомянуть две классические теории:
Моделирование парадигмы
Архитектура хранилища данных Inmon «сверху вниз» (EDW-DM) для концентраторов.
объемное моделирование
Шиноподобная архитектура хранилища данных «снизу вверх» (DM-DW), предложенная Кимбаллом.
Моделирование или многоуровневое хранилище данных на самом деле предназначено для лучшей организации, управления и обслуживания данных.В фактической разработке будут интегрированы два метода.Конечно, есть и другие, такие как модель хранилища данных и модель привязки. Я еще не пользовался, поэтому не скажу.
Пространственное моделирование обычно относится к модели звезды и модели снежинки.Модель звезды очень удобна для анализа OLAP.
Многоуровневое хранилище данных
Просто, просто ODS + DM, синхронизируйте все данные, а затем непосредственно разработайте некоторые отчеты прикладного уровня, это проще всего; когда содержимое уровня DM больше, если вы хотите его повторно использовать, вы будете разделять общедоступный уровень на трехуровневая структура, я недавно прочитал книгу Али «Дорога к большим данным», которая содержит много очень хорошего контента, связанного с хранилищем данных После справки, используемая в настоящее время модель слоев выглядит следующим образом:
В соответствии с этим методом наслоения наше внимание при разработке сосредоточено на уровне dwd, который является уровнем подробных данных.Здесь в основном есть несколько широких таблиц, в которых хранятся подробные данные; когда мы достигнем уровня dws, мы будем агрегировать данные для разных измерений. Теперь, логически говоря, слой dws — это слой рынка, который обычно делится по темам и относится к категории многомерного моделирования; реклама — это частичный прикладной слой, который является выводом различных отчетов.
Словарь индикаторов
Как мы уже говорили ранее, хранилище данных — это система и процесс построения, оно объединяет множество методологий и не является новой технологией. Здесь мы говорим о системе индикаторов в хранилищах данных. Индикаторы не уникальны для хранилищ данных или платформ данных. Многие сценарии будут иметь концепцию индикаторов.
Здесь мы говорим о показателях, на самом деле, KPI (ключевой показатель производительности), ключевые показатели эффективности.
Ключевой показатель эффективности предприятия (KPI: Key Performance Indicator) — это целевой количественный показатель управления для измерения эффективности процесса путем установки, выборки, расчета и анализа ключевых параметров входа и выхода внутреннего процесса организации. разложение стратегических целей на практические рабочие цели является основой управления эффективностью предприятия. KPI позволяют руководителям отделов определить основные обязанности отдела и на основе этого определить показатели эффективности персонала отдела.
Роль платформы данных заключается в поддержке анализа и принятия решений, а также в наблюдении за работой предприятия. Итак, как мы смотрим на работу компании? Просто посмотрите на KPI.На уровне компании есть KPI, которые больше всего беспокоят компанию, такие как: дневная активность, GMV, объем заказов и т. д. Мы можем исследовать производительность отдела по KPI, то есть, представление. Это тоже цифровая трансформация, все управление и производительность оцифрованы.
Что касается платформы данных, индикаторы представляют собой своего рода метаданные, и существуют процедуры для обслуживания индикаторов и управления ими.Ниже приводится краткое введение в управление индикаторами - словарь индикаторов.
Словарь индикаторов
Словарь индикаторов на самом деле является управлением индикаторами.После того, как появится больше индикаторов, чтобы делиться ими, единообразно изменять и поддерживать, мы будем поддерживать все индикаторы в Excel. Конечно, Excel не очень удобен для обмена и контроля версий, если позволяют условия, можно разработать простую систему управления индексами, а при кровном родстве удобнее отслеживать поток данных.
Кодировка индикатора
Для облегчения поиска и управления определим набор кодов для индикаторов
Тип индикатора
Базовые индикаторы: индикаторы, которые не подлежат дальнейшей разборке, индикаторы, которые можно рассчитать напрямую, такие как «количество ордеров», «объем сделки». Производные индикаторы: индикаторы, рассчитываемые через специальное измерение на основе базовых индикаторов, таких как Заказы WeChat», «Количество заказов Alipay». Показатели расчета: показатели, рассчитываемые на основе нескольких основных показателей, показатели, которые нельзя разобрать с точки зрения бизнеса, например, «коэффициент распроданности», «коэффициент выкупа».
Деловой калибр
Самое главное для индикатора - уточнить статистический калибр индикатора, то есть как рассчитывается индикатор, если калибр унифицирован, не будет двусмысленности.
Шаблон индикатора
Помимо пунктов, о которых мы говорили выше, есть еще несколько базовых, таких как «название индикатора» и формула расчета, которые формируют шаблон индикатора.
В прошлом у нас остался ответственный отдел, то есть какой отдел отвечает за ведение этого показателя, а какой отдел обращает внимание и берет на себя этот KPI. Что касается показателей, то они неотделимы от измерений, об истории измерений мы поговорим позже.
Сортировка и управление метриками
Разобраться в показателях в начале очень хлопотно, т.к. для унификации калибра надо общаться и согласовывать с разными ведомствами, могут быть разные показатели, и надо судить, нужен ли этот показатель на самом деле и нужен ли его можно заменить другими показателями, взаимосвязь между показателями и показателями также нуждается в уточнении.
Более того, после того, как с первой версией индикаторов разобрались, ее нужно продвигать и поддерживать, причем итеративно и постоянно продвигать, чтобы все отделы компании могли сосредоточиться на проблеме с единой точки зрения.
Наиболее важным параметром является параметр даты.
Измерение даты является нашим наиболее часто используемым измерением. В начале платформы первой инициализацией может быть измерение даты. Здесь мы кратко представим измерение даты.
Что такое размер даты
В нашей повседневной жизни генерация данных связана с датой, данные генерируются каждую минуту и секунду, анализ данных также неотделим от даты.
Измерение даты — это фиксированный календарь, 365 дней в году, каждый день мы открываем календарь в компьютере:
Мы можем закрепить некоторые из них, такие как день недели, лунный календарь, год, месяц, число и праздники, мы все можем закрепить их и использовать при анализе.
Структура измерения даты
Измерение даты может содержать как можно больше сведений о дате, чтобы его можно было использовать непосредственно во время анализа, а также его следует сочетать с некоторыми особыми обстоятельствами компании, такими как некоторые специальные форматы отображения даты.
- Базовый год Квартал Месяц Воскресенье Информация
- Расширенная информация
В дополнение к основным датам, указанным выше, есть также некоторая расширенная информация, которая обычно используется.
Также может быть некоторая информация о лунном календаре, лунном году и т. д., дата начала, дата окончания и т. д. пользовательской недели компании, и все содержимое, связанное с датой, может быть добавлено для обслуживания.
- инициализация измерения
Для инициализации данных мы можем использовать Java, Python или SQL. Обычно используемые функции даты могут в основном удовлетворить наши требования к данным. Для инициализации SQL нам нужно использовать оператор управления циклом, такой как MySQL и PG. Для Hive нам нужно комбинируйте Shell или Python для использования.
Как правило, нет необходимости инициализировать данные за слишком много лет, если охвачены бизнес-данные компании, а информацию о праздниках необходимо поддерживать каждый год в сочетании с информацией, публикуемой Государственным советом.
- О часах
Обычно мы также анализируем почасовые данные, как правило, мы не помещаем их в таблицу дат, а помещаем в отдельную таблицу почасовых измерений, которые при необходимости можно использовать вместе.
Соглашения об именах
Другими словами, правил нет. При построении платформы данных внутри группы данных мы должны сначала сформулировать различные спецификации, чем раньше, тем лучше, и постоянно следить за тем, чтобы все выполняли соглашение. Как только вы позволите всем играть свободно, если вы захотите позже унифицировать или провести рефакторинг, это повлечет за собой много трудозатрат и временных затрат.
Вот некоторые из моего текущего опыта компании, чтобы поделиться.
О проекте
Традиционно построение хранилищ данных разрабатывается по иерархической модели хранилищ данных. Некоторые из них также будут разделены на слои в соответствии с бизнес-направлениями, перераспределены по соответствующим бизнес-направлениям и разработаны отдельно. Здесь я использую MaxCompute от Alibaba Cloud, платформу данных, предоставленную Alibaba.Это полная среда разработки, которая очень удобна в использовании и избавляет вас от необходимости создавать собственную платформу. В MaxCompute есть проектная концепция, изначально планировалось создавать проекты непосредственно на основе дизайна многоуровневой модели, но по какой-то причине она была изменена на создание проектов на основе бизнес-направлений. Над названием этого проекта надо хорошенько подумать.Неважно, на чем основан дизайн, нужно мыслить ясно и понимать.Однажды заданное, оно уже не будет изменено снова, и нет никакой возможности изменить его.
О корне
Забыл, называется ли он "root", сначала написал, а потом нашел в книге для подтверждения. Корень слова относится к спецификации построения хранилища данных и относится к категории управления метаданными. О, теперь все это классифицируется как часть управления данными.
Обычно создание полного хранилища данных включает в себя управление данными, но теперь, когда речь идет о хранилищах данных, речь идет больше о моделировании данных, а когда речь идет об управлении данными, речь идет больше о спецификации данных и управлении данными.
Затем мы говорим о нашем главном герое - корень.
Когда мы изучаем английский язык, мы должны знать корень слова. Это самое тонкое и простое слово. Мы в основном используем его для стандартизации отношений отображения между китайским и английским языками. Часть бизнеса нашей компании связана с полками.Английское название: стеллаж, стеллаж является корнем слова, затем мы называем его стеллажом во всех местах, где используются таблицы и поля, и никак иначе. Это роль корня, который используется для унификации имен и выражения одного и того же значения. В системе индикаторов есть много "рейтовых" индикаторов, которые можно разобрать на ХХХ+рейт, а курс можно назвать курсом, поэтому все наши индикаторы называются ХХХ+рейт. Корни можно использовать для унификации имен таблиц, имен полей, имен предметных доменов и т. д.
Имя таблицы
Имя таблицы должно быть знакомо с именем.По имени таблицы вы можете узнать, какой это бизнес-домен, для чего он используется и какова степень детализации данных.
- обычный стол
Обычная таблица — это таблица, которую нам нужно укрепить, таблица, которая официально используется, и таблица, которую необходимо поддерживать и совершенствовать в течение определенного периода времени. Спецификация: Иерархический префикс [dwd|dws|ads|bi]_бизнес-домен_субъектный домен_XXX_ степень детализации бизнес-домен, предметный домен, мы можем четко перечислить в корне и постоянно улучшать, степень детализации такая же, главное - это временная степень детализации , день, месяц, год, неделя и т. д., используйте корень для определения аббревиатуры.
- Промежуточный стол
Промежуточная таблица обычно появляется в задании и представляет собой таблицу промежуточных данных, временно хранимых в задании. Область действия промежуточной таблицы ограничена процессом выполнения текущего задания. После выполнения задания миссия промежуточной таблицы завершена и может быть удалена (вы можете свободно выбирать в соответствии со сценарием вашей компании. Раньше компания хранила данные промежуточной таблицы в течение нескольких дней для устранения неполадок). Спецификация: mid_table_name_ [0~9|dim] table_name — это имя целевой таблицы в нашей задаче, обычно задача имеет только одну целевую таблицу. Имя стола добавлено сюда, чтобы предотвратить конфликт имен столов во время свободной игры.В конце вы можете выбрать играть свободно и давать какие-то осмысленные имена, или просто и грубо использовать вместо них числа, у каждого есть свои преимущества и недостатки, тщательно выбирайте. Часто встречаются таблицы, которым необходимо заполнить измерения, и здесь мне нравится использовать тусклые окончания.
Когда промежуточная таблица создана, добавьте , если вы хотите сохранить историческую промежуточную таблицу, вы можете добавить дату или временную метку.
drop table if exists table_name;
create table_name as xxx;
- Временные таблицы
Временная таблица — это временная тестовая таблица, таблица, которая временно используется один раз, то есть таблица, временно сохраняющая данные для просмотра, и таблица, которая в дальнейшем вообще больше не используется. удалить в любой момент. Спецификация: tmp_xxx должно начинаться только с tmp, а другие имена необязательны.Обратите внимание, что таблицы, начинающиеся с tmp, не должны использоваться для фактического использования, а только для тестовой проверки.
- таблица размеров
Таблица измерений — это таблица класса абстрактного описания, основанная на базовых данных. Таблицы измерений могут быть автоматически абстрагированы от базовых таблиц или поддерживаться вручную. Спецификация: таблица измерений dim_xxx, которая начинается с dim, за которой следует описание индикатора, которое можно свободно использовать.
- часы ручной работы
Ручная таблица — это таблица, которая поддерживается вручную.После того, как она была инициализирована вручную один раз, она, как правило, не изменяется автоматически, и последующие изменения также поддерживаются вручную. Вообще говоря, степень детализации ручных данных в порядке, поэтому на данный момент мы помещаем их в слой dwd, и если позже появится целевое значение или другие типы ручных данных, они будут распределены по слоям в соответствии с реальной ситуацией. Спецификация: dwd _ бизнес-домен _manual_ xxx ручная таблица, добавление специального поля темы, ручная, указание таблицы ручного обслуживания
показатель
Именование индикаторов также относится к корню слова, чтобы избежать появления одного и того же индикатора 10 человек имеют 10 методов именования.
Конкретная операция основана на фактической ситуации в компании, а спецификация формулируется как можно скорее.
управление данными
Построение универсального хранилища данных включает в себя множество решений, в том числе управление данными, управление данными также проходит через весь проект и является долгосрочной задачей. Сейчас многие понимают хранилище данных просто как моделирование данных.
Управление данными включает в себя множество вещей, которые я раньше не делал, поэтому я нашел некоторую информацию в Интернете, чтобы поделиться.
Зачем нужно управление данными
С увеличением объема данных данные стали активом, нам необходимо лучше управлять этими данными и лучше отражать ценность данных, что требует управления данными. Фактически, при создании платформы данных ряд проблем, с которыми мы столкнулись, можно решить с помощью управления данными:
-
Качество данных становится все хуже и хуже, а обнаружение проблем серьезно отстает
-
Отсутствуют стандарты данных, а стандарты разных ведомств не унифицированы
-
Влияние изменений данных на нисходящий поток неясно, и масштабы воздействия не могут быть подтверждены.
Управление данными — это набор механизмов управления непрерывным улучшением, который обычно включает организацию структуры данных, модель данных, формулировку политики и системы, технические инструменты, стандарты данных, качество данных, анализ воздействия, рабочий процесс, процесс контроля и оценки и так далее.
Проще говоря, существует множество процессов и стандартов, таких как «управление метаданными», «управление основными данными» и «качество данных».
Решайте проблемы, с которыми мы сталкиваемся в процессе использования данных, посредством управления данными.
Вы можете обратиться к этой части:«Управление данными»
О приращении
Многие новички или студенты, которые не прошли ETL, неправильно поняли этот шаг, особенно при общении со студентами, изучающими бизнес-разработки. Их понимание этого шага также предвзято.
Давайте поговорим о том, что они думают о приращении. Они думали, что "инкремент в том, чтобы получить его в соответствии с инкрементом времени, и инкрементная синхронизация, вы можете дать мне данные после инкремента, не всегда синхронизируйте полную сумму". правильно. Да, но это не строго, и он будет делать ошибки. Давайте посмотрим на это шаг за шагом.
1. Что такое инкрементальный
Приращение идет относительно полной суммы, и все они в сценарии "синхронизация данных", например, данные бизнес-системы синхронизируются с хранилищем данных, а данные хранилища данных синхронизируются с бизнесом. system, и используется метод синхронизации.Все они относятся к нашей разработке, и их можно синхронизировать с уровня базы данных, поэтому мы не будем их здесь приводить.
Полная синхронизация, то есть для синхронизации всех данных, 100 записей будут синхронизированы 100 записей, 10 000 записей будут синхронизированы 10 000 записей и 100 миллионов записей будут синхронизированы 100 миллионов записей, Вы также должны найти проблемы в этом методе. Когда объем данных невелик, полная синхронизация проста, удобна и проста в выполнении.Однако, когда объем данных велик, особенно когда исторические данные не меняются часто, полная синхронизация будет тратить много ресурсов и времени, серьезно влияет на эффективность синхронизации.
--全量同步一般先delete，然后insert
delete from tmp_a;
insert into tmp_a xxx;
-- 或者直接 insert overwrite
insert overwrite table tmp_a xxx;
Синтаксис SQL может быть другим, в этом почти смысл, ха-ха
Не забудьте удалить или перезаписать вставку, иначе данных будет все больше и больше.
Выберите несколько сценариев инкрементной синхронизации:
-
Объем данных велик, а исторические данные меняются нечасто.
-
только дополнительные данные
При использовании инкрементной синхронизации есть некоторые требования к таблице, такие как create_time, поле update_time create_time представляет время создания записи, update_time представляет время обновления записи, если она инкрементальная, вам нужно только взять измененные данные (используйте update_time), Примечание. Здесь также должен быть первичный ключ, который используется для перезаписи данных.
Это связано с различными бизнес-сценариями. Некоторые записи не будут обновляться после их создания, как и данные о проточной воде. Такие данные можно брать напрямую поэтапно, и операция удаления не требуется, однако некоторые данные будут обновлены. ● Когда синхронизированные данные изменяются, сторона хранилища данных также должна быть синхронизирована.
2. Как сделать инкрементальный
Добавочная синхронизация также должна быть инициализирована один раз, и инициализация завершена.
Предположим, у нас есть такая таблица:
create table tmp_a(
id bigint,
create_time datetime,
update_time datetime
);
Как правило, в автономных сценариях операция синхронизации выполняется, когда объем бизнеса наименьший, и большая часть этого времени приходится на середину ночи и раннее утро, поэтому большая часть синхронизации начинается после 0:00, синхронизируя вчерашние данные, то есть Часто говорят Т+1.
Предположим, что следующие 4 записи созданы 1 марта, хранилище данных будет синхронизировано ранним утром 2 марта.
Второго добавили 1 запись и обновили 1. По правилу приращения получим две записи.
После получения инкрементных данных нам нужно объединить инкрементные данные в таблицу нашего хранилища данных.
Недавно добавленные данные можно вставлять напрямую, но для обновленных данных нам нужно обновить исходную запись или удалить, а затем вставить ее. Раньше мы также записывали статус вставки данных. Если она обновлена, запишите «обновление», если оно вставлено, запишите «вставка». Когда вы доберетесь сюда, вы должны знать, зачем вам нужен первичный ключ. Если первичного ключа нет, как узнать, изменилась ли эта запись?
Использование приращений обычно требует двух наборов таблиц, один для хранения добавочных данных, а другой для хранения полных полных данных.
3. etl_insert_time
Независимо от того, являются ли они инкрементными или полными, я предпочитаю добавлять поле метки времени, чтобы определить время вставки записи.Это особенно полезно при сравнении инкрементных данных для устранения проблем с данными.
4. Механизм синхронизации нашей компании
Что касается нас, начинающей компании с небольшим объемом данных, мы используем инструменты Alibaba Cloud.В начале все данные шли из полного объема для удобства.Объем данных был 10 терабайт.Много это исторические данные.
Хоть мы и пришли в полном объеме, но чтобы зафиксировать изменения записанных данных, мы используем метод pt (partition), который представляет собой полный снимок каждый день, это тоже сейчас дешевый метод обработки для хранения, который прост и груб . Когда я впервые пришел, я сказал, что это будет инкрементальный, но он был отклонен. Позже никто не пришел, чтобы сделать это слишком много таблиц, и стоимость модификации слишком высока.
5. Инкрементальный на основе Hive
Hive теперь также является стандартным. Упомянутые выше инкрементальные решения могут по-прежнему основываться на реляционных базах данных. В Hive из-за более сильной вычислительной мощности проблема объема данных может быть проигнорирована, поэтому было получено несколько решений. Основная причина — поддержка операций удаления в Hive, старайтесь не удалять.
- Сортировка (номер_строки)
Мы по-прежнему получаем добавочные данные каждый день, а затем вставляем добавочные данные в каждый раздел.Каждый раздел является добавочными данными дня.Конечно, если данные изменяются, записи одного и того же первичного ключа появятся в нескольких разделах, поэтому Если мы хотим получить последнюю полную версию данных, мы можем использовать row_number для сортировки по первичному ключу и времени, чтобы получить последнюю версию полных данных.
- full join
Используйте метод полного соединения, чтобы связать добавочные данные с полными историческими данными, а затем получить последнюю полную версию данных.
- left join + union all
Этот метод похож на метод полного соединения, я считаю, что этот метод более красивый и строгий, этот метод также использовался для инкрементов на GP в прошлом.
6. Таблица молнии
Говоря об инкрементах, я также должен упомянуть зиппер-таблицу, которая раньше использовалась больше, но я чувствую, что она редко используется в интернет-компаниях. В zip-таблице фактически фиксируется каждое изменение данных, что немного хлопотно обрабатывать.Это вроде уже писалось раньше, найду и выложу.
Соглашения восходящего и нисходящего потоков
Из-за характеристик и позиционирования хранилища данных оно должно сильно полагаться на вышестоящую бизнес-систему, и, конечно, есть также несколько нижестоящих систем, поэтому очень важно определить спецификации выше и ниже по течению и механизм уведомления об изменениях. .
Кажется, я уже писал про апстрим и даунстрим, но не нашел только сейчас, так что напишу еще раз здесь.
вверх по течению
То, о чем я здесь говорю, в основном основано на небольших компаниях, таких как компания-стартап, в которой я сейчас работаю.Как и в зрелой компании, идеально подходят различные регламенты процессов и отказоустойчивые механизмы мониторинга. это применяется.
Для хранилища данных наиболее важными являются данные.Основным источником данных в хранилище данных является бизнес-система, представляющая собой различные бизнес-данные компании.Поэтому хранилище данных должно постоянно синхронизировать данные бизнес-системы с собственными данными. При изменении вышестоящей бизнес-системы хранилище данных также должно изменяться синхронно, иначе эта операция синхронизации, скорее всего, завершится ошибкой.
- Изменения структуры таблицы
Структура восходящей таблицы часто меняется, добавляются поля, модифицируются поля и удаляются поля (если это поле действительно больше не используется, оно обычно помечается как устаревшее). Лучше всего четко поддерживать структуру таблицы. Имя таблицы, имя поля, тип поля и описание поля должны быть четко организованы. Неиспользуемые поля должны быть удалены или отмечены. Когда бизнес часто меняется или итеративно оптимизируется, легко Я долго писал код, и наконец обнаружил, что таблица используется неправильно, поле используется неправильно, что смущает.
Для такого рода изменений ручная обработка заключается в ручном добавлении и изменении полей в таблице, соответствующей хранилищу данных, а затем изменении задачи синхронизации.Автоматическом изменении структуры таблицы в хранилище данных и автоматическом изменении задачи синхронизации.
- значение перечисления
В бизнес-системе будет много констант для идентификации некоторых состояний или типов. Такие значения часто добавляются. Хранилище данных будет выполнять некоторую обработку этих значений, например преобразовывать их в измерения и переводить на соответствующий китайский язык. Мы не не знаю об этой связи сопоставления, об этом знает только бизнес-разработка, поэтому лучше позволить им вести таблицу значений перечисления, и давайте синхронизировать эту таблицу.
- create_time & update_time
Обычно create_time, когда эта запись будет вставлена, не изменится, но в некоторых случаях, ха-ха, разработчики его обновят; update_time, когда эта запись изменится, время тоже изменится, Некоторые разработчики его не обновляют...
Поэтому при выполнении инкрементных операций обязательно обсудите определения и сценарии использования этих двух полей с разработчиком.
- is_delete & is_valid
В некоторых случаях нам нужно удалить некоторые данные. Как правило, мы не удаляем их физически. Мы выполним логическое удаление через поле. Пожалуйста, свяжитесь с разработчиками, используйте фиксированное поле и подтвердите, что обе стороны имеют одинаковое понимание поля, иначе сзади будет много ям.
вниз по течению
После разговора о восходящем потоке, давайте поговорим о нисходящем.Для хранилищ данных общие электронные письма, отчеты и платформы визуализации являются нисходящими, поэтому, когда мы выполняем некоторые операции реконструкции и оптимизации в хранилище данных, нам также необходимо уведомлять их.
В основном для поддержки модели хранилища данных, сценариев использования таблиц, описаний полей и т. д.
Вы должны хорошо справляться с требованиями восходящего потока, потому что вы также являетесь восходящим потоком.
Примечания к задаче
Здесь говорится об аннотациях, а аннотации всегда заставляют людей любить и ненавидеть их.
Без комментариев, кто знает, для чего используются эти коды?С точки зрения кода, то, что вы хотите сделать, это А, но на самом деле требование Б, вы должны угадать, что вы делаете; если в коде есть комментарии, он не обязательно Можно сесть и расслабиться.Комментарии могут быть требованиями исходной версии.После нескольких версий код уже изменился,комментарии не изменились,а комментарии и код не совпадают.Кто знает какой один должен преобладать.
Все наши хранилища данных основаны на облаке Alibaba, и мы используем его DataWorks в качестве автономного инструмента Весь код находится на нем, поэтому вот краткое введение в задачи в облаке Alibaba и несколько спецификаций аннотаций.
-- @name p_dwd_rack_machine
-- @description 货架宽表
-- @target rack.dwd_rack_machine
-- @source owo_ods.kylin__machine_release_his
-- @source owo_ods.kylin__machine_device_his
-- @author yuguiyang 2017-12-25
-- @modify
@name: имя задачи. Имя нашей задачи обычно называется p_target имя таблицы. После обновления Alibaba DataWorks рекомендуется, чтобы имя задачи и имя таблицы совпадали.
@description: описание задачи, основное содержание задачи @target: имя целевой таблицы, обычно задача выводит только одну целевую таблицу
@source: Исходная таблица — это базовая таблица, используемая в задаче.Его также можно здесь не указывать.Его видно непосредственно из кровного родства, и легко пропустить обновление.
@author: создатель и дата создания, @modify: запись об изменении контента, изменение человека, дата изменения, причина изменения, это также можно найти в контроле версий, но здесь они более интуитивно понятны.
«Hard Presto | Принципы и настройка Presto, интервью и всесторонние обновления для реального боя»
"Hive Hive | Резюме интервью по базовой настройке из 40 000 слов"