Какво представлява процесът ETL (извличане, преобразуване, зареждане) в хранилището на данни?

what is etl extract

Този задълбочен урок за ETL процес обяснява потока и стъпките на процеса, включени в процеса на ETL (извличане, преобразуване и зареждане) в хранилището на данни:

Този урок от поредицата обяснява: Какво е ETL процес? Извличане на данни, трансформация, зареждане, плоски файлове, какво е етапиране? ETL цикъл и др.

Да започваме!!

=> Вижте Тук перфектното ръководство за обучение по съхранение на данни.

Какво ще научите:

• Основи на процеса на ETL (извличане, преобразуване, зареждане)
  • Какво представлява ETL процесът в хранилището на данни?
  • Извличане на данни
    • Методи за извличане в хранилището на данни
    • Извличане на променени данни
  • Преобразуване на данни
    • Как да приложим трансформацията?
  • Зареждане на данни
  • Плоски файлове
    • Обработка на плоски файлове с фиксирана дължина
    • Обработка на разграничени плоски файлове
  • Предназначение на сценичната зона
  • Проектиране на сценичната зона
  • Поток на ETL процес
• Заключение
  • Препоръчително четене

Основи на процеса на ETL (извличане, преобразуване, зареждане)

Целева аудитория

• Хранилище за данни / ETL разработчици и тестери.
• Професионалисти в базата данни с основни познания за концепции за бази данни.
• Администратори на бази данни / експерти за големи данни, които искат да разберат областите за съхранение на данни / ETL.
• Завършили колеж / Преподаватели, които търсят работа в склад за данни.

Какво представлява ETL процесът в хранилището на данни?

Всички знаем, че хранилището за данни представлява колекция от огромни обеми данни, за да предостави информация на бизнес потребителите с помощта на инструментите за бизнес разузнаване.

За тази цел DW трябва да се зарежда на редовни интервали. Данните в системата се събират от една или повече операционни системи, плоски файлове и т.н. Процесът, който пренася данните в DW, е известен като ETL процес . Извличането, трансформацията и зареждането са задачите на ETL.

# 1) Екстракция: Всички предпочитани данни от различни системи източници като бази данни, приложения и плоски файлове се идентифицират и извличат. Извличането на данни може да бъде завършено чрез стартиране на задачи в неработно време.

# 2) Трансформация: Повечето от извлечените данни не могат да бъдат директно заредени в целевата система. Въз основа на бизнес правилата могат да се извършат някои трансформации преди зареждането на данните.

Например, данните за целевата колона могат да очакват две входни колони, обединени данни като вход. По същия начин може да има сложна логика за трансформация на данни, която се нуждае от експертиза. Някои данни, които не се нуждаят от трансформации, могат да бъдат директно преместени в целевата система.

Процесът на трансформация също коригира данните, премахва всички грешни данни и коригира грешки в данните, преди да ги зареди.

# 3) Зареждане: Цялата събрана информация се зарежда в целевите таблици на хранилището на данни.

Извличане на данни

Извличането на данни играе основна роля при проектирането на успешна DW система. Различните системи източници могат да имат различни характеристики на данните и процесът ETL ще управлява ефективно тези разлики, докато извлича данните.

' Карта на логическите данни ”Е основен документ за извличане на данни. Това показва кои изходни данни трябва да отидат към коя целева таблица и как полетата на източника се съпоставят със съответните полета на целевата таблица в процеса на ETL.

По-долу са описани стъпките, които трябва да бъдат изпълнени по време на проектирането на логически данни:

