Вам понадобится несколько файлов.Как правило, мои данные озера имеют несколько зон.Первая зона - Raw.Он содержит копию исходных данных, организованных в папки сущностей / год / месяц / день, где сущностью является таблица в вашей базе данных SQL.Как правило, эти файлы являются инкрементными нагрузками.Каждая добавочная загрузка для объекта имеет имя файла, похожее на Entity_YYYYMMDDHHMMSS.txt (и, возможно, даже больше информации), а не только Entity.txt.И отметка времени в имени файла - это конец добавочного среза (максимально возможное время вставки или обновления данных), а не просто текущее время, где это возможно (иногда они относительно одинаковы, и это не имеет значения, но я склоненполучить согласованное время окончания добавочного среза для всех таблиц в моем пакете).Вы можете получить дату папок и метку времени в имени файла с помощью , параметризовав папку и файл в наборе данных .
У Мелиссы Коутс есть две хорошие статьи об озере данных Azure: Зоны в озере данных и Варианты использования и планирование озера данных .Ее соглашения об именах немного отличаются от моих, но мы оба скажем вам быть последовательными.Я бы сначала поместил файл инкрементальной загрузки в Raw.Он должен отражать добавочные данные в том виде, как они были загружены из источника.Если вам нужна объединенная версия, это можно сделать с помощью фабрики данных или U-SQL (или по вашему выбору) и поместить в зону стандартизированного сырья.Есть некоторые проблемы с производительностью с небольшими файлами в озере данных, поэтому консолидация может быть хорошей, но все зависит от того, что вы планируете делать с данными после того, как поместите их туда .Большинство пользователей не имеют доступа к данным в зоне RAW, вместо этого используют данные из стандартизованных необработанных или курированных зон.Кроме того, я хочу, чтобы Raw был неизменным архивом, из которого я мог бы восстанавливать данные в других зонах, поэтому я склонен оставлять их в файлах по мере их поступления.Но если бы вы нашли, что вам нужно там консолидироваться, это было бы хорошо.
Отслеживание изменений - это надежный способ получения изменений, но мне не нравятся их соглашения об именах / организация файлов в их примере .Я хотел бы убедиться, что имя вашего файла имеет имя объекта и отметку времени.У них есть инкрементальный - [PipelineRunID].Я бы предпочел [Entity]_[YYYYMMDDHHMMSS]_[TriggerID].txt (или не указывать идентификатор запуска), потому что он более информативен для других.Я также склонен использовать идентификатор триггера, а не конвейер RunID.Идентификатор триггера находится во всех пакетах, выполняемых в этом экземпляре триггера (пакетном режиме), тогда как RunID конвейера специфичен для этого конвейера.
Если вы не можете отслеживать изменения, водяной знак в порядке.Я обычно не могу добавить отслеживание изменений в мои источники и должен идти с водяным знаком.Проблема заключается в том, что вы доверяете точной дате изменения приложения.Были ли случаи, когда строка обновлялась, а дата изменения не изменялась?Когда строка вставлена, обновляется ли дата изменения или вам нужно проверить два столбца, чтобы получить все новые и измененные строки?Это то, что мы должны учитывать, когда мы не можем использовать отслеживание изменений.
Подведем итог:
- Загрузите пошагово и назовите ваши инкрементные файлы разумно
- Если вам нужна текущая версия таблицы в озере данных, это отдельнаяфайл в вашей стандартизированной сырой или курированной зоне.