Комментарии 6
Тема раскрыта не очень, не хватает детальности, и фокуса на каком-то одном направлении. Или обзор решения с точки зрения бизнеса, или технические показатели, или же обзор что умеет datafactory, и как его можно применить. Смешиваются понятия databricks/spark, насколько могу судить.
Например, при прочтении возник вопрос, почему в одном пайплайне используется и DataFactory и Databricks, и Synapse? При том что Synapse по сути своей приёмник datafactory и адаптация databricks разрабатываемая microsoft. Почему не получилось обойтись одним Synapse? Это ведь должно было как упростить логику, так и снизить косты?
Хорошая статья, автор молодец.
Интересно было узнать и о таком подходе. Но часто в практике миграции я сталкиваюсь со следующими проблемами:
Необходимость правки части записей вручную, либо по правилам, применимым к небольшой части загружаемых данных
Не всегда поддающиеся формализации процедуры обогащения данных
Проверка результатов миграции с ранжированием расхождений (в случае с тем же озером данных, например, корректность отработки ETL процедур)
Валидация результатов владельцем данных
Хотелось бы чтобы данные вопросы также были освещены в статье.
"Я знаю карате, ушу, кун-фу и еще много страшных слов". Каким организациям это подойдет, вы в Корусе про 152 ФЗ слышали?
Тащить данные сначала в Data Bricks, чтобы потом в Azure Synapse залить - почему напрямую нельзя? И зачем вам DataLake при этом? Попробовать новые технологи? А оркестратор какой?
"Масштабируемость"? А сколько стоит все это удовольствие, можете огласить? В паркет я и сам лить могу, мне для этого Azure не нужен. Дельту по паркету вы как собираете?
Пастух больших данных: как мы используем Azure Data Factory в качестве единого сервиса для задачи миграции