• Архитект на хранилище за данни проектира документа на логическата карта с данни.
• Позовавайки се на този документ, разработчикът на ETL ще създаде ETL работни места, а ETL тестерите ще създадат тестови случаи.
• Всички конкретни източници на данни и съответните елементи от данни, които подкрепят бизнес решенията, ще бъдат споменати в този документ. Тези елементи от данни ще действат като входове по време на процеса на извличане.
• Данните от всички системи източници се анализират и всякакъв вид аномалии на данните се документират, така че това помага при проектирането на правилните бизнес правила, за да спре извличането на грешни данни в DW. Такива данни са отхвърлени тук.
• След като моделът на крайния източник и целеви данни бъде проектиран от архитектите на ETL и бизнес анализаторите, те могат да направят разходка с разработчиците на ETL и тестерите. По този начин те ще получат ясно разбиране за това как трябва да се изпълняват бизнес правилата на всяка фаза на извличане, преобразуване и зареждане.
• Преглеждайки правилата за картографиране от този документ, архитектите на ETL, разработчиците и изпитателите трябва добре да разберат как данните протичат от всяка таблица като измерения, факти и всякакви други таблици.
• Тук също се споменава всякакъв вид правила или формули за манипулиране на данни, за да се избегне извличането на грешни данни. Например, извличайте само последните 40 дни данни и т.н.
• Екипът на ETL носи отговорност да проучи данните според бизнес изискванията, да изведе всяка полезна система от източници, таблици и колони, които да бъдат заредени в DW.

Документът с карта с логически данни обикновено е електронна таблица, която показва следните компоненти:

Диаграма на потока на извличане:

Посочете предварително времевия прозорец за стартиране на заданията към всяка система източник, така че да няма пропуснати данни по време на цикъла на извличане.

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

Методи за извличане в хранилището на данни

В зависимост от източниците и целевите среди за данни и бизнес нуждите можете да изберете метода за извличане, подходящ за вашата DW.

# 1) Логически методи за извличане

Извличането на данни в система за съхранение на данни може да бъде еднократно пълно зареждане, което се извършва първоначално (или) може да бъде допълнително зареждане, което се случва всеки път с постоянни актуализации.

въпроси и отговори за интервю за тестово ръководство pdf

• Пълна екстракция: Както подсказва самото име, системните данни се извличат напълно в целевата таблица. Всеки път, когато този вид извличане зарежда всички текущи системни данни на източника, без да се вземат предвид последните извлечени времеви печати. За предпочитане можете да използвате пълна екстракция за първоначалните натоварвания или таблици с по-малко данни.
• Допълнителна екстракция: Данните, които са добавени / модифицирани от определена дата, ще бъдат взети предвид за допълнително извличане. Тази дата е специфична за бизнеса като последна извлечена дата (или) дата на последната поръчка и т.н. Можем да се позовем на колона с времеви отпечатък от самата изходна таблица (или) може да се създаде отделна таблица, която да проследява само подробностите за датата на извличане. Позоваването на клеймото за време е важен метод по време на инкрементална екстракция. Логиката без клеймо за време може да се провали, ако таблицата DW има големи данни.

# 2) Методи за физическо извличане

В зависимост от възможностите на системите източници и ограниченията на данните, системите източник могат да предоставят данните физически за извличане като онлайн извличане и извличане офлайн. Това поддържа всеки от логическите типове извличане.

• Онлайн извличане :: Можем директно да се свържем с произволни системни бази данни с низовете за свързване, за да извлечем данни директно от системните таблици на източника.
• Извличане офлайн :: Тук няма да се свързваме директно с базата данни на системата източник, вместо това системата източник предоставя данни изрично в предварително дефинирана структура. Изходните системи могат да предоставят данни под формата на плоски файлове, файлове за изхвърляне, архивни дневници и таблични пространства.

Инструментите ETL са най-подходящи за извършване на сложни извличания на данни, независимо колко пъти за DW, въпреки че са скъпи.

Извличане на променени данни

След като първоначалното зареждане приключи, е важно да се помисли как да се извлекат данните, които са променени от системата източник допълнително. Екипът на ETL Process трябва да разработи план за това как да се приложи извличането за първоначалните и допълнителните натоварвания в началото на самия проект.

