#relational-database #etl #data-warehouse
#реляционная база данных #etl #хранилище данных
Вопрос:
Мы используем Informatica PowerCenter для перемещения данных в основном из других реляционных баз данных в наше хранилище данных. Я разработал простой алгоритм для перемещения данных в звездообразную схему или любое материализованное представление с использованием захвата данных изменений и хотел бы знать, что в нем не так, чтобы я мог лучше понять привлекательность таких инструментов, как Informatica.
Предположения:
- У нас есть канал сообщений CDC, по которому поступают отдельные события insert / update / delete.
- Мы определили материализованное представление интереса как совокупный SQL-запрос к исходным таблицам. Другими словами, это SQL-запрос, который содержит группировку ПО выражению. Таким образом, материализованное представление гарантированно будет иметь согласованную степень детализации, а содержимое выражения GROUP BY можно рассматривать как его первичный ключ.
Алгоритм:
- По каналу приходит сообщение CDC. Строка исходной таблицы была изменена:
Мы перебираем любые запросы, которые зависят от этой таблицы. Для каждого запроса мы определяем, является ли таблица «первичной» или «неосновной» для данного конкретного запроса — например, использовалось ли значение из этой таблицы в запросе GROUP BY expression. Другими словами, мы определяем, зависит ли PK материализованного представления напрямую от этой таблицы.
- Была изменена основная таблица:
- Была вставлена строка первичной таблицы со значением P=p:
- Вставьте необработанную строку в наше зеркало исходной таблицы.
- Запустите интересующий запрос с фильтром, ГДЕ P=p, и найдите затронутые строки.
- Вставьте затронутые строки в нашу таблицу материализованного представления.
- Строка первичной таблицы была обновлена, и значение P = p1 изменилось на P = p2:
Мы разделяем это на два сообщения: ОТБРАСЫВАЕМ P = p1 (см. Ниже) и ВСТАВЛЯЕМ P = p2 (см. Выше).
- Строка первичной таблицы со значением P = p была удалена:
- Запустите интересующий запрос, выбрав только значения PK и фильтр, ГДЕ P= p, чтобы найти соответствующие значения PK (pk1, pk2, …, pkn).
- Удалите необработанную строку нашего зеркала исходной таблицы.
- Удалите строки, ГДЕ PK В (pk1, pk2, …, pkn) из таблицы материализованного представления.
- Была вставлена строка первичной таблицы со значением P=p:
- Была изменена неосновная таблица:
- Была вставлена строка неосновной таблицы с соответствующим значением V=v:
- Вставьте необработанную строку в наше зеркало исходной таблицы.
- Запустите интересующий запрос с фильтром, ГДЕ V=v, и найдите соответствующие значения PK (pk1, pk2, …, pkn).
- Запустите интересующий запрос с фильтром, ГДЕ PK in (pk1, pk2, …, pkn) и обновите эти строки в таблице материализованного представления.
- Строка неосновной таблицы была обновлена с соответствующим значением, измененным с V = v1 на V = v2:
Мы разделяем это на два сообщения: ОТБРАСЫВАЕМ V = v1 (см. Ниже) и ВСТАВЛЯЕМ V = v2 (см. Выше).
- Была удалена неосновная строка таблицы с соответствующим значением V=v:
- Запустите интересующий запрос, выбрав только значения PK и фильтр, ГДЕ V=v, чтобы найти соответствующие значения PK (pk1, pk2, …, pkn).
- Удалите необработанную строку из нашего зеркала исходной таблицы.
- Запустите интересующий запрос с фильтром, ГДЕ PK in (pk1, pk2, …, pkn) и обновите эти строки в таблице материализованного представления.
- Была вставлена строка неосновной таблицы с соответствующим значением V=v:
- Была изменена основная таблица:
Что делает его еще лучше:
- Любые обновления таблицы материализованного представления сами по себе могут быть преобразованы в сообщения CDC. Это позволило бы выполнять рекурсивные обновления материализованных представлений, которые зависят от других материализованных представлений.
Если бы такое решение действительно работало, было быстрым и масштабируемым, оно могло бы решить 80% наших проблем ETL. Однако я не могу быть первым, кто придумал такой наивный подход, поэтому, пожалуйста, скажите мне, почему это не может работать.
Комментарии:
1. Привет — вы спрашиваете мнение, поэтому ваш вопрос на самом деле не относится к этому форуму. Тем не менее, многие люди пишут свои собственные ETL-фреймворки (обычно в наши дни на Python), и у них есть хорошие и плохие причины для этого. Подумайте о том, как вы могли бы управлять сложными преобразованиями данных, происхождением данных, управлением данными, качеством данных, Различными типами исходных данных и т. Д. И т. Д., Используя вашу платформу
2. Спасибо за ответ, @NickW!
3. Чтобы быть более конкретным, я ищу логические ошибки и ошибки производительности (есть ли где-нибудь полное сканирование таблицы, которое я пропустил?) В моем алгоритме (это действительно просто алгоритм, а не полная структура), На которые, я думаю, можно ответить объективно. Я не могу придумать причину, по которой алгоритм не будет работать с произвольно сложными преобразованиями данных, если есть предложение GROUP BY . Происхождение данных тривиально, поскольку алгоритм уже полагается на него. Другие поднятые вами проблемы выходят за рамки, поскольку это не полная структура.
4. Привет — рад, что оказался неправ, но я сомневаюсь, что вы получите полезный ответ с этого сайта, поскольку он действительно здесь для помощи в решении реальных проблем с кодированием, а не псевдокодом / теоретическими алгоритмами. Не стесняйтесь внедрять реальное решение на основе вашего алгоритма, а затем возвращайтесь с конкретными вопросами, если что-то работает не так, как ожидалось, и вам нужна помощь в его решении
Ответ №1:
Для тех, кто рассматривает это в будущем, дифференциальный поток данных — гораздо лучшее решение, чем то, что я опубликовал. Существует SQL-подобная реализация дифференциального потока данных с открытым исходным кодом, которая называется Materialize .