0x00 Предисловие
По прошествии полугода у меня несколько другое понимание хранилища данных, я вывернул контент про зиппер-таблицу, написанный ранее, и перевыпустил его с небольшой доработкой. В этой статье будет рассказано о содержимом, связанном с zip-таблицей в хранилище данных, в том числе о ее принципе, дизайне и реализации в нашем сценарии больших данных.
содержание
Полный текст состоит из следующих частей:
-
Сначала поделитесь назначением застежки-молнии, что такое застежка-молния.
-
Дайте конкретный сценарий приложения для разработки и реализации таблицы-молнии и, наконец, используйте несколько примеров, чтобы проиллюстрировать, как использовать таблицу, которую мы разработали (из-за широкомасштабного использования Hive сейчас,В качестве примера возьмем дизайн в сценарии Hive.).
-
Проанализируйте преимущества и недостатки таблицы с застежкой-молнией и дополните часть упомянутого выше содержания, например, разницу между таблицей с застежкой-молнией и счетчиком проточной воды.
0x01 Что такое zip-таблица
Таблица-молния определяется способом хранения данных в таблице в дизайне хранилища данных.Как следует из названия, так называемая застежка-молния предназначена для записи истории. Записывает информацию обо всех изменениях вещи от начала до текущего состояния.
Давайте сначала рассмотрим пример, который представляет собой zip-таблицу, в которой хранится самая основная информация о пользователях и жизненном цикле каждой записи. Мы можем использовать эту таблицу для получения последних данных за день и предыдущих исторических данных.
Мы пока не будем подробно объяснять эту таблицу, а конкретно объясним, как ее спроектировать, внедрить и использовать позже.
Сценарии использования зиппер-таблиц
В процессе проектирования модели данных хранилища данных часто встречается следующий дизайн таблицы:
-
Некоторые таблицы имеют большой объем данных, например пользовательская таблица с примерно 1 миллиардом записей и 50 полями.Даже если для сжатия используется Orc, объем хранения одной таблицы превысит 100G.Используйте двойное резервное копирование в Hdfs или Если есть три резервных копии, это будет больше.
-
Некоторые поля в таблице будут обновлены операцией обновления, например, контактная информация пользователя, описание продукта, статус заказа и т. д.
-
Вам необходимо просмотреть информацию об исторических моментальных снимках в определенный момент времени или период времени, например, чтобы просмотреть статус заказа в определенный момент времени в истории.
-
Доля и частота изменений записей в таблице не очень велика, например, всего пользователей 1 миллиард, а каждый день добавляется и меняется около 2 миллионов, и доля изменений очень мала.
Итак, как мне спроектировать эту таблицу? Ниже есть несколько вариантов:
-
Вариант 1: каждый день хранится только последняя копия Например, мы используем Sqoop для ежедневного извлечения последних полных данных в Hive.
-
Вариант 2. Храните полный фрагмент данных каждый день.
-
Вариант 3: Используйте столик на молнии.
Зачем использовать стол на молнии
Теперь мы проанализируем три упомянутых выше по порядку.
Вариант первый
Излишне говорить, что эта схема очень проста в реализации: каждый день данные предыдущего дня сбрасываются, а новые рисуются заново.
преимуществоОчевидно, что это экономит место, а некоторые общие применения также очень удобны: нет необходимости добавлять раздел времени или что-то еще при выборе таблицы.
недостатокТо же очевидное, исторических данных нет, сначала листать старый аккаунт можно только проходными другими путями, например, откачкой от счетчика воды.
Вариант 2
Полный срез в день — относительно безопасное решение, к тому же доступны исторические данные.
недостатокТо есть место для хранения слишком велико.Если вы будете вести полный объем этой таблицы каждый день, то много неизменной информации будет каждый раз сохраняться в полном объеме, что является большой тратой памяти.
Конечно, мы также можем пойти на некоторые компромиссы, например сохранить данные только за последний месяц. Тем не менее, спрос бесстыдный, жизненный цикл данных полностью нами не контролируется, вы обнаружите, что срок хранения может меняться с 30 дней до 90 дней, затем с 90 дней до 1 года, а затем нужно хранить вечно .
стол на молнии
Часы на молнии в основном соответствуют нашим потребностям в использовании.
Во-первых, это компромисс в плане места, хотя он и не такой маленький, как первый план, его ежедневный прирост может составлять всего одну тысячную или даже одну десятитысячную от второго плана.
На самом деле, оно может удовлетворить потребности, которые может удовлетворить второе решение, которое может не только получать последние данные, но также добавлять условия фильтрации и получать исторические данные. Так что в некоторых сценариях стол на молнии может решить многие проблемы.
0x02 Дизайн и реализация Zipper Table
как спроектировать стол на молнии
Давайте возьмем каштан, чтобы подробно рассказать о столике на молнии. Взяв в качестве примера таблицу пользовательских данных, давайте сначала посмотрим на изменения информации в таблице User в реляционной базе данных.
Данные в таблице на 01.01.2017:
Данные в таблице на 2017-01-02 заключаются в том, что данные пользователей 002 и 004 были изменены, а 005 — это новый пользователь:
Данные в таблице на 03.01.2017 заключаются в том, что данные пользователей 004 и 005 были изменены, а 006 — новый пользователь:
Если хранилище данных спроектировано как архивная таблица с застежкой-молнией для сохранения таблицы, будет следующая таблица, которая представляет собой данные за последний день (т. е. 2017-01-03):
инструкция
-
t_start_date указывает время начала жизненного цикла записи, а t_end_date указывает время окончания жизненного цикла записи.
-
t_end_date = '9999-12-31'
Указывает, что запись в настоящее время находится в допустимом состоянии. -
Если запрашиваются все действительные в настоящее время записи, то
select * from user where t_end_date = '9999-12-31'
. -
Если вы запросите исторический снимок 2017-01-02, то
select * from user where t_start_date <= '2017-01-02' and t_end_date >= '2017-01-02'
. (Здесь важно понимать, что это более важная часть часов на молнии.)
Реализовать zip-таблицу в Hive
В текущем сценарии больших данных большинство компаний выберут архитектуру хранилища данных, в которой доминируют Hdfs и Hive. В текущей версии Hdfs файлы в файловой системе изменить нельзя, а это значит, что таблицы Hive можно только удалять и добавлять, но не обновлять. Основываясь на этой предпосылке, давайте реализуем таблицу-молнию.
Взяв в качестве примера приведенную выше таблицу пользователей, мы хотим реализовать пользовательскую таблицу-молнию. Прежде чем реализовать его, нам нужно определить, какие источники данных у нас есть.
-
Нам нужна полная шкала пользователей для уровня Ods. По крайней мере, его нужно использовать для инициализации.
-
Таблица ежедневных обновлений пользователей.
И нам нужно определить временную гранулярность таблицы zip.Например, таблица zip принимает только одно состояние в день, то есть, если в день происходит 3 изменения состояния, мы берем только последнее состояние.Этот вид Таблица дневной детализации может фактически решить большую часть проблемы.
Кроме того, я хотел бы добавить, как получить ежедневную таблицу обновлений пользователей.Согласно опыту автора, существует 3 способа получения или косвенного получения ежедневного приращения пользователей.Поскольку это более важно, это объясняется подробно:
-
Мы можем отслеживать изменения данных базы данных Mysql, например, используя Canal, и, наконец, объединять ежедневные изменения, чтобы получить последнее состояние.
-
Предполагая, что мы получаем срез данных каждый день, мы можем взять разницу данных среза за два дня в качестве таблицы ежедневного обновления.В этом случае мы можем сначала объединить все поля, а затем взять md5, так что все в порядке. .
-
Водомер! Есть суточный расходомер.
Пользовательская таблица слоя Ods
Теперь давайте посмотрим на структуру таблицы срезов профиля пользователя нашего слоя Ods:
Таблица User_update слоя Ods
Затем нам также понадобится таблица ежедневного обновления пользователя, которая была проанализирована ранее, если мы получили эту таблицу, теперь мы предполагаем, что она уже существует.
стол на молнии
Теперь мы создаем zip-таблицу:
Реализовать инструкцию Sql
Тогда инициализированный Sql не будет записан.По сути, это эквивалентно взятию пользовательской таблицы слоя Ods за день.Напишем оператор ежедневного обновления.
Теперь мы предполагаем, что мы инициализировали дату 2017-01-01, а затем необходимо обновить данные дня 2017-01-02, у нас есть следующий SQL.
Затем установите две даты в качестве переменных, и все готово.
0x03 Дополнение
Итак, мы разобрали принцип и конструктивные идеи зип-стола, и реализовали зип-стол в среде Hive.Сделаем небольшие дополнения к зип-столу.
Молния часы и счетчик воды
В таблице проточных вод хранятся записи об изменениях пользователя.Например, в таблице проточных вод каждая запись об изменении пользователя будет храниться в данных за один день, а в таблице застежек-молний есть только одна запись.
Это проблема детализации, о которой необходимо позаботиться при разработке таблицы застежек-молний. Конечно, мы также можем установить меньшую гранулярность, которой обычно достаточно днем.
производительность запросов
Конечно, таблица zip также столкнется с проблемой производительности запросов.Например, если мы храним данные zip в течение 5 лет, то эта таблица обязательно будет относительно большой, и производительность при выполнении запросов будет относительно низкой.Я лично думаю, что есть два пути решения:
-
В некоторых механизмах запросов мы индексируем start_date и end_date, что может значительно повысить производительность. На самом деле этот метод не работает в Hive, т.к. Hive эквивалентен отсутствию индекса, но его можно учитывать в других системах.
-
Сохраняйте некоторые исторические данные. Например, мы сохраняем полный объем данных zip-таблицы в одной таблице, а затем открываем zip-таблицу, которая предоставляет данные только за последние 3 месяца.
Механизм устранения
Что касается механизма исключения, то он фактически связан с производительностью: с одной стороны, накопление всех данных будет приводить к тому, что расчет будет становиться все медленнее и медленнее, с другой стороны, бизнес-сторона фактически имеет определенный приоритет в спросе на исторические данные. данные.
Таким образом, некоторые механизмы исключения данных могут быть сформулированы при разработке зип-таблицы. Исключенные данные не нужно удалять.Например, мы создаем две таблицы zip, одна таблица zip сохраняет только последние десять фрагментов данных, а другие данные будут храниться в исторической таблице zip.
разное
Так же есть некоторые опыты в использовании, которые добавляются:
-
При использовании таблицы zip можно опустить t_end_date, который является датой истечения срока действия, но после его добавления многие запросы можно оптимизировать.
-
Вы можете добавить флаг состояния текущей строки, чтобы быстро определить текущее состояние.
-
Некоторый контент может быть добавлен к дизайну зип-таблицы, потому что мы сохраняем состояние каждый день.Если мы добавим в это состояние поле, например количество изменений в день, эффект зип-таблицы будет больше.
0xFF Сводка
Просто выплюнуть слот, чем больше вы чувствуете, что знаете больше, тем меньше вы осмеливаетесь писать в блог небрежно.
В начале ведение блога было довольно произвольным, я был очень смелым и осмелился написать, если у меня была идея, и меня не особо заботило правильное или неправильное.
Потом, пока я пишу, я получаю много отзывов. Некоторые из них общаются друг с другом, а некоторые указывают на недостатки. Я чувствую, что несу большую ответственность за написанное мной содержание, чем раньше, поэтому я намного осторожнее при письме.
Потом я узнал, что в моем предыдущем понимании на самом деле было много неправильных мест, я был бы очень виноват, а интернет очень страшное место для общественного мнения.Если бы у меня были какие-то ошибки в понимании, или я не подумал об это осторожно, некоторые люди распылят вас на кучу собак.Блин, после прочтения некоторых комментариев, мне становится стыдно, что я написал это сам, вместо того, чтобы опубликовать это. В это время я буду чувствовать, что ведение блога должно быть более осторожным: если вы чего-то не понимаете глубоко, вы не посмеете это написать.
Тем не менее, менталитет все еще должен быть спокойным.В конце концов, полученных положительных отзывов гораздо больше, чем отрицательных отзывов.Написание блога следует рассматривать как запись моего обучения, и я, кстати, поделюсь своими мыслями с миром .Существует давление, чтобы быть более мотивированным к обучению и ответственным за содержание, чтобы иметь более глубокое понимание.