Как подойти к миссии ETL?

Question

Я должен выполнить ETL, где источником является большая и плохо спроектированная база данных sql 2k и лучше спроектированная база данных sql 2k5. Я думаю, что SSIS - это путь. Может ли кто-нибудь предложить список дел, контрольный список или вещи, на которые стоит обратить внимание, чтобы я ничего не забыл? Как мне подойти к этому, чтобы потом не укусить меня сзади.

Answer 1

Некоторые общие советы ETL

1. Рассмотрите возможность организации пункт назначения (например, все код для выдачи Заказчику измерение живет в одном модуле, независимо от источника). Это иногда называют Предметно-ориентированный ETL. Это делает найти вещи намного проще и будет повысить ремонтопригодность вашего Код.

2. Если база данных SQL2000 является беспорядком, вы, вероятно, обнаружите, что SSIS потоки данных являются неуклюжим способом с данными. Как правило, инструменты ETL плохо масштабируется со сложностью; что-то вроде половины всех данных складские проекты в финансах компании делают с хранением код процедуры как явный архитектурное решение - именно по этой причине. Если у вас есть поместить большое количество кода в sprocs, рассмотрите возможность размещения всех код в sprocs.
   
   Для системы, включающей в себя множество сложных операций очистки или преобразования, 100% -ный метод sproc гораздо более удобен в обслуживании, поскольку это единственный реальный способ поместить все преобразования и бизнес-логику в одном месте. В смешанных системах ETL / sproc вам приходится искать в нескольких местах, отслеживать, устранять неполадки, отлаживать или изменять все преобразования.

3. Лучшее место в инструментах ETL - в системах, где у вас есть большее количество источников данных с относительно простыми преобразованиями.

4. Сделайте код тестируемым, чтобы вы могли разобрать компоненты и проверить в изоляции. Код, который может быть выполнен только в середине сложного потока данных в инструменте ETL, гораздо сложнее протестировать.

5. Сделать извлечение данных немым без бизнес-логики и скопировать в плацдарм. Если у вас есть бизнес логика распространилась по всей выдержке и преобразовать слои, у вас будет преобразования, которые не могут быть проверены в изоляции и сделать это трудно отследить ошибки. Если преобразование бег из области постановки вы уменьшить жесткую зависимость от исходная система, снова улучшающая проверяемость. Это особый выигрыш для архитектур на основе sproc, поскольку он позволяет создать практически полностью однородную кодовую базу.

6. Создание универсального медленно меняющегося обработчик измерений или использовать один из полка, если есть. Это делает это легче провести модульное тестирование функциональность. Если это может быть единица протестировано, система тестирования не должны проверить все угловые случаи, только ли данные представлены это правильно. Это не так сложно, как кажется. Последнее, что я написал, было около 600 или 700 строк кода T-SQL. То же самое касается любых общих функций очистки.

7. Загрузка по возможности постепенно.

8. Введите свой код - пусть он делает записи в журнале, возможно записывая диагностику, такую ​​как итоговые данные или счета. Без этого устранение неполадок практически невозможно. Кроме того, проверка утверждений - хороший способ подумать об обработке ошибок для этого (действительно ли количество строк при одинаковом числе строк в b соответствует соотношению A: B 1: 1).

9. Используйте синтетические ключи. Использование естественных ключей из исходных систем связывает вашу систему с источниками данных и затрудняет добавление дополнительных источников. Ключи и отношения в системе всегда должны совпадать - без нулей. Для ошибок, «не записанных», сделайте конкретные «ошибки» или «не записанные» записи в таблице измерений и сопоставьте их.

10. Если вы строите Оперативное хранилище данных (предмет многих религиозных войн), не используйте ключи ODS в схемах типа «звезда». Обязательно соединяйте ключи ODS для построения измерений, но сопоставляйте их с естественным ключом. Это позволяет вам произвольно отбрасывать и воссоздавать ODS - возможно, изменяя его структуру - без нарушения схем «звезда». Наличие этой возможности является реальным выигрышем в обслуживании, так как вы можете изменить структуру ODS или выполнить повторное развертывание ODS методом перебора в любой момент.

Точки 1-2 и 4-5 означают, что вы можете построить систему, в которой весь кода для любой данной подсистемы (например, отдельного измерения или таблицы фактов) находится в одном и только одном месте в система. Этот тип архитектуры также лучше для большего числа источников данных.

Точка 3 является контрапунктом к пункту 2. По сути, выбор между инструментами SQL и ETL является функцией сложности преобразования и количества исходных систем. Чем проще данные и чем больше источников данных, тем сильнее аргументация в пользу инструментального подхода. Чем сложнее данные, тем больше оснований для перехода на архитектуру, основанную на хранимых процедурах. Как правило, лучше или почти исключительно использовать один или другой, но не оба.

Пункт 6 облегчает тестирование вашей системы. Тестирование SCD или любых функциональных возможностей, основанных на изменениях, является трудоемким процессом, поскольку вы должны иметь возможность представить в систему более одной версии исходных данных. Если вы перенесете функции управления изменениями в код инфраструктуры, вы можете протестировать их изолированно с помощью наборов тестовых данных. Это победа в тестировании, поскольку она снижает сложность требований к тестированию вашей системы.

