Как да подходим към ETL мисия?

Някои общи съвети за ETL

1. Помислете дали да го организирате по дестинация (например, целият код за създаване на Customerdimension живее в един и същ модул, независимо от източника). Това понякога е известно като субектно-ориентиран ETL. Това прави намирането на неща много по-лесно и ще повиши поддържаемостта на вашия код.

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

3. Сладкото място на ETL инструментите е в системи, където имате по-голям брой източници на данни със сравнително прости трансформации.

4. Направете кода годен за тестване, за да можете да отделите компонентите и да тествате изолацията. Кодът, който може да бъде изпълнен само от средата на сложен поток от данни в ETL инструмент, е много по-труден за тестване.

5. Направете извличането на данни тъпо с nobusiness логиката и копирайте в зоната на astaging. Ако имате бизнес логика, разпространена в слоевете за извличане и трансформиране, ще имате трансформации, които не могат да бъдат тествани изолирано и затрудняват проследяването на грешки. Ако преобразуването се изпълнява от етапна област, вие намалявате твърдата зависимост от изходната система, като отново повишавате възможността за тестване. Това е особена победа за 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 ключовете.