Розширення сховища даних: Частина 3. Використання технології великих даних для створення активного архіву

1. Серія контенту:
2. Цей контент є частиною серії: Розширення сховища даних
3. Архівування інформації зі сховища даних
4. Малюнок 1. Життєвий цикл даних в сховищі
5. Фактори, що впливають на вибір даних, що підлягають збереженню
6. Типова реалізація архіву сховища даних
7. Малюнок 2. Традиційне архівування даних з корпоративного сховища даних
8. Малюнок 3. Типова реалізація архіву сховища даних
9. Малюнок 4. Архівування з використанням платформи великих даних
10. рівень обчислень
11. рівень запитів
12. інфраструктура
13. Розміщення даних
14. Малюнок 5. Макет архівних даних на платформі великих даних
15. Малюнок 6. Розміщення елементів даних в активному архіві
16. Малюнок 7. Альтернативний макет архівних даних на платформі великих даних
17. Мови запитів високого рівня (Hive, Pig і Jaql)
18. SQOOP
19. Інтеграція ETL-інструментів з великими даними
20. Flume
21. IBM Big SQL і Cloudera Impala
22. IBM BigSheets
23. Архітектура активного архіву
24. Малюнок 8. Архітектура активного архіву
25. Малюнок 9. Клієнтські додатки, що використовують активний архів
26. Малюнок 10. Процес архівування
27. Малюнок 11. Процес відновлення
28. Ресурси для скачування

Розширення сховища даних

Серія контенту:

Цей контент є частиною # з серії # статей: Розширення сховища даних

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Расширение+хранилища+данных

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Розширення сховища даних

Слідкуйте за виходом нових статей цієї серії.

У першій частині цієї серії статей аналізується стан справ у сфері сховищ даних і пропонуються різні підходи до розширення сховища даних. У другій частині йдеться про те, як використовувати платформу великих даних для збору даних для сховища даних. Ця стаття присвячена побудові архіву, до якого можна звертатися з платформи великих даних. У четвертій частині буде описано використання платформи великих даних для дослідження даних.

В останні десятиліття підприємства займалися побудовою сховищ даних. Після введення в експлуатацію типове корпоративне сховище даних стає основою інформаційної магістраллю компанії. Сьогодні організації створюють більше даних завдяки розширенню можливостей щодо збору інформації з різних джерел. Бази даних, ETL-інструменти і засоби звітності працюють з великими обсягами даних. Але темпи зростання обсягів даних в складних сховищах даних, які обслуговують безліч підрозділів, змушують архівувати рідко використовуються дані і тримати в сховище тільки ті дані, які активно використовуються.

Стандартним засобом аналізу великих обсягів даних швидко стає Hadoop. Високорівневі мови запитів і засоби розробки спрощують постановку і рішення задач MapReduce. А такі механізми, як драйвери ODBC і JDBC, забезпечують більш повну інтеграцію з існуючими інструментами.

Архівування інформації зі сховища даних

Архівування сховища даних - це процес переміщення даних, які навряд чи знадобляться для роботи, зі сховища даних на носій, де їх можна зберігати тривалий час і звідки їх можна при необхідності витягувати. Вимоги, що пред'являються до архіву сховища даних, впливають на проект сховища даних, і їх потрібно визначити на ранньому етапі проектування і включити до складу бізнес-вимог до сховища даних. У число цих бізнес-вимог входять:

• механізм вибору критеріїв визначення записів, які можна перемістити в архів;
• формат і спосіб зберігання архівних даних;
• метод вказівки ймовірності збереження і терміни отримання даних.

Малюнок 1. Життєвий цикл даних в сховищі

Після архівування даних вони стають недоступними для запитів до тих пір, поки не будуть відновлені з архіву і повернуті в сховище даних. З метою забезпечення безперервності бізнесу і підготовки до аварійних ситуацій організації часто зберігають резервні копії даних в різних офісах або центрах обробки даних. Так як для отримання даних потрібно координація між декількома підрозділами, цей процес може бути тривалим.

Фактори, що впливають на вибір даних, що підлягають збереженню