Най-вече можете да разгледате стратегията „Одитиращи колони“ за нарастващото натоварване, за да заснемете промените в данните. По принцип системните таблици-източници могат да съдържат колони за одит, които съхраняват времевия печат за всяко вмъкване (или) модификация.

Клеймото за време може да се попълни от тригери на базата данни (или) от самото приложение. Трябва да осигурите точността на данните на одитните колони, дори ако те се зареждат по някакъв начин, за да не пропуснете променените данни за допълнителни натоварвания.

По време на допълнителното зареждане можете да вземете предвид максималната дата и час, когато се е случило последното зареждане, и да извлечете всички данни от системата източник с времевия печат, по-голям от последния времеви печат.

Докато извличате данните:

• Използвайте оптимално заявките за извличане само на данните, от които се нуждаете.
• Не използвайте клаузата Distinct, тъй като забавя изпълнението на заявките.
• Използвайте SET оператори като Union, Minus, Intersect внимателно, тъй като влошава производителността.
• Използвайте ключови думи за сравнение като like, between и т.н. в клаузата where, а не функции като substr (), to_char () и т.н.

Преобразуване на данни

Трансформацията е процес, при който набор от правила се прилага към извлечените данни преди директно зареждане на системните данни източник в целевата система. Извлечените данни се считат за сурови данни.

Процесът на трансформация с набор от стандарти привежда всички различни данни от различни системи източници в използваеми данни в системата DW. Преобразуването на данни има за цел качеството на данните. Можете да се обърнете към документа за картографиране на данни за всички правила за логическа трансформация.

Въз основа на правилата за трансформация, ако дадени източници не отговарят на инструкциите, тогава тези източници се отхвърлят преди зареждане в целевата DW система и се поставят във файл за отхвърляне или в таблица за отхвърляне.

Правилата за трансформация не са посочени за данните за колоните с директно натоварване (не се нуждае от промяна) от източник до цел. Следователно трансформациите на данни могат да бъдат класифицирани като прости и сложни. Трансформациите на данни могат да включват преобразуване на колони, преформатиране на структурата на данни и т.н.

По-долу са дадени някои от задачите, които трябва да бъдат изпълнени по време на трансформацията на данни:

# 1) Избор: Можете да изберете или цялата таблична информация, или конкретен набор от данни от колони от системите източник. Изборът на данни обикновено се завършва при самото извличане.

Възможно е да има случаи, при които системата-източник не позволява да се избере определен набор от данни за колони по време на фазата на извличане, след това да се извлекат всички данни и да се направи селекция във фазата на трансформация.

# 2) Разделяне / присъединяване: Можете да манипулирате избраните данни, като ги разделите или присъедините. Ще бъдете помолени да разделите още повече избраните изходни данни по време на трансформацията.

Например, ако целият адрес се съхранява в едно голямо текстово поле в системата източник, системата DW може да поиска да раздели адреса на отделни полета като град, държава, пощенски код и т.н. Това е лесно за индексиране и анализ въз основа на всеки компонент поотделно.

Докато обединяването / обединяването на две или повече колони данни се използва широко по време на фазата на трансформация в системата DW. Това не означава обединяване на две полета в едно поле.

Например, ако информацията за даден обект идва от множество източници на данни, тогава събирането на информацията като едно цяло може да се нарече обединяване / обединяване на данните.

# 3) Преобразуване: Извлечените данни от системите източници могат да бъдат в различни формати за всеки тип данни, поради което всички извлечени данни трябва да бъдат преобразувани в стандартизиран формат по време на фазата на трансформация. Един и същ формат е лесен за разбиране и лесен за използване за бизнес решения.

# 4) Обобщение: В някои ситуации DW ще търси обобщени данни, а не подробни данни от ниско ниво от системите източници. Тъй като данните на ниско ниво не са най-подходящи за анализ и заявки от страна на бизнес потребителите.

Например, Данните за продажбите за всяко плащане може да не се изискват от системата DW, ежедневните продажби на странични продукти (или) дневни продажби от магазина са полезни. Следователно обобщаването на данните може да се извърши по време на фазата на трансформация според бизнес изискванията.

