Промежуточные таблицы в БД против области хранения

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

Для многих хранилищ данных, в которых вы пытаетесь обработать данные и создать измерения, часто существует процесс, в котором вы загружаете необработанные исходные данные в какую-то другую базу данных / таблицы как необработанные данные, а затем обрабатываете их в формате, который хотите вставить в свой таблицы фактов и измерений. Этот процесс усложняется тем фактом, что данные могут поступать с опозданием или данные, которые корректируются позже, поэтому часто эти системы проектируются с использованием секционированных таблиц в целевых таблицах фактов, чтобы обеспечить возможность повторной обработки данных для секции ( например, день) без повторной обработки всей таблицы фактов. Кроме того, процесс преобразования в этой промежуточной таблице может быть интенсивным, если сами данные поступают в форме, далекой от того, как вы хотите представить их в своем DW. Часто в локальных системах они обрабатываются в отдельной базе данных (возможно, на том же SQL Server), чтобы изолировать ее от производственной системы. Кроме того, иногда бывает, что эти промежуточные таблицы можно воссоздать из исходных исходных данных (файлов CSV или аналогичных), поэтому они не являются хранилищем записей для этого исходного материала. Это позволяет вам рассмотреть возможность использования простого режима восстановления для этой базы данных (который снижает требования к журналу ввода-вывода и время восстановления по сравнению с полным восстановлением). Хотя не каждый DW использует режим полного восстановления для обработанных данных DW (некоторые вместо этого выполняют двойную загрузку на вторую машину, так как конвейер существует), возможность использовать полное восстановление плюс физическая репликация журналов (группы доступности AlwaysOn) в SQL Server дает вам гибкость для создания копии базы данных для аварийного восстановления в другом регионе мира. (Вы также можете выполнить горизонтальное масштабирование чтения запросов на этом сервере, если хотите). Есть варианты этой базовой модели, но во многих локальных системах есть что-то подобное.

Когда вы смотрите на SQL Azure, вы видите некоторые сходства и некоторые различия, которые имеют значение при рассмотрении того, как настроить эквивалентную модель:

1. У вас есть полное восстановление для всех пользовательских баз данных (но tempdb находится в режиме простого восстановления). У вас также есть кворум-фиксация ваших изменений в N репликах (например, в группах доступности) при использовании баз данных v-core или премиум-класса, что имеет большое значение, потому что у вас часто есть более общая топология сети в общедоступных облачных системах по сравнению с настраиваемой системой, которую вы построить себя. Другими словами, время фиксации журнала может быть медленнее, чем в вашей текущей системе. Для пакетных систем это не обязательно имеет слишком большое значение, но вам нужно быть осторожным, чтобы использовать достаточно большие размеры пакетов, чтобы вы не ожидали в сети все время в своем приложении. Учитывая, что ваша промежуточная таблица также может быть базой данных SQL Azure, вам необходимо знать, что в ней также есть фиксация кворума, поэтому вы можете подумать, какие данные будут оставаться повседневными (остаются в базе данных SQL Azure) или .который может быть помещен в базу данных tempdb для снижения задержек и воссоздан в случае потери.
2. Сегодня в SQL Azure нет модели управления ресурсами внутри базы данных (кроме эластичных пулов, которые являются частичными и нацелены на другой вариант использования, чем DW). Таким образом, наличие отдельной промежуточной базы данных - хорошая идея, поскольку она изолирует вашу производственную рабочую нагрузку от обработки в промежуточной базе данных. Вы избегаете проблем с шумными соседями, поскольку на вашу основную производственную рабочую нагрузку влияет обработка дневных данных, которые вы хотите загрузить.
3. Когда вы подготавливаете машины для локального DW, вы часто покупаете достаточно большой массив хранения / SAN, на котором вы можете разместить свою рабочую нагрузку и, возможно, многие другие (сценарии консолидации). Базы данных премиум / виртуального ядра в SQL Azure настроены с использованием локальных SSD (при этом Hyperscale является новым дополнением, которое дает вам некоторую модель горизонтального масштабирования между машинами, которая в некоторых отношениях немного похожа на SAN). Итак, вам нужно продумать количество операций ввода-вывода в секунду, необходимое для вашей производственной системы и вашего процесса подготовки / загрузки. У вас есть возможность выбрать масштабирование каждого из них, чтобы лучше управлять своей рабочей нагрузкой и затратами (в отличие от капитальных затрат на покупку большого массива хранения, который создается заранее, а затем вы настраиваете рабочие нагрузки, чтобы они вписывались в него).
4. Наконец, есть также предложение SQL DW, которое работает немного иначе, чем SQL Azure - оно оптимизировано для больших рабочих нагрузок DW и имеет масштабируемые вычисления с возможностью масштабирования вверх / вниз. В зависимости от потребностей вашей рабочей нагрузки вы можете рассматривать это как конечную цель DW, если она больше подходит.

Чтобы перейти к исходному вопросу - можете ли вы запустить конвейер загрузки данных в SQL Azure? Да, ты можешь. Есть несколько предостережений по сравнению с вашим существующим локальным опытом, но это сработает. Честно говоря, есть люди, которые просто загружаются из файлов CSV или аналогичных напрямую, без использования промежуточной таблицы. Часто они не делают столько преобразований, поэтому YMMV в зависимости от ваших потребностей.

Надеюсь, это поможет.