Якщо дані потрібні організації для ведення бізнесу, їх необхідно зберегти. У деяких випадках зберігаються історичні дані для порівняння історичних тенденцій з поточними подіями. Часто фахівці аналізують існуючі дані для пошуку ідей, які могли б відкрити нові можливості для розвитку бізнесу. Аналітично орієнтовані компанії мають підвищену потребу в довгостроковому зберіганні даних.

Зростаюча кількість нормативних вимог і необхідність для організацій дотримуватися їх також впливає на вирішення питання про те, які дані слід зберігати. Терміни зберігання даних встановлюються такими нормативними актами, як закон Сарбейнса-Окслі, HIPAA і Базель II.

Організації зберігають все більше даних на все більш тривалі періоди часу. Необхідність зберігати ці додаткові дані створює потребу в нових правилах, процедурах, методах і програмному забезпеченні для підтримки зберігання, управління і доступу до архівних даних.

Типова реалізація архіву сховища даних

У сховищах даних, призначених для зберігання великих обсягів даних, відомості рівня транзакцій зазвичай зберігаються протягом декількох років. Залежно від вимог дані старше двох-трьох років переміщаються на архівний носій, такий як магнітна стрічка. Зведені статистичні дані залишаються в сховище даних для історичного аналізу. Однак після архівування даних відомості рівня транзакцій доводиться відновлювати в сховище даних, якщо виникає необхідність аналізу історичних даних. Малюнок 2 ілюструє типовий процес архівування сховища даних.

Малюнок 2. Традиційне архівування даних з корпоративного сховища даних

Основні СУБД підтримують секціонування даних, яке відіграє важливу роль у реалізації стратегії резервного копіювання в сховище даних. Зазвичай дані в сховище даних секціонуючою за часом, яке служить критерієм відбору записів для архівування. Традиційні рішення архівування спираються на передові методи резервного копіювання, такі як інкрементне резервне копіювання і можливість переводити розділи в автономний режим з метою резервного копіювання, не впливаючи на операції.

При будь-якої реалізації стратегії архівування сховища даних необхідно розглянути вимоги, що пред'являються до резервного копіювання і відновлення. При архівації в автономному режимі додатковий простір зберігання, показане на малюнку 3, не підходить для ситуацій, коли потрібно відновлювати докладні відомості для історичного аналізу. Так як дані з автономного сховища неможливо швидко витягти, користувачам доводиться виключати детальну історію з аналізу або робити оцінки, базуючись на статистичних даних.

Малюнок 3. Типова реалізація архіву сховища даних

Реалізація архіву сховища даних може бути ускладнена рядом факторів:

• структура та схема сховища даних можуть змінюватися в залежності від бізнес-вимог. Зміна схеми сховища даних необхідно враховувати для підтримки сумісності функцій резервного копіювання та відновлення. У складних сховищах даних такі зміни можуть викликати проблеми;
• автономні носії архіву даних, такі як магнітні стрічки і диски, схильні до відмов з плином часу, і для гарантованої доступності даних необхідно проводити планові модельні випробування;
• для операцій відновлення, як правило, потрібно координація різних підрозділів і людей, щоб мінімізувати простої і використовувати зовнішнє зберігання носіїв резервних копій;
• відновлення історичних даних може порушити нормальну роботу сховища і вимагає ретельного планування.

Резервні копії даних, що зберігаються на магнітній стрічці, схильні до впливу змін форматів магнітної стрічки і вимог переходу на найсучасніший формат.

Apache Hadoop дозволяє реалізувати активний архів, до якого можна звертатися із запитами. Hadoop особливо підходить для ситуацій, коли необхідно на час зберегти великий обсяг даних. Як показано на малюнку 4, платформа великих даних охоплює рівні зберігання, обчислень і запитів, що дозволяє реалізувати активний архів.

Малюнок 4. Архівування з використанням платформи великих даних

рівень зберігання