# 5) Обогатяване: Когато DW колона се формира чрез комбиниране на една или повече колони от множество записи, обогатяването на данни ще пренареди полетата за по-добър изглед на данните в системата DW.

# 6) Ревизии на формати: Ревизиите на форматите се случват най-често по време на фазата на трансформация. Типът данни и дължината му се ревизират за всяка колона.

Например, колона в една система източник може да бъде числова, а същата колона в друга система източник може да бъде текст. За да се стандартизира това, по време на фазата на трансформация типът данни за тази колона се променя на текст.

# 7) Декодиране на полета: Когато извличате данни от множество системи източници, данните в различни системи могат да бъдат декодирани по различен начин.

Например, една система източник може да представлява статус на клиента като AC, IN и SU. Друга система може да представлява същия статус като 1, 0 и -1.

По време на фазата на трансформация на данни трябва да декодирате такива кодове в правилни стойности, които са разбираеми за бизнес потребителите. Следователно горните кодове могат да бъдат променени на Активен, Неактивен и Спиран.

# 8) Изчислени и получени стойности: Като разглежда системните данни на източника, DW може да съхранява допълнителни данни за колони за изчисленията. Трябва да направите изчисленията въз основа на бизнес логиката, преди да ги съхраните в DW.

# 9) Преобразуване на дата / час: Това е един от ключовите типове данни, върху които да се концентрирате. Форматът за дата / час може да е различен в много източници.

Например, един източник може да съхранява датата като 10 ноември 1997 г. Друг източник може да съхранява същата дата във формат 11/10/1997. Следователно, по време на трансформацията на данните, всички стойности за дата / час трябва да бъдат преобразувани в стандартен формат.

# 10) Дедупликация: В случай, че системата източник има дублирани записи, уверете се, че само един запис е зареден в системата DW.

Диаграма на трансформационния поток:

Как да приложим трансформацията?

В зависимост от сложността на трансформацията на данни можете да използвате ръчни методи, инструменти за трансформация (или) комбинация от двете, което е ефективно.

# 1) Ръчни техники

Ръчните техники са подходящи за малки DW системи. Анализаторите на данни и разработчиците ще създадат програмите и скриптовете за ръчно преобразуване на данните. Този метод се нуждае от подробно тестване за всяка част от кода.

Разходите за поддръжка могат да станат високи поради промените, които се случват в бизнес правилата (или) поради шансовете за получаване на грешки с увеличаването на обемите данни. Първо трябва да се погрижите за метаданните, а също и при всяка промяна, която се случва в правилата за трансформация.

# 2) Инструменти за трансформация

Ако искате да автоматизирате по-голямата част от процеса на трансформация, тогава можете да възприемете инструментите за трансформация в зависимост от бюджета и времевата рамка, налични за проекта. Докато автоматизирате, трябва да отделите качествено време, за да изберете инструментите, да ги конфигурирате, инсталирате и интегрирате със системата DW.

Практически пълната трансформация със самите инструменти не е възможна без ръчна намеса. Но данните, трансформирани от инструментите, със сигурност са ефективни и точни.

За да постигнем това, трябва да въведем правилни параметри, дефиниции на данни и правила в инструмента за трансформация като вход. От дадените входове самият инструмент ще записва метаданните и тези метаданни се добавят към общите метаданни на DW.

код за сортиране на вмъкване c ++

Ако има някакви промени в бизнес правилата, просто въведете тези промени в инструмента, за останалите модификации на трансформацията ще се погрижи самият инструмент. Следователно комбинацията от двата метода е ефективна за използване.

Зареждане на данни

Извлечените и трансформирани данни се зареждат в целевите DW таблици по време на фазата на зареждане на ETL процеса. Бизнесът решава как да се случи процесът на зареждане за всяка таблица.

Процесът на зареждане може да стане по следните начини:

• Първоначално натоварване: Зареждане на данните за попълване на съответните DW таблици за първи път.
• Допълнително натоварване: След като DW таблиците се заредят, останалите текущи промени се прилагат периодично.
• Пълно опресняване: Ако използваните таблици се нуждаят от опресняване, текущите данни от тази таблица се премахват напълно и след това се зареждат отново. Презареждането е подобно на първоначалното натоварване.

Погледнете примера по-долу за по-добро разбиране на процеса на зареждане в ETL:

# 1) По време на първоначалното зареждане данните, които се продават на 3^rdЮни 2007 се зарежда в целевата таблица на DW, защото това са първоначалните данни от горната таблица.

# две) По време на инкременталното зареждане трябва да заредим данните, които се продават след 3^rdЮни 2007 г. Трябва да разгледаме всички записи с датата на продажба, по-голяма от (>) предходната дата за следващия ден. Следователно, на 4^тиЮни 2007 г., вземете всички записи с дата на продажба> 3^rdЮни 2007 г. чрез използване на заявки и зареждане само на тези два записа от горната таблица.

На 5^тиЮни 2007 г., вземете всички записи с дата на продажба> 4^тиЮни 2007 г. и заредете само един запис от горната таблица.

# 3) По време на пълно опресняване, всички горепосочени данни на таблицата се зареждат в DW таблиците наведнъж, независимо от датата на продажба.

Заредените данни се съхраняват в съответните таблици с измерения (или) с факти. Данните могат да бъдат заредени, добавени или обединени в DW таблиците, както следва:

# 4) Зареждане: Данните се зареждат в целевата таблица, ако тя е празна. Ако в таблицата има някои данни, съществуващите данни се премахват и след това се зареждат с новите данни.

Например,

Съществуващи данни от таблицата

Променени данни

Данни след зареждане

# 5) Добавяне: Append е разширение на горния товар, тъй като работи върху вече съществуващи таблици с данни. В целевите таблици Append добавя повече данни към съществуващите данни. Ако се намери дублиран запис с входните данни, той може да бъде добавен като дубликат (или) може да бъде отхвърлен.

Например,

Съществуващи данни от таблицата

Променени данни

Данни след добавяне

# 6) Деструктивно сливане: Тук входящите данни се сравняват със съществуващите целеви данни въз основа на първичния ключ. Ако има съвпадение, тогава съществуващият целеви запис се актуализира. Ако не бъде намерено съвпадение, в целевата таблица се вмъква нов запис.

Например,

Съществуващи данни от таблицата

Променени данни

Данни след конструктивно обединяване

# 7) Конструктивни отива: За разлика от деструктивното сливане, ако има съвпадение със съществуващия запис, той оставя съществуващия запис такъв, какъвто е, и вмъква входящия запис и го маркира като най-новите данни (клеймо за време) по отношение на този първичен ключ.

Например,

Съществуващи данни от таблицата

Променени данни

Данни след конструктивно обединяване

Технически, опресняването е по-лесно от актуализирането на данните. Актуализацията се нуждае от специална стратегия, за да извлече само специфичните промени и да ги приложи към системата DW, докато Refresh просто замества данните. Но опресняването на данните отнема повече време в зависимост от обема данни.

Ако имате такива задачи за опресняване, които да се изпълняват ежедневно, може да се наложи да свалите системата DW, за да заредите данните. Вместо да сваляте цялата DW система, за да зареждате данни всеки път, можете да разделяте и зареждате данни под формата на няколко файла.

Направете бележка за времето на работа за всеки товар, докато тествате. Ако някакви данни не могат да бъдат заредени в системата на DW поради някакви ключови несъответствия и т.н., тогава им дайте начините за обработка на такъв тип данни. Уверете се, че заредените данни са тествани щателно.

Зареждане на диаграма на потока:

Плоски файлове

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

Плоските файлове се използват предимно за следните цели:

