Существуют разные модели для конвейеров перемещения данных, и ни одна из них не является идеальной.Я сделаю несколько замечаний по общим шаблонам, которые я вижу в случае, если это поможет вам принимать решения по вашему приложению.
Для многих хранилищ данных, где вы пытаетесь использовать данные и создавать измерения, часто естьпроцесс, в котором вы загружаете необработанные исходные данные в некоторые другие базы данных / таблицы в виде необработанных данных, а затем обрабатываете их в формате, который хотите вставить в таблицы фактов и измерений.Этот процесс усложняется тем фактом, что вы можете получить данные с опозданием или данные, которые будут исправлены позднее, поэтому часто эти системы разрабатываются с использованием секционированных таблиц на целевых таблицах фактов, чтобы позволить повторную обработку данных на основе разделов (например, один день) без необходимости повторной обработки всей таблицы фактов.Кроме того, процесс преобразования в этой промежуточной таблице может быть интенсивным, если сами данные поступают в форме, далекой от того, как вы хотите представить их в своем DW.Часто в локальных системах они обрабатываются в отдельной базе данных (возможно, на том же SQL Server), чтобы изолировать ее от производственной системы.Кроме того, иногда случается, что эти промежуточные таблицы воссоздаются из исходных данных (файлы CSV или аналогичные), поэтому они не являются хранилищем записей для этого исходного материала.Это позволяет рассмотреть возможность использования простого режима восстановления в этой базе данных (что снижает требования к журналу ввода-вывода и время восстановления по сравнению с полным восстановлением).Хотя не каждый DW использует режим полного восстановления для обработанных данных DW (некоторые вместо этого выполняют двойную загрузку на второй компьютер, поскольку конвейер существует), возможность использовать полное восстановление и репликацию физического журнала (AlwaysOn Availability Groups) в SQL Server дает вамгибкость создания копии базы данных для аварийного восстановления в другом регионе мира.(Вы также можете выполнить масштабирование чтения запроса на этом сервере, если хотите).Существуют варианты этой базовой модели, но многие локальные системы имеют нечто подобное.
Когда вы смотрите на SQL Azure, есть некоторые сходства и некоторые различия, которые имеют значение при рассмотрении вопроса о том, как настроитьэквивалентная модель:
- У вас есть полное восстановление для всех пользовательских баз данных (но tempdb находится в простом восстановлении).У вас также есть кворум-фиксация ваших изменений в N репликах (например, в группах доступности) при использовании v-core или premium dbs, что имеет большое значение, потому что у вас часто есть более общая топология сети в системах публичного облака по сравнению с пользовательской системой, которую вы используете.построить себя.Другими словами, время фиксации журнала может быть медленнее текущей системы.Для пакетных систем это не обязательно имеет большое значение, но вы должны быть осторожны, чтобы использовать пакеты достаточно больших размеров, чтобы не ждать в сети все время в вашем приложении.Учитывая, что ваша промежуточная таблица также может быть базой данных SQL Azure, вы должны знать, что она также имеет кворумную фиксацию, поэтому вы можете подумать, какие данные будут оставаться в течение дня (остается в БД SQL Azure) по сравнению с... которые могут войти в базу данных tempdb для меньших задержек и быть воссозданными в случае потери.
- В SQL Azure сегодня нет модели управления ресурсами intra-db (кроме эластичных пулов, которые являются частичными и нацелены на другое использование).дело, чем DW).Таким образом, наличие отдельной промежуточной базы данных является хорошей идеей, поскольку она изолирует рабочую нагрузку от обработки в промежуточной базе данных.Вы избегаете шумных проблем соседей с основной рабочей нагрузкой, на которую влияет обработка данных дня, которые вы хотите загрузить.
- Когда вы предоставляете машины для локальной DW, вы часто покупаете достаточно большой массив хранения / SAN, чтобы вы могли разместить свою рабочую нагрузку и, возможно, многие другие (сценарии консолидации).БД премиум / v-core в SQL Azure устанавливаются с локальными твердотельными накопителями (с новым дополнением Hyperscale, которое дает вам модель межмашинного масштабирования, которая в некоторых отношениях немного похожа на SAN).Итак, вы хотели бы продумать IOPS, необходимые для вашей производственной системы и вашего процесса подготовки / загрузки.У вас есть возможность выбрать масштабирование каждого из них, чтобы лучше управлять своей рабочей нагрузкой и расходами (в отличие от покупки CAPEX большого массива хранилищ, который заранее спланирован, а затем вы настраиваете рабочие нагрузки, чтобы в него вписаться).
- Наконец, есть также предложение SQL DW, которое работает несколько иначе, чем SQL Azure - оно оптимизировано для больших рабочих нагрузок DW и имеет масштабируемые вычисления с возможностью масштабирования и увеличения, и уменьшения.В зависимости от ваших потребностей в рабочей нагрузке вы можете рассмотреть это в качестве конечной цели DW, если это лучше подходит.
Чтобы вернуться к исходному вопросу - можете ли вы запустить конвейер загрузки данных в SQL Azure?Да, ты можешь.Есть несколько предостережений по сравнению с вашим существующим опытом, но это сработает.Чтобы быть справедливым, есть также люди, которые просто загружают из файлов CSV или аналогичных напрямую, без использования промежуточной таблицы.Часто они не выполняют столько преобразований, поэтому YMMV основывается на ваших потребностях.
Надеюсь, это поможет.