Как приблизиться к миссии ETL?

Некоторые общие подсказки 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's или любая основанная на изменении функциональность трудно, поскольку необходимо смочь представить больше чем одну версию исходных данных к системе. При перемещении функциональности управления изменениями в код инфраструктуры можно протестировать его в изоляции с наборами данных тестирования. Это - победа в тестировании, поскольку оно уменьшает сложность Ваших требований тестирования системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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