# 1) Доставка на изходни данни: Може да има малко системи източници, които няма да позволят на потребителите на DW достъп до техните бази данни поради съображения за сигурност. В такива случаи данните се доставят чрез плоски файлове.

По същия начин данните се доставят от външните доставчици или мейнфрейм системи основно под формата на плоски файлове и те ще бъдат FTP от потребителите на ETL.

# 2) Работни / сценични маси: ETL процесът създава подготвителни таблици за своята вътрешна цел. Свързването на подреждащи таблици с плоските файлове е много по-лесно от СУБД, тъй като четенето и записването във файлова система са по-бързи от вмъкването и заявката на база данни.

# 3) Подготовка за насипно натоварване: След като процесите на извличане и преобразуване са завършени, ако груповото натоварване в потока не се поддържа от инструмента ETL (или) Ако искате да архивирате данните, можете да създадете плосък файл. Тези данни с плосък файл се четат от процесора и зареждат данните в DW системата.

Плоските файлове могат да бъдат създадени по два начина като „Плоски файлове с фиксирана дължина“ и „Разграничени плоски файлове“. Плоските файлове могат да бъдат създадени от програмистите, които работят за системата източник.

Нека видим как обработваме тези плоски файлове:

Обработка на плоски файлове с фиксирана дължина

По принцип плоските файлове са с колони с фиксирана дължина, поради което те също се наричат ​​позиционни плоски файлове. По-долу е разположението на плосък файл, който показва точните полета и техните позиции във файл.

Оформлението съдържа име на полето, дължина, изходна позиция при което започва символът на полето, крайната позиция, при която завършва символът на полето, типът данни като текст, числови и т.н. и коментари, ако има такива.

В зависимост от позициите на данните, екипът за тестване на ETL ще провери точността на данните в плосък файл с фиксирана дължина.

Обработка на разграничени плоски файлове

В разграничените плоски файлове всяко поле с данни е разделено с разделители. Този разделител показва началната и крайната позиция на всяко поле. Като цяло запетая се използва като разделител, но можете да използвате всеки друг символ или набор от символи.

Разграничените файлове могат да бъдат с разширение .CSV (или) .TXT разширение (или) без разширение. Разработчиците, които създават ETL файловете, ще посочат действителния символ на разделителя, за да обработят този файл. В оформлението на файла с разделители първият ред може да представлява имената на колоните.

Подобно на позиционните плоски файлове, екипът за тестване на ETL изрично ще потвърди точността на данните с разделени плоски файлове.

Предназначение на сценичната зона

Основната цел на подреждането е да съхранява временно данни за ETL процеса. Областта на постановка се нарича задна част на системата DW. Архитектът на ETL решава дали да съхранява данни в зоната за подреждане или не.

Постановката ще помогне много бързо да се получат данните от системите източници. В същото време, в случай че системата DW се провали, не е необходимо да стартирате процеса отново, като събирате данни от системите източник, ако данните за промените вече съществуват.

След процеса на извличане на данни, ето причините да се индексират данните в системата DW:

# 1) Възстановимост: Попълнените подреждащи таблици ще се съхраняват в самата база данни на DW (или) те могат да бъдат преместени във файлови системи и могат да се съхраняват отделно. В един момент данните за подреждане могат да действат като данни за възстановяване, ако дадена стъпка на трансформация или зареждане се провали.

Може да има шансове системата източник да е заменила данните, използвани за ETL, поради което запазването на извлечените данни в инсценирането ни помага за справка.

# 2) Архивиране: Трудно е да се направи резервно копие за огромни обеми таблици на базата данни DW. Но архивите са задължителни за всяко възстановяване при бедствие. Следователно, ако разполагате с променителни данни, които са извлечени данни, тогава можете да стартирате заданията за трансформация и зареждане, като по този начин авариралите данни могат да бъдат презаредени.

За да направите резервно копие на промените, често можете да премествате тези данни във файлови системи, така че да е лесно да се компресират и съхраняват във вашата мрежа. Винаги, когато е необходимо, просто декомпресирайте файловете, заредете в подреждащи таблици и изпълнете задачите, за да презаредите DW таблиците.

