В Фабрике данных Azure у меня есть конвейер (состоящий из потоков, но это технический аспект), который более или менее представляет собой следующий поток:
Получите набор элементов из набора данных (скажем: я получаю 5 автомобилей, у каждого автомобиля есть свои «столбцы» — идентификатор, цвет, модель,...)
превратить этот набор в массив: я делаю это с блоком Aggregate, который содержит функцию сценария «собрать».
Что я хочу :
Я хотел бы, чтобы на шаге 2 был создан объект, а не массив.
Если бы это был json, я бы хотел:
//NOT THIS
[
{ "id":"1", "model":"", "color":"red" },
{ "id":"2", "model":"", "color":"blue" },
]
//THIS
{
"1": { "model":"", "color":"red" },
"2": { "model":"", "color":"blue" },
}
Я пытался работать с объектами как со строками, а затем использовать кучу «заменить», чтобы превратить [ ] в { } ... но это слишком много усилий - и, что более важно, слишком высок риск того, что я совершу ошибку с побегом персонажа.
Как бы вы превратили набор элементов в один объект вместо массива?
Примечание: конечная цель состоит в том, чтобы позже иметь возможность работать с автомобилями как со словарем, а не с коллекцией, в терминах программирования. Я просто добавил это для тех, кто может гуглить это, не зная точно, что они ищут.
Вопрос несуразный. этот ответ предназначен для всех, чтобы понять, почему.
Фабрика данных работает со схемами. Каждый столбец строго типизирован.
Например, если представить, что я начал с набора данных на основе файла json:
[
{ "id":"1", "model":"", "color":"red" },
{ "id":"2", "model":"", "color":"blue" },
]
Затем эти значения немедленно именуются и преобразуются в известные типы данных: есть столбец с именем «id», другой столбец с именем «модель» и третий столбец с именем «цвет». У них есть имена. Есть шаблон. В каждом ряду одинаковый узор.
Единственное, что может не иметь имени, — это массив: потому что мы знаем, что это набор элементов, имеющих одинаковую схему (т. е. имена столбцов).
Но если вы превратите его в словарь, вы нарушите шаблон: теперь у вас есть объект, поля (столбцы) которого имеют непредсказуемые имена.
{
"1": { "model":"", "color":"red" },
"2": { "model":"", "color":"blue" },
}
например, в словаре чуть выше теперь есть поле (столбец) с именем "1", еще одно с именем "2", еще одно с именем "3"... Для этого объекта нет шаблона. Мы не знаем, сколько полей он может иметь. Помните: это не массив. Это должно быть объектом. Вы должны знать, сколько полей имеет объект, если планируете его вводить. Было бы еще хуже, если бы идентификаторы были гидами. Полностью зашифрованные, непредсказуемые имена полей/столбцов.
Другими словами, вы не можете определить тип этих данных json. и, следовательно, вы не можете разобрать его на объект, у которого есть схема, чтобы передать его вашему потоку в фабрике данных.
=================
При этом вы все равно можете создать словарь в виде строки, которую вы, возможно, захотите проанализировать позже, за пределами фабрики данных (например, в C#, в вашем бэкэнде, который реагирует на вставки в набор данных приемника).
Тогда вот как вы это получите:
В построителе выражений используйте такое выражение. По сути, используйте шаблон «редуктор»:
уменьшать(
элементы массива,
"",
#acc + toString(#item) + ",",
concat(символ(123), #результат,символ(125))
)
Конечно, замените «arrayItems» именем вашего собственного набора элементов, который вы получили из блока потока непосредственно перед только что добавленным производным блоком столбца.
Обратите внимание, что в моем случае в предыдущем кирпиче уже было выполнено следующее преобразование:
from
{ "id" : "1", ... ALL OTHER FIELDS ... }
to
{ "1": { ... ALL OTHER FIELDS ... } }
Я сделал это в еще одном производном столбце, на этот раз с таким выражением:
associate(id, @())
Другой ответ говорит, что вопрос бессмысленный. Но это не совсем так.
Если ваша цель действительно состоит в том, чтобы создать словарь, то есть вы действительно хотите иметь один столбец для каждого идентификатора, т. е. один выходной столбец для каждой входной строки, вы можете исследовать следующее поле фабрики данных Azure: «строки в столбцы», также известное как вращаться. например: Строки в столбцы в ADF
Обратите особое внимание на пояснения к пункту «Разрешить дрейф схемы», чтобы управлять развитием схемы по мере преобразования столбцов.
Примечание: конечно, вы хотите быть уверены, что будет достаточно небольшое количество входных идентификаторов — вы не хотите создавать один гигантский словарь. Я не знаю, как ADF отреагирует на это с точки зрения производительности.
Примечание. В этом ответе я обсуждаю только преобразование идентификаторов, но, конечно, все еще остается вопрос о превращении других полей/столбцов в объект словаря, предназначенный для соответствия ключу. Это будет сделано так же, как и в другом ответе (посмотрите на часть, касающуюся «ВСЕХ ДРУГИХ ПОЛЕЙ»).
Мне нужно проверить, но я думаю, что решение может быть связано с функцией «уменьшить»: kromerbigdata.com/2021/01/06/…