Pull to refresh

Comments 7

Проблемы с качеством исходных данных. Я бы сказал, что 80% всех проблем связаны именно с этим аспектом:

  • Источники часто не обеспечивают постоянное качество данных (как с точки зрения технических аспектов, так и логических/бизнесовых). 

И

Потратив на это несколько месяцев мы убедились в бесперспективности данного занятия. Затраты на генерацию входных и выходных тестовых данных были значительными и сопоставимы с затратами на саму разработку. При этом в ходе такого вот тестирования чаще находили ошибки в тестовых данных, а не в коде. 

Кажется, эти два утверждения несколько противоречат друг-другу.

Не совсем понял, почему. Можете пояснить?
В первой части речь идет о том, что качество данных и их "разнообразие" не стабильно и никогда не знаешь, что тебе "прилетит", пока не начнешь грузить реальные данные (то форматы будут не те, то пропуски, то "сочетания несочетаемого", то API после 500 запросов в течение 10 минут отправляет тебя в бан и т.п.)
Во второй цитате идет речь о попытке лет 15 назад тестировать загрузку данных на синтетически сгенеренных данных, которая закончилась провалом, в том числе потому, что как бы не "извращался" тестировщик/аналитик, который генерит эти тестовые данные, он все равно не мог "выдумать" те кейсы, которые "подкидывали" реальные данные несмотря на все "дата контракты" и "логику здравого смысла"

Хорошая статья, спасибо. Кстати баланс на счету может быть отрицательным, это от страны зависит. У нас например разрешают кредитную линию для банковского счета, и соответственно баланс отображается отрицательным.

Согласен, может быть в зависимости от бухучета. В РСБУ например это допустимо только для парных счетов (но только внутри одного операционного дня). Но приходящие на ум "овердрафты" и "кредиты" - это на самом деле не "отрицательный остаток", а нормальный положительный, только не на пассивном "депозитном" счете , а на активном "кредитном".
А так да, видел системы банковские (российские), где для простоты и унификации (чтобы не городить отдельную логику для активных и пассивных счетов при обработе Дебет-Кредит) на уровне базы все остатки на активных счетах хранились со знаком "минус", а на пассивных были положительные.

Так поэтому дата-инженеринг это про Waterfall. Сначала мы тщательно фиксируем (аналитиками, например) требования к качеству данных (вплоть до значений отдельных колонок), затем настраиваем констрейнты (но это уже не обязательно, на raw/stage - слое их быть не должно, а вот на витринном - уже да). И отдельная тема - как обрабатывать "плохие" данные. Готового универсального рецепта тут нет.

где cloud фактически становится стандартом

Будучи обремененным опытом работы в банках, я с этим не согласен. И до "стандарта" облакам ещё далеко.

маниакальное стремление ограничить копирование данных с ПРОДа на ДЕВ

а вот тут - да, встречалось )))
а там, где был доступ на ПРОД, приходилось работать строго из офиса. Как будто я дома через все RDP и закрытые буферы обмена сразу себе на флешку скачаю гигабайт 500. Хотя случаи слива данных штатными сотрудниками именно из офиса вполне известны

Будучи обремененным опытом работы в банках, я с этим не согласен. И до "стандарта" облакам ещё далеко.

Зависит от индустрии и страны )

Как будто я дома ..

Так можно же безнаказанно скриншоты экрана делать!)

Sign up to leave a comment.

Articles