Я использую следующий набор данных для тестирования потоков данных сопоставления: https://github.com/fivethirtyeight/data/tree/master/avengers.
Мой поток данных очень прост; Источник (файл с разделителями в AzureDataLakeStorageGen2), перемещающийся в приемник (паркетный файл в AzureDataLakeStorageGen2). Я использовал возможность импорта проекции, чтобы получить свою схему и установить значение «Проверить схему». Я получаю прогноз, который предполагает, что типы данных кажутся правильными. Стоит отметить, что мой набор данных, указывающий на этот источник, определяет все столбцы как строки, поэтому явно существует разрыв между схемой импорта в наборе данных и схемой преобразования потока данных источника. Смотрите это изображение. Прогноз источника потока данных
Если я попытаюсь использовать параметры проверки схемы, я столкнусь с проблемами. Первая проблема, которую я получаю, - это ошибка любого типа данных, не являющегося строкой. При использовании предварительного просмотра данных или запуске потока данных в конвейере, например Error: at Source 'AvengersHeader': Column 'Appearances has incompatible types( Found: StringType, Required: ShortType). Я предположил, что это произошло из-за строки заголовка, но исключив ее с помощью Пропустить счетчик строк со значением 1, я получил новую ошибку, например. Error: at Source 'AvengersHeader': Missing column 'URL.
В документации источника говорится
Проверить схему: если выбран вариант Проверить схему, поток данных не будет запущен, если входящие исходные данные не соответствуют определенной схеме набора данных.
Я предполагал, что это будет смотреть на типы данных, но теперь задаюсь вопросом, просто ли это предоставленные столбцы.
Для приемника документация я заявляю
Проверить схему: если выбрана проверка схемы, поток данных завершится ошибкой, если какой-либо столбец схемы входящего источника не будет найден в исходной проекции или если типы данных не совпадают. Используйте этот параметр, чтобы обеспечить соответствие исходных данных контракту вашей определенной проекции. В сценариях источника базы данных полезно сигнализировать об изменении имен или типов столбцов.
Отмечу пару вещей:
- Это указывает на изменения в источнике
- Он указывает, что тип источника не совпадает, однако, похоже, этого не происходит.
Тогда мой вопрос: может ли кто-нибудь указать на конкретную документацию, в которой подробно описывается ожидаемое поведение и использование этого? Либо официальная документация MS, либо блоги, я не привередничаю. Если кто-то захочет бросить свои 2 цента / пенни, это тоже нормально.
Глядя на это дальше, я исследовал производный столбец, за которым следует условное разбиение, но это потенциально требует довольно много времени:
`iif(
isNull(toInteger(Appearances))==true()
|| isNull(toBoolean(case(or({Current?}=='', isNull({Current?})) == true(), 'NO',{Current?})) )== true()
|| isNull(toShort(Year)) == true()
|| isNull( toShort({Years since joining}))== true()
|| isNull(toBoolean(case(or(Death1=='', isNull(Death1)) == true(), 'NO',Death1)) )== true()
|| isNull(toBoolean(case(or(Return1=='', isNull(Return1)) == true(), 'NO',Return1)) )== true()
|| isNull(toBoolean(case(or(Death2=='', isNull(Death2)) == true(), 'NO',Death2)) )== true()
|| isNull(toBoolean(case(or(Return2=='', isNull(Return2)) == true(), 'NO',Return2)) )== true()
|| isNull(toBoolean(case(or(Death3=='', isNull(Death3)) == true(), 'NO',Death3)) )== true()
|| isNull(toBoolean(case(or(Return3=='', isNull(Return3)) == true(), 'NO',Return3)) )== true()
|| isNull(toBoolean(case(or(Death4=='', isNull(Death4)) == true(), 'NO',Death4)) )== true()
|| isNull(toBoolean(case(or(Return4=='', isNull(Return4)) == true(), 'NO',Return4)) )== true()
|| isNull(toBoolean(case(or(Death5=='', isNull(Death5)) == true(), 'NO',Death5)) )== true()
|| isNull(toBoolean(case(or(Return5=='', isNull(Return5)) == true(), 'NO',Return5)) )== true()
,1,0
)`
Преобразование «Условное разделение» ищет строки, которые соответствуют требованиям, и записывает их, записывая искаженные строки в другом месте.
Хотя это работает, я не уверен, что сделал бы это, вместо этого фрейм данных, использующий _corrupt_record, чувствует, что это решит мою проблему намного легче. вопрос, зачем мне пытаться выполнить проверку в отображении потоков данных?