Історичні дані, що містяться в сховище даних у відповідності з політикою архівування, можна перемістити на рівень зберігання платформи великих даних. Рівень зберігання грає роль носія архіву для сховища даних. Розподілена файлова система Hadoop (Hadoop Distributed File System - HDFS), яка служить основою для побудови більшості платформ великих даних, ідеально підходить для зберігання великих обсягів даних, розподілених за стандартними вузлів. HDFS - це система з одноразовою записом, а історичні дані зазвичай архівуються один раз і більше ніколи не перезаписувати. Такі особливості HDFS, як масштабованість, відмовостійкість і можливість доступу до потоковим даними, роблять її придатною для активних архівів.

рівень обчислень

Будь-які обчислення або обробка, які повинні проводитися в активному архіві, повинні забезпечувати можливість роботи з великими обсягами даних. Середа MapReduce дозволяє розподіляти обчислення по великому набору стандартних вузлів, розташованих поверх розподіленої файлової системи, такої як HDFS. На етапі map вхідні дані обробляються елемент за елементом і перетворюються в проміжний набір даних. На етапі reduce дані перетворюються в набір зведених даних. Завдання MapReduce можна писати на різних мовах програмування, включаючи Java ™ та Python. Інші мови сценаріїв і запитів високого рівня полегшують обчислення в середовищі MapReduce.

рівень запитів

Активний архів повинен дозволяти легко запитувати дані і робити обчислення, агрегування та інші типові SQL-операції. Хоча на платформі великих даних всі операції повинні виконуватися як завдання MapReduce, код завдань MapReduce, написаний на таких мовах програмування, як Java, важкий для розуміння і менш зручний. Рівень запитів дозволяє описати операції аналізу, завантаження і збереження даних для розподіленої файлової системи. Він організовує обробку завдань на платформі великих даних. Для зручного доступу до даних з активного архіву на платформі великих даних можна використовувати багато комерційні продукти і продукти з відкритим вихідним кодом, такі як Hive, Pig і Jaql.

Сховище даних розробляється на основі бізнес-вимог, а активний архів служить розширенням цього сховища. Активний архів повинен надавати спосіб звернення до даних і їх вилучення з допомогою семантики, відповідної сховища даних. Інформація метаданих, розроблена для сховища, повинна застосовуватися і до активного архіву, щоб користувачі, знайомі зі сховищем, могли без особливих труднощів освоїти активний архів. Ретельно виберіть інфраструктуру, макет даних і систему записів активного архіву.

інфраструктура

Якщо організація хоче побудувати активний архів в якості першого кроку до реалізації платформи великих даних, їй слід вирішити, чи створювати їй необхідні для цього служби або придбати їх. У багатьох випадках активний архів - лише частина ширшої стратегії аналізу даних. При створенні платформи великих даних з нуля потрібні досвід і інфраструктура для побудови масштабованої і розширюється платформи, здатної задовольнити поточні потреби і допускає нарощування для задоволення потреб в майбутньому. Хоча системи на базі Hadoop можуть працювати на стандартному обладнанні, в рішення великих даних входять програмне забезпечення системного управління, мережеві можливості і додаткові ресурси, необхідні для аналітичної обробки. Програмно-апаратні комплекси для роботи з великими даними, такі як IBM® PureData ™ Appliance for Hadoop, надають інфраструктуру великих даних, здатну задовольнити нинішні і майбутні потреби підприємства.

Інфраструктура активного архіву на базі Hadoop повинна бути співмірна з обсягами збережених даних. Проаналізуйте коефіцієнт повторення в середовищі Hadoop і ефективність, якої можна досягти шляхом стиснення даних в Hadoop. Коефіцієнт повторення - це число копій кожного зрізу даних. Залежно від кількості вузлів даних може знадобитися один або декілька вузлів управління. Кількість стійок, необхідних для вузлів даних, також є важливим фактором аналізу в ході проектування інфраструктури.

Розміщення даних

Одне з найважливіших проектних рішень - модель розміщення даних на платформі великих даних. Так як активний архів повинен зберігати величезний обсяг даних, важливу роль відіграє вибір відповідної структури організації даних. Ця структура впливає на продуктивність обробки запитів і на те, як виконуються обчислення над даними в активному архіві. Структура повинна бути масштабованої, щоб дані можна було додавати зі сховища даних поступово, у міру їх готовності до архівування.

