what is etl extract
Цей поглиблений посібник з процесу 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) Методи логічного вилучення
Вилучення даних у системі сховища даних може бути одноразовим повним завантаженням, яке виконується спочатку (або), це можуть бути додаткові завантаження, що відбуваються щоразу при постійних оновленнях.
як прошити BIOS Windows 10 -
- Повна екстракція: Як випливає з назви, вихідні системні дані повністю витягуються до цільової таблиці. Кожного разу, коли такий вид вилучення завантажує всі поточні дані вихідної системи, не враховуючи останні витягнуті позначки часу. Переважно ви можете використовувати повну витяжку для початкових завантажень або таблиці з меншою кількістю даних.
- Поступова екстракція: Дані, додані / змінені з певної дати, будуть враховуватися для додаткового вилучення. Ця дата є специфічною для бізнесу, оскільки дата останньої вилучення (або) останньої дати замовлення тощо. Ми можемо посилатися на стовпець часової позначки із самої вихідної таблиці (або) може бути створена окрема таблиця для відстеження лише деталей дати вилучення. Посилання на мітку часу є важливим методом під час додаткового вилучення. Логіка без позначки часу може вийти з ладу, якщо таблиця 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 р. Інше джерело може зберігати ту саму дату у форматі 10.11.1997. Отже, під час перетворення даних усі значення дати / часу повинні бути перетворені у стандартний формат.
# 10) Дедуплікація: Якщо у вихідній системі є дублікати записів, переконайтеся, що в систему DW завантажено лише один запис.
Діаграма потоку трансформації:
Як здійснити трансформацію?
Залежно від складності перетворення даних, ви можете використовувати ручні методи, засоби перетворення (або) поєднання обох варіантів, який є ефективним.
# 1) Ручні прийоми
Ручні прийоми є достатніми для малих систем ПЕ. Аналітики даних та розробники створюватимуть програми та сценарії для перетворення даних вручну. Цей метод потребує детального тестування для кожної частини коду.
Витрати на обслуговування можуть стати високими через зміни, що відбуваються у бізнес-правилах (або) через шанси отримати помилки зі збільшенням обсягів даних. Вам слід подбати про метадані спочатку, а також при кожній зміні, що відбувається в правилах трансформації.
# 2) Інструменти трансформації
Якщо ви хочете автоматизувати більшу частину процесу трансформації, тоді ви можете застосувати інструменти трансформації залежно від бюджету та часових рамок, доступних для проекту. Під час автоматизації слід витратити якісний час на вибір інструментів, налаштування, встановлення та інтеграцію їх із системою DW.
Практично повне перетворення самих інструментів неможливе без ручного втручання. Але дані, перетворені інструментами, безумовно, ефективні та точні.
Для цього нам слід ввести належні параметри, визначення даних та правила в інструмент перетворення як вхідні дані. З поданих входів інструмент сам запише метадані, і ці метадані додаються до загальних метаданих DW.
Якщо в бізнес-правилах є якісь зміни, просто введіть ці зміни в інструменті, про решту модифікацій трансформації подбає сам інструмент. Отже, поєднання обох методів ефективно використовувати.
Завантаження даних
Витягнуті та перетворені дані завантажуються у цільові таблиці DW під час фази завантаження процесу ETL. Бізнес вирішує, яким чином повинен відбуватися процес завантаження для кожної таблиці.
Процес завантаження може відбуватися наступними способами:
- Початкове навантаження: Завантаження даних для першого заповнення відповідних таблиць DW.
- Додаткове навантаження: Після завантаження таблиць DW періодично застосовуються інші поточні зміни.
- Повне оновлення: Якщо будь-які використовувані таблиці потребують оновлення, поточні дані з цієї таблиці повністю видаляються, а потім перезавантажуються. Перезавантаження подібне до початкового навантаження.
Подивіться на приклад нижче, щоб краще зрозуміти процес завантаження в ETL:
Ідентифікатор товару | Назва продукту | Дата продажу |
---|---|---|
1 | Граматика | 3 червня 2007 р |
два | Маркер | 3 червня 2007 р |
3 | Задня сумка | 4 червня 2007 р |
4 | Кап | 4 червня 2007 р |
5 | Взуття | 5 червня 2007 р |
# 1) Під час початкового завантаження дані, які продаються на 3рдЧервень 2007 завантажується до цільової таблиці DW, оскільки це вихідні дані з наведеної таблиці.
# два) Під час додаткового завантаження нам потрібно завантажити дані, які продаються через 3рдЧервень 2007 р. Ми повинні врахувати всі записи, дата продажу яких перевищує (>) попередню дату наступного дня. Отже, на 4гоЧервень 2007 року, завантажте всі записи з датою продажу> 3рдЧервень 2007 року, використовуючи запити та завантажуючи лише ці два записи із наведеної таблиці.
5гоЧервень 2007 року, завантажте всі записи з датою продажу> 4гоЧервня 2007 року та завантажте лише один запис із наведеної таблиці.
# 3) Під час повного оновлення всі наведені вище дані таблиці завантажуються в таблиці DW за один раз, незалежно від дати продажу.
Завантажені дані зберігаються у відповідних таблицях вимірів (або) фактів. Дані можна завантажувати, додавати або об’єднувати в таблиці DW наступним чином:
# 4) Навантаження: Дані завантажуються в цільову таблицю, якщо вона порожня. Якщо в таблиці є деякі дані, наявні дані видаляються, а потім завантажуються новими даними.
Наприклад,
Існуючі дані таблиці
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Вести |
Боб | Помічник менеджера |
Рональд | Розробник |
Змінені дані
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Рохан | директор |
Четан | AVP |
В.П. |
Дані після завантаження
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Рохан | директор |
Четан | AVP |
В.П. |
# 5) Додайте: Додаток є продовженням вищезазначеного навантаження, оскільки він працює на вже існуючих таблицях даних. У цільових таблицях додаток додає більше даних до існуючих даних. Якщо з вхідними даними виявлено будь-який дублікат запису, він може бути доданий як дублікат (або) може бути відхилений.
Наприклад,
Існуючі дані таблиці
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Вести |
Змінені дані
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Рохан | директор |
Четан | AVP |
В.П. |
Дані після додавання
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Вести |
Рохан | директор |
Четан | AVP |
В.П. |
# 6) Руйнівне злиття: Тут вхідні дані порівнюються з існуючими цільовими даними на основі первинного ключа. Якщо є збіг, то існуючий цільовий запис оновлюється. Якщо збігу не знайдено, тоді новий запис вставляється в цільову таблицю.
Наприклад,
Існуючі дані таблиці
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Вести |
Змінені дані
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | директор |
Четан | AVP |
В.П. |
Дані після конструктивного злиття
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | директор |
Четан | AVP |
В.П. |
# 7) Конструктивна іде: На відміну від деструктивного злиття, якщо є збіг із існуючим записом, тоді він залишає існуючий запис таким, яким він є, і вставляє вхідний запис і позначає його як останні дані (позначку часу) щодо цього первинного ключа.
Наприклад,
Існуючі дані таблиці
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Вести |
Змінені дані
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | директор |
Четан | AVP |
В.П. |
Дані після конструктивного злиття
ім'я працівника | Роль |
---|---|
Джон | Менеджер |
Ревант | Директор *** |
Ревант | Вести |
Четан | AVP |
В.П. |
Технічно оновити простіше, ніж оновлювати дані. Оновлення потребує спеціальної стратегії для вилучення лише конкретних змін та застосування їх до системи DW, тоді як Refresh просто замінює дані. Але оновлення даних займає більше часу, залежно від обсягу даних.
Якщо у вас є такі завдання оновлення, які потрібно запускати щодня, можливо, вам доведеться збити систему DW для завантаження даних. Замість того, щоб збивати всю систему DW для кожного завантаження даних, ви можете розділити та завантажити дані у вигляді кількох файлів.
Запишіть час роботи кожного навантаження під час тестування. Якщо будь-які дані не можуть завантажитися в систему DW через будь-яке невідповідність ключових даних тощо, надайте їм способи обробки таких даних. Переконайтеся, що завантажені дані ретельно перевірені.
Діаграма завантаження потоку:
Плоскі файли
Плоскі файли широко використовуються для обміну даними між неоднорідними системами, від різних вихідних операційних систем та від різних систем бази даних-джерела до програм зберігання даних. Плоскі файли є найефективнішими та простими в управлінні також для однорідних систем.
Плоскі файли в основному використовуються для таких цілей:
# 1) Доставка вихідних даних: Може бути небагато вихідних систем, які не дозволять користувачам DW отримувати доступ до своїх баз даних із міркувань безпеки. У таких випадках дані доставляються через плоскі файли.
як перетворити char на int в C ++
Подібним чином дані надходять із зовнішніх постачальників або систем мейнфреймів, по суті, у вигляді плоских файлів, і вони будуть передаватися FTP користувачами ETL.
# 2) Робочі / постановочні столи: Процес ETL створює проміжні таблиці для свого внутрішнього призначення. Асоціація індексної таблиці з плоскими файлами набагато простіша, ніж СУБД, оскільки читання та запис у файлову систему відбувається швидше, ніж вставлення та запит бази даних.
# 3) Підготовка до насипного навантаження: Після завершення процесів вилучення та перетворення, якщо масове завантаження в потоці не підтримується інструментом ETL (або). Якщо ви хочете архівувати дані, тоді ви можете створити плоский файл. Дані плоского файлу зчитуються процесором і завантажують дані в систему DW.
Плоскі файли можна створювати двома способами, як “Плоскі файли фіксованої довжини” та “Розділені плоскі файли”. Плоскі файли можуть створювати програмісти, які працюють на вихідну систему.
Давайте подивимося, як ми обробляємо ці плоскі файли:
Обробка плоских файлів із фіксованою довжиною
Загалом, плоскі файли мають стовпці фіксованої довжини, отже, їх також називають позиційними плоскими файлами. Нижче наведено макет плоского файлу, який показує точні поля та їх положення у файлі.
Назва поля | Довжина | Почніть | Кінець | Тип | Коментарі |
---|---|---|---|---|---|
Ім'я | 10 | 1 | 10 | Текст | Ім'я замовника |
По батькові | 5 | одинадцять | п’ятнадцять | Текст | По батькові замовника |
Прізвище | 10 | 16 | 25 | Текст | Прізвище замовника |
Макет містить назва поля, довжина, вихідна позиція з якого починається символ поля, кінцева позиція, на якій закінчується символ поля, тип даних у вигляді тексту, числа тощо тощо та коментарі, якщо такі є.
Залежно від позицій даних, команда тестування ETL перевірить точність даних у плоскому файлі фіксованої довжини.
Обробка розділених плоских файлів
У розділених плоских файлах кожне поле даних відокремлюється розділювачами. Цей роздільник вказує початкове та кінцеве положення кожного поля. Як правило, кома використовується як роздільник, але ви можете використовувати будь-який інший символ або набір символів.
Розділені файли можуть мати розширення .CSV (або) .TXT (або) без розширення. Розробники, які створюють файли ETL, вказуватимуть фактичний символ роздільника для обробки цього файлу. У розділеному макеті файлів перший рядок може представляти імена стовпців.
Так само, як позиційні плоскі файли, команда тестування ETL чітко перевірить точність розділених даних плоских файлів.
Призначення місця постановки
Основною метою проміжної зони є тимчасове зберігання даних для процесу ETL. Область постановки називається закулісною системою DW. Архітектор ETL вирішує, зберігати дані в проміжній зоні чи ні.
Постановка допоможе отримати дані з вихідних систем дуже швидко. У той же час, якщо система DW виходить з ладу, вам не потрібно починати процес заново, збираючи дані з вихідних систем, якщо дані про перехід вже існують.
Після процесу вилучення даних, ось причини для встановлення даних у системі DW:
# 1) Відновлюваність: Заповнені проміжні таблиці зберігатимуться в самій базі даних DW (або) їх можна буде перемістити у файлові системи та зберігати окремо. У певний момент дані проміжного етапу можуть діяти як дані відновлення, якщо будь-який крок перетворення або завантаження не вдається.
Можливо, є ймовірність того, що система-джерело перезаписала дані, що використовуються для ETL, отже, збереження видобутих даних у проміжних етапах допомагає нам для будь-якого посилання.
# 2) Резервне копіювання: Важко взяти назад величезні обсяги таблиць баз даних DW. Але резервне копіювання є обов’язковим для будь-якого аварійного відновлення. Отже, якщо у вас є проміжні дані, які витягуються, ви можете запустити завдання для перетворення та завантаження, тим самим розбиті дані можна перезавантажити.
Щоб створити резервну копію проміжних даних, ви можете часто переміщувати проміжні дані до файлових систем, щоб їх було легко стиснути та зберегти у вашій мережі. Щоразу, коли потрібно просто розпакувати файли, завантажте їх у проміжні таблиці та запустіть завдання, щоб перезавантажити таблиці DW.
# 3) Аудит: Іноді може відбутися аудит системи ETL, щоб перевірити зв'язок даних між вихідною системою та цільовою системою. Аудитори можуть перевірити вихідні вихідні дані щодо вихідних даних на основі правил трансформації.
Індекційні дані та їх резервне копіювання тут дуже корисні, навіть якщо вихідна система має доступні дані чи ні. Оскільки аудит може відбуватися в будь-який час і за будь-який період теперішніх (або) минулих даних. Архітектура місця постановки повинна бути добре спланована.
Проектування сценографії
У сховищі даних дані променевої області можуть бути спроектовані таким чином:
З кожним новим завантаженням даних у проміжні таблиці існуючі дані можуть бути видалені (або) збережені як історичні дані для довідки. Якщо дані видаляються, то це називається «Перехідна зона проходження».
Якщо дані зберігаються як історія, то вони називаються «постійною промежуточною зоною». Ви також можете спроектувати зону постановки за допомогою комбінації двох вищевказаних типів, яка є “гібридною”.
Ось основні правила, які слід знати під час проектування місця постановки:
- Тільки команда ETL повинна мати доступ до зони індексування даних. Запити про проміжні дані обмежені для інших користувачів.
- Таблиці в проміжній області можуть бути додані, змінені або скинуті архітектором даних ETL без залучення інших користувачів. Оскільки інсценізаційна площа не є областю презентації для створення звітів, вона просто виконує роль робочого столу.
- Архітектор ETL повинен оцінити міру зберігання даних проміжної області, щоб надати деталі адміністраторам DBA та ОС. Адміністратори виділять місце для індексування баз даних, файлових систем, каталогів тощо.
Якщо область проходження та база даних DW використовують один і той же сервер, ви можете легко перемістити дані до системи DW. Якщо сервери різні, використовуйте посилання на базу даних FTP (або).
Потік процесу ETL
Стандартний цикл ETL пройде наступні етапи процесу:
- Почніть цикл ETL, щоб виконувати завдання послідовно.
- Переконайтесь, що всі метадані готові.
- Цикл ETL допомагає отримувати дані з різних джерел.
- Перевірте витягнуті дані.
- Якщо використовуються проміжні таблиці, тоді цикл ETL завантажує дані в проміжні.
- ETL здійснює перетворення, застосовуючи бізнес-правила, створюючи агрегати тощо
- Якщо є якісь збої, то цикл ETL повідомить про це у формі звітів.
- Потім цикл ETL завантажує дані в цільові таблиці.
- Раніше дані, які потрібно зберігати для історичної довідки, архівуються.
- Решта даних, які не потрібно зберігати, очищається.
Діаграма потоку процесів ETL:
Висновок
У цьому підручнику ми дізналися про основні концепції процесу ETL у сховищі даних. На даний момент ви вже мали змогу зрозуміти, що таке вилучення даних, перетворення даних, завантаження даних і потік процесу ETL.
Прочитайте майбутній підручник, щоб дізнатися більше про тестування сховища даних !!
=> Завітайте сюди, щоб отримати ексклюзивну серію зберігання даних.
Рекомендована література
- Підручник з тестування сховища даних із прикладами | Посібник з тестування ETL
- 10 найкращих інструментів картографування даних, корисних у процесі ETL (2021 СПИСОК)
- Підручник з тестування сховища даних ETL (повний посібник)
- Видобуток даних: процес, методи та основні проблеми аналізу даних
- Процес видобутку даних: задіяні моделі, етапи та виклики
- Запитання та відповіді на інтерв’ю для тестування ETL
- 10 найкращих засобів тестування ETL у 2021 році
- Топ-10 популярних засобів зберігання даних та технологій тестування