Как подойти к выполнению миссии ETL?
https://stackoverflow.com/questions/440346
-
22-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Предполагается, что я выполняю ETL, где исходным кодом является большая и плохо спроектированная база данных sql 2k и лучше спроектированная база данных sql 2k5.Я думаю, что SSIS - это правильный путь.Кто-нибудь может предложить список дел, или контрольный список, или на что следует обратить внимание, чтобы я ничего не забыл?Как мне следует подойти к этому, чтобы позже он не укусил меня сзади?
Решение
Ну, я разрабатываю ETL для компании, где я нахожусь.
Мы работаем с SSIS. Использование API для генерации и сборки наших собственных пакетов DTSX.
SSIS не подходит для управления ошибками. Иногда вы получаете сообщение «Ошибка OleDb» это может иметь много разных значений в зависимости от контекста.
Прочитайте документацию по API (они мало говорят).
Некоторые ссылки, которые помогут вам начать там: http://technet.microsoft.com/de-de /library/ms135932(SQL.90).aspx
http://msdn.microsoft.com/en-us/library /ms345167.aspx
http://msdn.microsoft.com/en-us/library /ms403356.aspx
http://www.codeproject.com/KB/database/foreachadossis.aspx
http://wiki.sqlis.com/default.aspx/SQLISWiki /ComponentErrorCodes.html
http: // www.new.facebook.com/inbox/readmessage.php?t=1041904880323#/home.php?ref=logo
http://technet.microsoft.com/en-us/library /ms187670.aspx
http: // www .sqlis.com / запись / Обработка-разные-строки-типа-в-же-file.aspx
http://technet.microsoft.com/ ан-нас / библиотека / ms135967 (SQL.90) .aspx
http://msdn.microsoft.com/ ан-нас / библиотека / ms137709 (SQL.90) .aspx
http://msdn.microsoft.com/ ан-нас / библиотека / ms345164 (SQL.90) .aspx
http://msdn.microsoft.com/en-us/library /ms141232.aspx
http://www.microsoft.com/technet/prodtechnol /sql/2005/ssisperf.mspx
http://www.ivolva.com/ssis_code_generator.html
http://www.ivolva.com/ssis_wizards.html
Другие советы
Несколько общих советов по ETL
Рассмотрите возможность организации его по назначению (например, весь код для создания измерения Customer находится в одном модуле, независимо от источника).Это иногда называют Предметно-ориентированный ETL.Это значительно упрощает поиск материала и повысит ремонтопригодность вашего кода.
Если в базе данных SQL2000 царит беспорядок, вы, вероятно, обнаружите, что службы безопасности потоки данных - это неуклюжий способ работы с данными.Как правило, инструменты ETL плохо масштабируются из-за сложности;примерно половина всех проектов хранилищ данных в финансовых компаниях компании работают с хранимым процедурным кодом в явном виде архитектурное решение - именно по этой причине.Если вам нужно поместить большой объем кода в sprocs, рассмотрите возможность размещения ВСЕ из кода в sprocs.
Для системы, включающей множество сложных операций очистки или преобразований, подход 100% sproc гораздо более удобен в обслуживании, поскольку это единственный возможный способ объединить все преобразования и бизнес-логику в одном месте.В смешанных системах ETL / sproc вам приходится искать в нескольких местах для отслеживания, устранения неполадок, отладки или изменения всего преобразования.Преимущества инструментов ETL заключаются в системах, где у вас есть большее количество источников данных с относительно простыми преобразованиями.
Сделайте код тестируемым, чтобы вы могли разбирать компоненты и тестировать изолированно.Код, который может быть выполнен только из середины сложного потока данных в инструменте ETL, гораздо сложнее протестировать.
Сделайте извлечение данных немым, без бизнес-логики, и скопируйте в промежуточную область.Если у вас есть бизнес логика распространилась по всему извлечения и преобразование слоев, у вас будет преобразования, которые не могут быть проверены в изоляции и принять его трудно отслеживать ошибки.Если преобразование выполняется из промежуточной области, вы уменьшаете жесткую зависимость от исходной системы, что снова повышает тестируемость.Это особый выигрыш для архитектур, основанных на sproc, поскольку он обеспечивает почти полностью однородную кодовую базу.
Создайте универсальный медленно изменяющийся обработчик измерений или используйте готовый обработчик, если таковой имеется.Это позволяет упростить модульное тестирование этой функциональности.Если это может быть модульно протестировано, системное тестирование не должно проверять все угловые случаи, просто правильны ли данные, представленные в it.Это не так сложно, как кажется - последнее, что я написал, было примерно 600 или 700 строк кода на T-SQL.То же самое относится к любым общим функциям очистки.
Загружайте постепенно, если это возможно.
Запрограммируйте свой код - пусть он делает записи в журнале, возможно, записывая диагностические данные, такие как контрольные итоги или подсчеты.Без этого устранение неполадок практически невозможно.Кроме того, проверка утверждений - хороший способ подумать об обработке ошибок для этого (количество строк равно количеству строк в b, действительно ли отношение A: B 1: 1).
Используйте синтетические ключи.Использование естественных ключей из исходных систем привязывает вашу систему к источникам данных и затрудняет добавление дополнительных источников.Ключи и взаимосвязи в системе всегда должны совпадать - никаких нулей.Для ошибок "не записано" внесите конкретные записи "ошибка" или "не записано" в таблицу измерений и сопоставьте их.
Если вы создаете Оперативное хранилище данных (предмет многих религиозных войн), не используйте повторно ключи ODS в схемах star.Обязательно соединяйте по ключам ODS для построения измерений, но сопоставляйте по естественному ключу.Это позволяет вам произвольно отбрасывать и воссоздавать ODS - возможно, изменяя его структуру - без нарушения схем звездочек.Наличие этой возможности - реальный выигрыш в обслуживании, поскольку вы можете изменить структуру ODS или выполнить повторное развертывание ODS методом перебора в любой момент.
Пункты 1-2 и 4-5 означают, что вы можете построить систему, в которой ВСЕ кода для любой заданной подсистемы (например,одно измерение или таблица фактов) находится в одном и только одном месте в системе.Этот тип архитектуры также лучше подходит для большего количества источников данных.
Пункт 3 является контрапунктом к пункту 2.По сути, выбор между инструментами SQL и ETL зависит от сложности преобразования и количества исходных систем.Чем проще данные и больше количество источников данных, тем убедительнее аргументы в пользу подхода, основанного на инструментах.Чем сложнее данные, тем убедительнее аргументы в пользу перехода к архитектуре, основанной на хранимых процедурах.Как правило, лучше использовать исключительно или почти исключительно одно из них, но не оба сразу.
Пункт 6 упрощает тестирование вашей системы.Тестирование SCD или любой функциональности, основанной на изменениях, сопряжено с трудностями, поскольку вы должны иметь возможность представить системе более одной версии исходных данных.Если вы перенесете функциональность управления изменениями в код инфраструктуры, вы сможете протестировать ее изолированно с помощью наборов тестовых данных.Это выигрыш в тестировании, поскольку снижает сложность требований к тестированию вашей системы.
Пункт 7 - это общий совет по производительности, который вам нужно будет соблюдать при работе с большими объемами данных.Обратите внимание, что вам может потребоваться инкрементная загрузка только для некоторых частей системы;для справочных таблиц меньшего размера и размеров это может вам не понадобиться.
Пункт 8 имеет отношение к любому безголовому процессу.Если ночью что-то пойдет не так, вам нужен хоть какой-то шанс увидеть, что пошло не так, на следующий день.Если код неправильно регистрирует происходящее и улавливает ошибки, вам будет гораздо сложнее устранить это.
Пункт 9 дает хранилищу данных самостоятельную жизнь.Вы можете легко добавлять и удалять исходные системы, когда у склада есть свои собственные ключи.Складские ключи также необходимы для реализации медленно изменяющихся размеров.
Пункт 10 - это выигрыш в обслуживании и развертывании, поскольку ODS может быть реструктурирована, если вам нужно добавить новые системы или изменить количество элементов записи.Это также означает, что измерение может быть загружено более чем из одного места в ODS (подумайте:добавление корректировок учета вручную) без зависимости от ключей ODS.
У меня есть опыт работы с процессами ETL, которые извлекают данные из более чем 200 распределенных баз данных в центральную базу данных на ежедневной, еженедельной, ежемесячной и ежегодной основе.Это огромный объем данных, и у нас возникло много проблем, специфичных для нашей ситуации.Но, на мой взгляд, есть несколько пунктов, о которых стоит подумать независимо от ситуации:
Убедитесь, что вы принимаете во внимание блокировки файлов как на стороне источника, так и на стороне назначения.Важно убедиться, что файлы не заблокированы другими процессами (и снять эти блокировки, если это необходимо и имеет смысл).
блокируете файлы для себя.Убедитесь, особенно в исходном коде, что вы блокируете файлы при извлечении данных, чтобы не получить обновленные наполовину данные.
если это вообще возможно, извлеките дельты, а не все данные.Получите копию данных, а затем извлеките только те строки, которые были изменены, а не все.Чем больше ваш набор данных, тем важнее это становится.Если нужно, просмотрите журналы и триггеры, но поскольку становится все более важным иметь эти данные на определенной основе, это, вероятно, совет номер один, который я бы вам дал.Даже если это отнимет значительное количество времени у проекта.
журнал выполнения.убедитесь, что вы знаете, когда это сработало, а когда нет, и появление определенных ошибок в процессе действительно может помочь в отладке.
документ, документ, документ.Если вы построите это правильно, вы построите это, а затем долгое время не будете думать об этом.Но вы можете быть уверены, что вам или кому-то еще в какой-то момент нужно будет вернуться к нему, чтобы улучшить его или исправить ошибку.Документация играет ключевую роль в таких ситуациях.
ХТХ, я обновлю это, если вспомню что-нибудь еще.
Мы выполняем огромный ETL (перевод клиента из устаревших приложений AS400 в Oracle EBS), и у нас фактически есть процесс, который (с изменениями) я могу порекомендовать:
<Ол>Самые сложные шаги - 2 & amp; 3 по моему опыту - иногда трудно заставить бизнес-пользователей правильно идентифицировать все нужные им биты за один проход, и еще сложнее правильно определить, откуда именно поступают данные (хотя это может иметь какое-то отношение к загадочному имена файлов и полей, которые я вижу!). Однако этот процесс должен помочь вам избежать серьезных промахов.
Эта ветка старая, но я хочу обратить ваше внимание на ответ ConcernedOfTunbridgeWells. Это невероятно хороший совет по всем пунктам. Я мог бы повторить несколько, но это уменьшило бы остальные, и все они заслуживают пристального изучения.