Як показано на малюнку 5, схему секціонування сховища даних можна використовувати і для організації структури папок розподіленої файлової системи. Для організації вкладених папок можна застосувати будь-який ключ розподілу або кластеризації, який використовується для основних таблиць фактів. Наприклад, сховище даних постачальника послуг зв'язку зберігає записи даних викликів, розподілені по місяцях. Якщо добовий обсяг записів обчислюється мільйонами, то активний архів може використовувати місяць в якості основної папки, у вкладених папках якій зберігаються дані по окремих днях.

Малюнок 5. Макет архівних даних на платформі великих даних

система записів

Як показано на малюнку 6, для активного архіву дані зі сховища даних необхідно перемістити в неструктуровані файли на платформі великих даних. Для опису бізнес-процесу, що охоплює кілька таблиць, система записів сховища даних посилається на комбінацію елементів даних. Щоб активний архів міг служити тієї ж мети для історичних даних, система записів сховища даних перетвориться в систему записів Hadoop. Якщо активний архів призначений тільки для зберігання історичних даних в аналітичних цілях і функція відновлення не потрібно, то система записів Hadoop можна спроектувати відповідно до встановлених вимог без оглядки на систему записів сховища даних. Наприклад, в систему записів активного архіву Hadoop можна об'єднати елементи даних, зібрані з різних таблиць сховища даних.

Малюнок 6. Розміщення елементів даних в активному архіві

Якщо потрібне відновлення даних, то в систему великих даних необхідно переміщати все елементи даних, присутні в сховище даних. Система записів Hadoop може охоплювати кілька файлів, а для запитів на платформі великих даних можуть знадобитися операції, аналогічні інструкціям злиття SQL. В цьому випадку при операціях відновлення під час операцій з архівом необхідно забезпечувати перетворення з системи запису сховища даних в систему Hadoop (і навпаки).

Малюнок 7. Альтернативний макет архівних даних на платформі великих даних

Платформа великих даних надає безліч інструментів, що підтримують створення активного архіву. Інструменти з відкритим вихідним кодом і комерційні продукти підтримують переміщення даних в активний архів і з нього. Для управління активним архівом можна використовувати найрізноманітніші інструменти, починаючи з драйверів ODBC і JDBC для підключення клієнтів, інструментів імпорту та експорту даних, мов сценаріїв і інших допоміжних утиліт. Методи, доступні в цих інструментах, можна використовувати для реалізації ефективної системи архіву.

Мови запитів високого рівня (Hive, Pig і Jaql)

Одним з важливих аспектів активного архіву є необхідність запитувати дані, що зберігаються в архіві, для цілей аналізу даних. Hive - це додаток для зберігання даних з використанням мови запитів HQL, концептуально подібного SQL. Pig - це великомасштабна система обробки даних, в якій можна писати конвеєри обробки даних на мові Pig Latin. Jaql розроблений компанією IBM головним чином для даних JSON, але може використовуватися і для аналізу структурованих і неструктурованих даних, що зберігаються в файлової системі HDFS. У кожному разі код, написаний на мові високого рівня, компілюється внутрішніми компиляторами в код MapReduce. Цей підхід позбавляє користувачів від необхідності вивчати функції MapReduce.

SQOOP

SQOOP - це проект Apache з відкритим вихідним кодом, орієнтований на імпорт великих обсягів даних з реляційних баз даних в файлову систему HDFS. SQOOP може виконувати завдання по завантаженню даних в кластер MapReduce і використовувати властивості відмовостійкості і паралельних обчислень. SQOOP можна застосовувати для підключення до будь-якої реляційної базі даних, що підтримує драйвери JDBC, і вилучення даних за допомогою стандартних SQL-запитів ANSI. Він може отримувати дані для подальшого переміщення на платформу великих даних. SQOOP також може завантажувати дані в HIVE або HBASE для подальшого аналізу.

Великі табліці можна розділіті на кілька завдання с помощью декількох завдання mapper, вікорістовуючі стовпці бази даних. Для економії місця витягнуті дані стискаються і записуються в файлову систему HDFS.