Точка 7 - это общий совет по производительности, который вам необходимо соблюдать для больших объемов данных. Обратите внимание, что вам может потребоваться только добавочная загрузка для некоторых частей системы; для справочных таблиц и размеров меньшего размера он может и не понадобиться.

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

Пункт 9 дает хранилищу данных собственную жизнь. Вы можете легко добавлять и удалять исходные системы, когда у хранилища есть свои собственные ключи. Ключи от склада также необходимы для реализации медленно меняющихся размеров.

Точка 10 - выигрыш в обслуживании и развертывании, поскольку ODS можно реструктурировать, если вам нужно добавить новые системы или изменить количество записей. Это также означает, что измерение может быть загружено из более чем одного места в ODS (например, добавление ручных корректировок учета) без зависимости от ключей ODS.

Answer 2

У меня есть опыт работы с процессами ETL, извлекающими данные из более 200 распределенных баз данных в центральную базу данных на ежедневной, еженедельной, ежемесячной и ежегодной основе Это огромный объем данных, и у нас было много проблем, характерных для нашей ситуации. Но, как я понимаю, есть несколько вещей, о которых нужно подумать, независимо от ситуации:

• Убедитесь, что вы учитываете блокировки файлов, как на стороне источника, так и на стороне назначения. Важно убедиться, что другие процессы не заблокировали файлы (и снять эти блокировки, если это необходимо и имеет смысл).

• блокировка файлов для себя. Удостоверьтесь, особенно в источнике, который вы блокируете файлы при извлечении данных, чтобы не получать обновленные данные наполовину.

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

• журнал выполнения. убедитесь, что вы знаете, когда это работает, а когда - нет, а выдача определенных ошибок в процессе может действительно помочь в отладке.

• документ, документ, документ. Если вы построите это правильно, вы собираетесь его построить, а потом долго не думать об этом. Но вы можете быть уверены, что вам или кому-то еще нужно будет вернуться к нему в какой-то момент, чтобы улучшить его или исправить ошибку. Документация является ключевой в этих ситуациях.

HTH, плохо обновлю это, если я думаю о чем-то еще.

Answer 3

Ну, я разрабатываю 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/SSISProgramming.aspx?display=PrintAll&fid=382208&df=90&mpp=25&noise=3&sort=Position&view=Quick&fr=26&select=2551674

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://msdn.microsoft.com/ja-jp/library/microsoft.sqlserver.dts.runtime.foreachloop.foreachenumerator.aspx

http://www.sqlis.com/post/Handling-different-row-types-in-the-same-file.aspx

http://technet.microsoft.com/en-us/library/ms135967(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms137709(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/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

http://www.codeplex.com/MSFTISProdSamples

http://www.experts -exchange.com / Microsoft / Разработка / MS-SQL-Server / SSIS / Q_23972361.html

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&PostID=1404157

http://msdn.microsoft.com/en-us/library/aa719592(VS.71).aspx

http://forums.microsoft.com/MSDN/MigratedForum.aspx?siteid=1&ForumID=80

http://blogs.conchango.com/jamiethomson/archive/2005/06/11/SSIS_3A00_-Custom-Logging-Using-Event-Handlers.aspx

http://blogs.conchango.com/jamiethomson/archive/2007/03/13/SSIS_3A00_-Property-Paths-syntax.aspx

http://search.live.com/results.aspx?q=%s&go=Buscar&form=QBJK&q1=macro%3Ajamiet.ssis

http://toddmcdermid.blogspot.com/2008/09/using-performupgrade.html?showComment=1224715020000

http://msdn.microsoft.com/en-us/library/ms136082.aspx

http://support.microsoft.com/kb/839279/en-us

Извините за "спам", но они очень полезны для меня.

Answer 4

Мы выполняем огромный ETL (перевод клиента из устаревших приложений AS400 в Oracle EBS), и у нас фактически есть процесс, который (с изменениями) я могу порекомендовать:

1. Определите критическую цель таблицы / поля.
2. Определите критические исходные таблицы / поля.
3. Работа с бизнес-пользователи для сопоставления источника мишени.
4. Анализ исходных данных для вопросы качества.
5. Определите, кто отвечает за вопросы качества данных определены.
6. Есть ответственные стороны очистить данные в источнике.
7. Разработка фактического ETL на основе информация из шагов 1 - 3.

По моему опыту, самые сложные шаги - это 2 и 3 - иногда бизнес-пользователям бывает сложно заставить правильно идентифицировать все нужные им биты за один проход, и еще сложнее точно определить, откуда поступают данные ( хотя это может иметь какое-то отношение к загадочным именам файлов и полей, которые я вижу!). Однако этот процесс должен помочь вам избежать серьезных промахов.

Answer 5

Эта ветка старая, но я хочу обратить ваше внимание на ответ ConcernedOfTunbridgeWells. Это невероятно хороший совет по всем пунктам. Я мог бы повторить несколько, но это уменьшило бы остальные, и все они заслуживают тщательного изучения.