#amazon-redshift #data-warehouse
#amazon-redshift #хранилище данных
Вопрос:
Я начал работать инженером по обработке данных в компании, где у нас странная архитектура в нашем кластере Redshift, и я хотел знать, имеет ли это какой-либо смысл.
У нас есть ряд схем, в которых репликатор (Attunity) постоянно обновляет таблицы по мере изменений, происходящих в наших системах OLTP, по сути, создавая их зеркальное отображение на уровне хранилища ODS. Детали реализации этого не важны.
Однако по какой-то причине архитектор данных решил, что для использования этих данных на уровне ODS нам не следует напрямую выбирать из этих таблиц. Поэтому вместо этого он создал серию схем, в которых мы должны создать представление для каждой физической таблицы. Представления являются точными копиями 1: 1, все они в основном просто SELECT col1, col2, [...] FROM TABLE .
Это доставляет нам всевозможные головные боли и требует огромных затрат на обслуживание, потому что для того, чтобы получить новую таблицу из нашего OLTP в наш OLAP, нам нужно подготовить и предоставить разрешения дополнительному компоненту, который не служит никакой цели (по крайней мере, на мой взгляд), и всякий раз, когда происходит изменение, например, дополнительный столбец в нашей системе OLTP, мы должны добавлять его в 2 разных места на нашем уровне ODS. По сути, в два раза больше задач для управления.
Есть ли какая-либо техническая причина, по которой это имело бы смысл?
Комментарии:
1. Ответ очень прост: «Как вы справляетесь со случаем, если таблица ODS переименована или если переименован определенный столбец?» Если ответ заключается в том, что вы распространяете это изменение в соответствующем представлении, вы правы, вы ввели ненужные накладные расходы. В противном случае, если вы используете представление для отрицания (возврата) изменения, вы можете извлечь выгоду из дополнительного уровня представления.
2. Это не мой случай… Наш уровень представлений всегда должен быть на 100% идентичен базовым физическим таблицам. Исходное обоснование, которое они дали, было связано с тем, что блокировки таблиц были проблемой, если нет уровня просмотра. Но с технической точки зрения, всякий раз, когда вы выбираете из представления, вы не меняете тот факт, что в любом случае вы выбираете из физической таблицы, просто с представлением в качестве промежуточного шага. Так что это объяснение не имело смысла для меня, и по сей день я настроен скептически и считаю, что все это было совершенно ненужным
3. Что произойдет, если 100 пользователей запрашивают одну и ту же таблицу? Представления предоставляют способ предотвратить locks..in просмотр вам нужно указать БЛОКИРОВКУ ДЛЯ ДОСТУПА, чтобы она могла предотвратить блокировку, чтобы другие могли читать те же данные