Інтеграція ETL-інструментів з великими даними

Всі основні комерційні ETL-інструменти надають можливості для інтеграції з платформою великих даних. IBM InfoSphere® DataStage® містить компонент Big Data File Stage (BDFS), який підключається до Hadoop і зчитує або записує дані прямо в файлову систему HDFS. Перевага використання ETL-інструментів для експорту та імпорту даних полягає в можливості інтегрувати процес архівування та відновлення з ETL-процесом і використовувати функції масштабування DataStage. У число цих функцій входить можливість секціонування даних і масштабування обробки за допомогою дизайну на основі призначеного для користувача інтерфейсу. Так як архівування та відновлення являє собою періодичний процес, оцініть, як сильно він вплине на існуючі ETL-процеси і продуктивність ETL. Один з недоліків використання ETL-інструментів для абот з активним архівом - необхідність передачі великого обсягу даних по мережі, так як ETL-інструменти зазвичай працюють в інший мережевої інфраструктури.

Flume

Flume - це що володіє високою надійністю і готовністю сервіс Apache з відкритим вихідним кодом для ефективного збору, об'єднання і переміщення великих обсягів журнальних даних. Flume використовується для збору даних з різних джерел, таких як JMS, Solr і журнальні джерела даних. Остання версія цього інструменту, Flume-Next Generation (Flume-Ng), має трирівневий дизайн: агент, колектор і сховище. Для збору даних з реляційних таблиці використовуються агенти Flume, що забезпечують процес архівування, а для процесу відновлення можна створити неструктуровані файли, що завантажуються завантажувачами бази даних. Ці функції доступні і в SQOOP, який частіше використовується для читання або запису даних з реляційних баз даних. Для процесу архівування можна застосовувати різні агенти для збору різних таблиць з метою розпаралелювання в Flume робочого навантаження на основі подій.

В процесі відновлення агенти отримують дані з HDFS через колектори. Агенти можуть відправляти дані через колектори для створення неформатованих файлів, які можна використовувати для повернення даних в таблиці сховища даних.

IBM Big SQL і Cloudera Impala

IBM Big SQL і Cloudera Impala - це механізми запитів, які реалізують SQL-подібні запити до даних, що зберігаються в Apache Hive і HBase. Ці інструменти служать важливими компонентами активного архіву, так як дозволяють отримувати дані їх сховища даних за допомогою клієнтських інструментів користувачів. Обидва ці механізми містять коннектори ODBC і JDBC і створюють код SQL, який відповідає стандартам ANSI, дозволяючи інструментам бізнес-аналізу підключатися до активного архіву та видавати дані для звітів. Користувачі сховища даних можуть писати SQL-подібні запити, які переводяться внутрішніми механізмами в завдання MapReduce для використання MPP-можливостей платформи великих даних. Ці механізми також підтримують точкові запити, які виконуються з короткою затримкою і можуть швидко повертати результати.

IBM BigSheets

IBM BigSheets, що входить до складу IBM InfoSphere BigInsights ™, є табличний інтерфейс для полегшення переміщення, вилучення та візуалізації даних. BigSheets можна використовувати замість традиційних інструментів бізнес-аналізу для простого звернення до активного архіву. BigSheets дозволяє створювати набори даних шляхом додавання нових стовпців, що визначають формули, як в електронній таблиці. З його допомогою можна виконувати операції злиття і об'єднання даних без написання коду на SQL або іншими мовами сценаріїв. BigSheets включає в себе діаграми візуалізації, які можна використовувати "як є", без настройки.

Архітектура активного архіву

Як показано на малюнку 8, активний архів взаємодіє з іншими компонентами і процесами, в тому числі:

• з клієнтськими додатками;
• з процесом архівування;
• з процесом відновлення.

Малюнок 8. Архітектура активного архіву