# 3) Одит: Понякога може да се случи одит на системата ETL, за да се провери връзката между данните между системата източник и целевата система. Одиторите могат да проверят първоначалните входни данни спрямо изходните данни въз основа на правилата за трансформация.

Инсталиращите данни и архивирането им са много полезни тук, дори ако системата източник разполага с данните или не. Тъй като одитът може да се случи по всяко време и за всеки период от настоящите (или) минали данни. Архитектурата на сцената трябва да бъде добре планирана.

Проектиране на сценичната зона

В хранилището за данни данните за промените могат да бъдат проектирани, както следва:

С всяко ново зареждане на данни в подреждащи таблици, съществуващите данни могат да бъдат изтрити (или) поддържани като исторически данни за справка. Ако данните бъдат изтрити, тогава те се наричат ​​„Преходна зона на поставяне“.

Ако данните се поддържат като история, тогава те се наричат ​​„Устойчива зона на подреждане“. Можете също така да проектирате сцена на сцена с комбинация от горните два типа, която е „Хибридна“.

Ето основните правила, които трябва да бъдат известни при проектирането на сценичната зона:

• Само екипът на ETL трябва да има достъп до зоната за подреждане на данни. Заявките за промените в данните са ограничени до други потребители.
• Таблиците в подреждането могат да бъдат добавяни, модифицирани или изпускани от архитекта на данни ETL, без да се включват други потребители. Тъй като сценичната зона не е презентационна зона за генериране на отчети, тя просто действа като работна маса.
• Архитектът ETL трябва да изчисли мярката за съхранение на данни за подреждащата област, за да предостави подробности на администраторите на DBA и OS. Администраторите ще отделят място за организиране на бази данни, файлови системи, директории и др.

Ако променителната област и базата данни DW използват един и същ сървър, тогава можете лесно да преместите данните в системата DW. Ако сървърите са различни, използвайте FTP (или) връзки към база данни.

Поток на ETL процес

Стандартният цикъл на ETL ще премине през следните стъпки на процеса:

• Започнете цикъла ETL, за да стартирате задания последователно.
• Уверете се, че всички метаданни са готови.
• Цикълът ETL помага да се извлекат данните от различни източници.
• Проверете извлечените данни.
• Ако се използват подреждащи таблици, тогава цикълът ETL зарежда данните в подреждане.
• ETL извършва трансформации чрез прилагане на бизнес правила, чрез създаване на агрегати и т.н.
• Ако има някакви грешки, тогава цикълът ETL ще го уведоми под формата на отчети.
• След това цикълът ETL зарежда данни в целевите таблици.
• По-ранните данни, които трябва да се съхраняват за историческа справка, се архивират.
• Останалите данни, които не е необходимо да се съхраняват, се почистват.

Диаграма на процеса на ETL:

Заключение

В този урок научихме за основните концепции на ETL процеса в хранилището на данни. Досега бихте могли да разберете какво е извличане на данни, трансформация на данни, зареждане на данни и поток на процеса на ETL.

Прочетете предстоящия урок, за да научите повече за тестването на хранилището на данни !!

=> Посетете тук за ексклузивната серия за съхранение на данни.

Препоръчително четене

• Урок за тестване на хранилище на данни с примери | Ръководство за тестване на ETL
• 10 най-добри инструмента за картографиране на данни, полезни в процеса на ETL (2021 СПИСЪК)
• Урок за тестване на хранилище на данни за ETL (Пълно ръководство)
• Извличане на данни: процес, техники и основни проблеми при анализа на данните
• Процес на извличане на данни: Включени модели, стъпки и предизвикателства
• Въпроси и отговори за интервю за ETL тестване
• Топ 10 инструменти за тестване на ETL през 2021 г.
• Топ 10 на популярните инструменти за съхранение на данни и технологии за тестване