Клієнтські програми для активного архіву - це перш за все додатки, які звертаються до системи великих даних для отримання даних в аналітичні системи, такі як інструменти бізнес-аналізу (BI) для цілей звітності. Як показано на малюнку 9, більшість інструментів BI дозволяє використовувати драйвери JDBC / ODBC для відправки SQL-сумісних запитів, які можна перетворити в функції MapReduce. Результати повертаються в систему BI. Аналітики можуть використовувати методи MapReduce або мови запитів високого рівня, такі як Hive або Pig, для аналізу історичних тенденцій в активному архіві. Ці інструменти також дозволяють переміщати дані з активного архіву в інші системи, що дає можливість об'єднувати дані з метою аналізу.

Малюнок 9. Клієнтські додатки, що використовують активний архів

процес архівування

Процес архівування повинен виявляти і переміщати все записи зі сховища даних відповідно до встановлених вимог і допоміжною інформацією. Як показано на малюнку 10, система записів сховища даних перетвориться в систему записів Hadoop. Після того як запис виявилася в системі великих даних і стала доступною в активному архіві, вона позначається як готова до видалення. Процес архівування повинен гарантувати, що записи, що архівуються в кожній окремій партії, додаються в існуючого набору даних відповідно до проектного макетом даних. Процес архівування повинен забезпечувати доступність даних для клієнтських додатків за допомогою запитів. Як правило, процес архівування планується і виконується з певною періодичністю.

Малюнок 10. Процес архівування

процес відновлення

Процес відновлення - це процес, майже зворотний процесу архівування. Як показано на малюнку 11, процес відновлення зчитує записи з платформи великих даних і ідентифікує їх, відновлюючи відповідно до встановлених вимог. Система записів Hadoop перетворюється в систему записів сховища даних. На відміну від операцій архівування, операції відновлення можуть бути складними. Операції запису, які повертають дані в сховищі, повинні враховувати зовнішні ключі, індекси, сурогатні ключі і інші подібні фактори. Операції повинні виконуватися в правильній послідовності. У дизайн процесів архівування та відновлення повинні входити роботи з очистки сховища даних і активного архіву, щоб майбутні операції архівування та відновлення працювали правильно. Хоча процес відновлення відбувається тільки на вимогу, потрібно виконувати часті тестові прогони, щоб бути впевненим у правильності функціонування операції відновлення при поточному стані сховища даних.

Малюнок 11. Процес відновлення

Висновок

Робота з історичними даними з метою інтелектуального аналізу і регулювання - важлива частина дизайну сховища даних. У великих сховищах даних історичні дані - це завдання великих даних, яка ідеально відповідає характеристикам систем, для яких призначений Hadoop. Платформи великих даних, засновані на Hadoop, пропонують економічний підхід до створення активних архівів, доступних для використання клієнтськими додатками. У четвертій частині цієї серії статей розповідається про те, як використовувати технології великих даних для початкового дослідження даних.

Ресурси для скачування

Схожі тими

• Оригінал статті: Data warehouse augmentation, Part 3: Use big data technology for an active archive .
• Побудова платформи великих даних з метою аналізу даних : Огляд комплексних архітектурних рішень і стратегій платформи великих даних.
• Розширення сховища великих даних від IBM : Відеоматеріал, який ілюструє різні сценарії розширення сховища даних.
• Навіщо IBM великі дані : Опис програмного забезпечення, що становить платформу великих даних IBM.
• Архітектура і моделі великих даних (Швета Джайн, Шрікант Л. Хупарт, Дівакар Мисора, IBM developerWorks, вересень 2013): опис різних архітектурних моделей великих даних.
• Нові варіанти використання великих даних: перетворення, активний архів і дослідження - Амр Авадалла: точка зору компанії Clouderra на розширення сховища даних і активні архіви.
• Книги IBM Redbook: Продуктивність і ємність систем великих даних : Огляд і аналіз переваг технології великих даних; розглядаються основні фактори успішного управління великими даними і нові технології, які допомагають вирішувати завдання великих даних.
• Використовуйте можливості великих даних: IBM Big Data Platform (Пол C. Зікопулос, Дірк Дероос, Крішнан Парасураман, Томас Дойч, Девід Корріган, Джеймс Джілс): огляд платформи IBM Big Data і способів її застосування для вирішення бізнес-завдань.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів