├── BigData.md ├── CODE_OF_CONDUCT.md ├── Python.md ├── README.md ├── SQL.md ├── SystemDesign.md └── sd-im ├── CPUUtilization.png ├── DiskSpaceUtilization.png ├── NetworkUtilization.png └── RAMUtilization.png /BigData.md: -------------------------------------------------------------------------------- 1 | # Big Data 2 | 3 | 4 | * [Что такое DWH](#dwh) 5 | * [Data Lake](#data-lake) 6 | * [Витрины данных](#data-marts) 7 | * [ETL и ETL-запросы](#ETL) 8 | * [Разработка ETL-процесса](#ETL-process) 9 | * [Элементы ETL-процесса](#Elements-of-the-ETL-process) 10 | * [Что такое Hadoop?](#hadoop) 11 | * [Data Vault](#Data-Vault) 12 | * [Apache Kafka](#Apache-Kafka) 13 | * [Greenplum](#Greenplum) 14 | * [Распределенная файловая система HDFS](#distributed-file-system-HDFS) 15 | * [Архитектура HDFS](#HDFS-architecture) 16 | * [Shell-команды](#Shell-commands) 17 | * [Java API](#Java_API1) 18 | * [MapReduce](#MapReduce) 19 | * [Фреймворк MapReduce](#MapReduce-framework) 20 | * [Hadoop Streaming](#Hadoop-Streaming) 21 | 30 | * [Pig и Hive](#Pig-and-Hive) 31 | * [Pig](#Pig) 32 | * [Hive](#Hive) 33 | * [NoSQL базы данных: HBase и Cassandra](#HBase-and-Cassandra) 34 | * [Способы хранения данных](#Data-storage-methods) 35 | * [NoSQL](#NoSQL) 36 | * [Введение в HBase](#Introduction-to-HBase) 37 | * [Архитектура HBase](#HBase-Architecture) 38 | 39 | * [Spark](#Spark) 40 | * [Основные понятия Spark](#Basic-concepts-of-Spark) 41 | * [Операторы Spark](#Spark-Operators) 42 | * [Чем отличается PostgreSQL от ClickHouse?](#PostgreSQL-vs-ClickHouse) 43 | * [Зачем в ClickHouse на движке MergeTree прописывается ORDER BY?](#Why-ORDER-BY-is-required-in-MergeTree-of-ClickHouse) 44 | * [Как работает запрос на джойн таблиц в ClickHouse, если выполнять по ключу, который отсортирован и не отсортирован?](#How-does-ClickHouse-handle-joins-on-sorted-and-unsorted-keys) 45 | * [Какие существуют архитектуры DWH?](#DWH-architectures) 46 | * [В чём преимущество Data Vault, если у нас происходят частые изменения на источнике?](#Advantages-of-Data-Vault-with-frequent-source-changes) 47 | * [ETL и ELT: разница, преимущества и недостатки.](#ETL-vs-ELT) 48 | * [Что выбрать, если меняется структура данных на источнике?](#What-to-choose-if-data-structure-changes-at-source) 49 | * [Apache Flink](#Apache-Flink) 50 | * [Чем Apache Flink отличается от Apache Spark?](#Flink-vs-Spark) 51 | * [Какие преимущества реального времени предлагает Flink по сравнению с пакетной обработкой?](#Real-time-advantages-of-Flink-over-batch-processing) 52 | * [Обработка потоков данных](#Stream-Processing) 53 | * [Что такое обработка потоков данных и какие задачи она решает?](#What-is-stream-processing-and-what-problems-does-it-solve) 54 | * [Какие паттерны обработки потоков данных вы знаете?](#Stream-processing-patterns) 55 | * [Lambda и Kappa архитектуры](#Lambda-and-Kappa-Architectures) 56 | * [В чем разница между Lambda и Kappa архитектурами?](#Difference-between-Lambda-and-Kappa-Architectures) 57 | * [Приведите примеры использования Lambda и Kappa архитектур.](#Examples-of-Lambda-and-Kappa-Architectures) 58 | * [Microservices and Big Data](#Microservices-and-Big-Data) 59 | * [Как микросервисы интегрируются с большими данными?](#How-do-microservices-integrate-with-big-data) 60 | * [Какие проблемы масштабируемости и управления могут возникнуть при использовании микросервисов для больших данных?](#Scalability-and-management-issues-with-microservices-for-big-data) 61 | * [Data Mesh](#Data-Mesh) 62 | * [Что такое Data Mesh и каковы его ключевые принципы?](#What-is-Data-Mesh-and-what-are-its-core-principles) 63 | * [Как Data Mesh способствует децентрализации управления данными?](#How-Data-Mesh-facilitates-decentralized-data-management) 64 | * [Security in Big Data](#Security-in-Big-Data) 65 | * [Какие основные аспекты безопасности необходимо учитывать при работе с большими данными?](#Key-security-aspects-in-big-data) 66 | * [Какие механизмы обеспечения безопасности данных используются в Hadoop и Spark?](#Data-security-mechanisms-in-Hadoop-and-Spark) 67 | * [Data Governance](#Data-Governance) 68 | * [Что такое управление данными (Data Governance) и почему это важно для больших данных?](#What-is-Data-Governance-and-why-is-it-important-for-big-data) 69 | * [Какие инструменты и технологии используются для управления качеством данных?](#Tools-and-technologies-for-data-quality-management) 70 | * [Machine Learning with Big Data](#Machine-Learning-with-Big-Data) 71 | * [Как интегрировать машинное обучение с большими данными?](#Integrating-machine-learning-with-big-data) 72 | * [Какие фреймворки и библиотеки чаще всего используются для машинного обучения на больших данных?](#Frameworks-and-libraries-for-machine-learning-on-big-data) 73 | * [Cloud Solutions for Big Data](#Cloud-Solutions-for-Big-Data) 74 | * [Какие облачные решения существуют для работы с большими данными?](#Cloud-solutions-for-big-data) 75 | * [В чем преимущества и недостатки использования облачных платформ для обработки и хранения больших данных?](#Advantages-and-disadvantages-of-using-cloud-platforms-for-big-data) 76 | 77 | 78 | # Что такое DWH 79 | 80 | 81 | DWH — Data warehouse — Корпоративное хранилище данных (КХД) — склад всех нужных и важных для принятия решений данных компании. 82 | 83 | Потребность в КХД сформировалась примерно в 90-х годах прошлого века, когда в секторе enterprise стали активно использоваться разные информационные системы для учета множества бизнес-показателей. Каждое такое приложение успешно решало задачу автоматизации локального производственного процесса, например, выполнение бухгалтерских расчетов, проведение транзакций, HR-аналитика и т.д. 84 | 85 | При этом схемы представления (модели) справочных и транзакционных данных в одной системе могут кардинально отличаться от другой, что влечет расхождение информации. Кроме того, большое разнообразие моделей данных затрудняет получение консолидированной отчетности, когда нужна целостная картина из всех прикладных систем. Поэтому возникли корпоративные хранилища данных (Data Warehouse, DWH) – предметно-ориентированные базы данных для консолидированной подготовки отчётов, интегрированного бизнес-анализа и оптимального принятия управленческих решений на основе полной информационной картины. 86 | 87 | __Архитектура КХД__ 88 | 89 | Вышеприведенное определение DWH показывает, что это средство хранения данных является реляционным. Однако, не стоит считать КХД просто большой базой данных с множеством взаимосвязанных таблиц. В отличие от традиционной SQL-СУБД, Data Warehouse имеет сложную многоуровневую (слоеную) архитектуру, которая называется LSA – Layered Scalable Architecture. По сути, LSA реализует логическое деление структур с данными на несколько функциональных уровней. Данные копируются с уровня на уровень и трансформируются при этом, чтобы в итоге предстать в виде согласованной информации, пригодной для анализа. 90 | 91 | Классически LSA реализуется в виде следующих уровней: 92 | 93 | 1. Операционный слой первичных данных(Primary Data Layer или стейджинг) 94 | Здесь выполняется загрузка информации из систем-источников в исходном качестве и сохранением полной истории изменений. Здесь происходит абстрагирование следующих слоев хранилища от физического устройства источников данных, способов их сбора и методов выделения изменений. 95 | 2. Ядро хранилища (Core Data Layer) 96 | Центральный компонент, который выполняет консолидацию данныхиз разных источников, приводя их к единым структурам и ключам. Именно здесь происходит основная работа с качеством данных и общие трансформации, чтобы абстрагировать потребителей от особенностей логического устройства источников данных и необходимости их взаимного сопоставления. Так решается задача обеспечения целостности и качества данных. 97 | 3. Аналитические витрины (Data Mart Layer) 98 | Тут данные преобразуются к структурам, удобным для анализа и использования в BI-дэшбордах или других системах-потребителях. Когда витрины берут данные из ядра, они называются регулярными. Если же для быстрого решения локальных задач не нужна консолидация данных, витрина может брать первичные данные из операционного слоя и называется соответственно операционной. Также бывают вторичные витрины, которые используются для представления результатов сложных расчетов и нетипичных трансформаций. Таким образом, витрины обеспечивают разные представления единых данных под конкретную бизнес-специфику. 99 | 4. Сервисный слой (Service Layer) 100 | Обеспечивает управление всеми вышеописанными уровнями. Он не содержит бизнес-данных, но оперирует метаданными и другими структурами для работы с качеством данных, позволяя выполнять сквозной аудит данных (data lineage), использовать общие подходы к выделению дельты изменений и управления загрузкой. Также здесь доступны средства мониторинга и диагностики ошибок, что ускоряет решение проблем. 101 | 102 | 103 | __LSA – слоеная архитектура DWH: как устроено хранилище данных__ 104 | ![LSA – слоеная архитектура DWH: как устроено хранилище данных](https://www.bigdataschool.ru/wp-content/uploads/2020/04/%D0%B4%D0%B2%D1%85_1.png) 105 | 106 | Все слои, кроме сервисного, состоят из области постоянного хранения данных и модуля загрузки и трансформации. Области хранения содержат технические (буферные) таблицы для трансформации данных и целевые таблицы, к которым обращается потребитель. Для обеспечения процессов загрузки и аудита ETL-процессов данные в целевых таблицах стейджинга, ядра и витринах маркируются техническими полями (мета-атрибутами). Еще выделяют слой виртуальных провайдеров данных и пользовательских отчетов для виртуального объединения (без хранения) данных из различных объектов. Каждый уровень может быть реализован с помощью разных технологий хранения и преобразования данных или универсальных продуктов, например, SAP NetWeaver Business Warehouse (SAP BW). 107 | 108 | __В чём разница между обычной базой данных и DWH__ 109 | 110 | 1. Типы хранимых данных. 111 | Обычные СУБД хранят данные строго для определенных подсистем. База данных склада хранит складские запасы и ничего более. База данных кадровиков хранит данные по персоналу, но не товары или сделки. DWH, как правило, хранит информацию разных подразделений — там найдутся данные и по товарам, и по персоналу, и по сделкам. 112 | 2. Объемы данных. 113 | Обычная БД, которая ведется в рамках стандартной деятельности компании, содержит только актуальную информацию, нужную в данный момент для функционирования определенной системы. В DWH пишутся не столько копии актуальных состояний, сколько исторические данные и агрегированные значения. Например, состояние запасов разных категорий товаров на конец смены за последние пять лет. Иногда в DWH пишутся и более крупные пачки данных, если они имеют критическое значение для бизнеса — допустим, полные данные по продажам и сделкам. То есть, по сути, это копия СУБД отдела продаж. 114 | 3. Место в рабочих процессах. 115 | Информация обычно сразу попадает в рабочие базы данных, а уже оттуда некоторые записи переползают в DWH. Склад данных, по сути, отражает состояние других БД и процессов в компании уже после того, как вносятся изменения в рабочих базах. 116 | 117 | DWH — это система данных, отдельная от оперативной системы обработки данных. В корпоративных хранилищах в удобном для анализа виде хранятся архивные данные из разных, иногда очень разнородных источников. Эти данные предварительно обрабатываются и загружаются в хранилище в ходе процессов извлечения, преобразования и загрузки, называемых ETL. Решения ETL и DWH — это (упрощенно) одна система для работы с корпоративной информацией и ее хранения. 118 | 119 | __Что дают DWH-решения для BI и принятия решений в компании__ 120 | 121 | Понятное дело, что просто так тратить деньги и время на консервирование кучи разных записей, которые и так можно накопать в других базах данных, никто не станет. Ответ заключается в том, что DWH необходима для того, чтобы делать BI — business intelligence. 122 | 123 | Что такое BI с DWH? Бизнес-аналитика (BI) — это процесс анализа данных и получения информации, помогающей компаниям принимать решения. 124 | 125 | Допустим, у вас в онлайн-магазине упала выручка. Менеджеры зовут на помощь бизнес-аналитика и просят его разобраться. Тот идет в DWH, вынимает оттуда данные по продажам, выручке, количеству пользователей, расходам — и собирает отчет, который в подробностях и с цифрами говорит о причинах падения финансовых показателей. Менеджеры внимательно смотрят на эту информацию и принимают решения по реорганизации ассортимента товаров и маркетинговых политик. 126 | Если бы такого аналитического отчета не было — управленцам пришлось бы искать проблему наугад. 127 | 128 | Логичный вопрос: казалось бы, зачем держать для этого всего DWH? Аналитики вполне могут ходить в базы данных разных систем и просто выдергивать оттуда то, что им надо. 129 | 130 | Ответ: так, конечно, тоже можно делать. Но — не нужно. И вот почему: 131 | 132 | 1. Доступ к нужным данным. 133 | Если компания большая, на получение данных из разных источников нужно собирать разрешения и доступы. У каждого подразделения в такой ситуации, как правило, свои базы данных со своими паролями, которые надо будет запрашивать отдельно. В DWH все нужное уже будет под рукой в готовом виде. Можно просто пойти и дернуть там необходимую статистику. 134 | 2. Сохранность нужных данных. 135 | Данные в DWH не теряются и хранятся в виде, удобном для принятия решений: есть исторические записи, есть агрегированные значения. В операционной базе данных такой информации может и не быть. Например, админы уж точно не будут хранить на складском сервере архив запасов за 10 лет — БД склада в таком случае была бы слишком тяжелой. А вот хранить агрегированные запасы со склада в DWH — это нормально. 136 | 3. Устойчивость работы бизнес-систем. 137 | DWH оптимизируется для работы аналитиков, а эти ребята могут запрашивать очень большие объемы информации. Если они будут делать это с помощью DWH — ничего страшного, даже если их запрос будет обрабатываться очень долго. А если запросить слишком много записей с боевой базы данных сервера — он может уйти в отказ до конца выполнения запроса от аналитики и создать проблемы для других систем. DWH исключает риск того, что аналитики что-то повесят или сломают. 138 | 139 | __Почему бизнес-аналитика невозможна без DWH__ 140 | 141 | DWH и бизнес-аналитики переводят управление компаниями из искусства в науку. Имея под рукой результаты измерений по сотням показателей, можно выдвигать гипотезы и ставить эксперименты. Правильные решения легко подтверждаются объективными цифрами, которые достают аналитики из DWH. 142 | 143 | Оптимальные управленческие решения — это не всегда максимизация прибыли. Это еще и выращивание новых производственных мощностей, минимизация негативного влияния на экологию, достойное качество жизни сотрудников, лояльность клиентов и стабильность бизнеса в долгосрочной перспективе. Все эти, казалось бы, сложные и эфемерные показатели можно анализировать с помощью BI и данных из DWH. 144 | 145 | Без DWH и аналитиков управление бизнесом превращается в слепую езду по льду — возможно, при определенной сноровке вы попадете куда надо, но шансов улететь в сугроб или в столб все же куда больше. 146 | 147 | ## Data Lake 148 | 149 | ([наверх](#sections)) 150 | 151 | Data Lake (Озеро данных) – это метод хранения данных системой или репозиторием в натуральном (RAW) формате, который предполагает одновременное хранение данных в различных схемах и форматах. Обычно используется blob-объект (binary large object) или файл. Идея озера данных в том чтобы иметь логически определенное, единое хранилище всех данных в организации (enterprise data) начиная от сырых, необработанных исходных данных (RAW data) до предварительно обработанных (transformed) данных, которые используются для различных задач: отчеты, визуализация, аналитика и машинное обучение. 152 | 153 | Data Lake (озеро данных) включает структурированные данные из реляционных баз данных (строки и колонки), полуструктурированные данные (CSV, лог файлы, XML, JSON), неструктурированные данные (почтовые сообщения, документы, pdf) и даже бинарные данные (видео, аудио, графические файлы). 154 | 155 | Data Lake (озеро данных), кроме методов хранения и описания данных, предполагает определение источников и методов пополнения данных. 156 | 157 | При этом используются следующие термины: 158 | 159 | * источники – sources; 160 | * настройки каналов – pipelines; 161 | * регулярность обновлений – schedulers; 162 | * владельцы – custodians; 163 | * время хранения – retention time; 164 | * метаданные – другие “данные о данных”. 165 | 166 | Data Lake (озеро данных) может использовать единый репозиторий в качестве хранилища данных (HDFS, EDW, IMDG, Cloud и т.д.) либо использовать модульную концепцию источников хранения данных для разных требований по безопасности, скорости, доступности при соблюдении условий хранения данных: неизменяемые RAW данные, согласованное время хранения (retention time), доступность. 167 | 168 | В 2010-х годах, с наступлением эпохи Big Data, фокус внимания от традиционных DWH сместился озерам данных (Data Lake). Однако, считать озеро данных новым поколением КХД не совсем корректно по следующим причинам: 169 | 170 | 1. Разное целевое назначение 171 | DWH используется менеджерами, аналитиками и другими конечными бизнес-пользователями, тогда как озеро данных – в основном Data Scientist’ами. Напомним, в Data Lake хранится неструктурированная, т.н. сырая информация: видеозаписи с беспилотников и камер наружного наблюдения, транспортная телеметрия, графические изображения, логи пользовательского поведения, метрики сайтов и информационных систем, а также прочие данные с разными форматами хранения (схемами представления). Они пока непригодны для ежедневной аналитики в BI-системах, но могут использоваться Data Scientist’ами для быстрой отработки новых бизнес-гипотез с помощью алгоритмов машинного обучения; 172 | 2. Разные подходы к проектированию 173 | Дизайн DWH основан на реляционной логике работы с данными – третья нормальная форма для нормализованных хранилищ, схемы звезды или снежинки для хранилищ с измерениями. При проектировании озера данных архитектор Big Data и Data Engineer большее внимание уделяют ETL-процессам с учетом многообразия источников и приемников разноформатной информации. А вопрос ее непосредственного хранения решается достаточно просто – требуется лишь масштабируемая, отказоустойчивая и относительно дешевая файловая система, например, HDFS или Amazon S3; 174 | 3. Цена 175 | обычно Data Lake строится на базе бюджетных серверов с Apache Hadoop, без дорогостоящих лицензий и мощного оборудования, в отличие от больших затрат на проектирование и покупку специализированных платформ класса Data Warehouse, таких как SAP, Oracle, Teradata и пр. 176 | 177 | Таким образом, озеро данных существенно отличается от КХД. Тем не менее, архитектурный подход LSA может использоваться и при построении Data Lake. Например, именно такая слоенная структура была принята за основу озера данных в Тинькоф-банке: 178 | 179 | * на уровне RAW хранятся сырые данные различных форматов (tsv, csv, xml, syslog, json и т.д.); 180 | * на операционном уровне (ODD, Operational Data Definition) сырые данные преобразуются в приближенный к реляционному формат; 181 | * на уровне детализации (DDS, Detail Data Store) собирается консолидированная модель детальных данных; 182 | * уровень MART выполняет роль прикладных витрин данных для бизнес-пользователей и моделей машинного обучения. 183 | 184 | В данном примере для структурированных запросов к большим данным используется Apache Hive – популярное средство класса SQL-on-Hadoop. Само файловое хранилище организовано в кластере Hadoop на основе коммерческого дистрибутива от Cloudera (CDH). Традиционное DWH банка реализовано на массивно-параллельной СУБД Greenplum. От себя добавим, что альтернативой Apache Hive могла выступить Cloudera Impala, которая также, как Greenplum, Arenadata DB и Teradata, основана на массивно-параллельной архитектуре. Впрочем, выбор Hive обоснован, если требовалась высокая отказоустойчивость и большая пропускная способность. Подробнее о сходствах и различиях Apache Hive и Cloudera Impala мы рассказывали здесь. Возвращаясь к кейсу Тинькофф-банка, отметим, что BI-инструменты считывают данные из озера и классического DWH, обогащая типичные OLAP-отчеты информацией из хранилища Big Data. Это используется для анализа интересов, прогнозирования поведения, а также выявления текущих и будущих потребностей, которые возникают у посетителей сайта банка. 185 | 186 | ## Витрины данных 187 | 188 | ([наверх](#sections)) 189 | 190 | Витрины данных — подмножество (срез) хранилища данных, представляющее собой массив тематической, узконаправленной информации, ориентированной, например, на пользователей одной рабочей группы или департамента. 191 | 192 | Концепция имеет ряд несомненных достоинств: 193 | 194 | * Аналитики видят и работают только с теми данными, которые им реально нужны. 195 | * Целевая БД максимально приближена к конечному пользователю. 196 | * Витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать. 197 | * Для реализации витрин данных не требуется высокомощная вычислительная техника. 198 | Но концепция витрин данных имеет и очень серьёзные пробелы. По существу, здесь предполагается реализация территориально распределённой информационной системы с мало контролируемой избыточностью, но не предлагается способов, как обеспечить целостность и непротиворечивость хранимых в ней данных. 199 | 200 | ## ETL и ETL-запросы 201 | 202 | ([наверх](#sections)) 203 | 204 | __ETL__ 205 | 206 | В переводе ETL (Extract, Transform, Load) — извлечение, преобразование и загрузка. То есть процесс, с помощью которого данные из нескольких систем объединяют в единое хранилище данных. 207 | 208 | Представьте ритейлера с розничными и интернет-магазинами. Ему нужно анализировать тенденции продаж и онлайн, и офлайн. Но бэкэнд-системы для них, скорее всего, будут отдельными. Они могут иметь разные поля или форматы полей для сбора данных, использовать системы, которые не могут «общаться» друг с другом. 209 | 210 | И вот тогда наступает момент для ETL. 211 | 212 | ETL-система извлекает данные из обеих систем, преобразует их в соответствии с требованиями к формату хранилища данных, а затем загружает в это хранилище. 213 | 214 | Схема всегда выглядит так: сначала извлечение данных из одного или нескольких источников, потом их подготовка к интеграции, после этого идет загрузка, и извлеченные данные попадают в общую базу. 215 | 216 | **Проектирование и разработка процесса ETL** 217 | 218 | Процесс ETL реализуется путем либо разработки приложения ETL, либо создания комплекса встроенных программных процедур, либо использования ETL-инструментария. Приложения ETL извлекают информацию из исходных БД источников, преобразуют ее в формат, поддерживаемый БД назначения, а затем загружают в эту БД преобразованные данные. 219 | 220 | Цель любого ETL-приложения состоит в том, чтобы своевременно доставить данные из внешних систем в систему, с которой работают пользователи. Как правило, ETL-приложения используются при переносе данных внешних источников в ХД систем бизнес-аналитики. Поэтому организация процесса ETL является составной частью проекта разработки практически любого ХД. 221 | 222 | Проектирование и разработка etl -процесса является одной из самых важных задач проектировщика ХД. 223 | Для ХД процесс ETL имеет следующие свойства: 224 | * Во-первых, объем данных, который выбирается из систем источников данных и помещается в ХД, как правило, бывает достаточно большим, до десятков Гб. 225 | * Во-вторых, процесс ETL является необходимой составной частью эксплуатации ХД. Периодичность процесса ETL определяется не только потребностью пользователя в своевременных данных, но и размером загружаемой порции данных. По оценкам специалистов, ETL-процесс может занимать до 80% времени. 226 | * В-третьих, на разных стадиях процесса ETL формируются метаданные ХД и обеспечивается качество данных. 227 | * В-четвертых, во время процесса ETL может произойти потеря данных, поэтому необходимо обеспечивать контроль за поступлением данных в ХД. 228 | * В-пятых, процесс ETL обладает свойством восстанавливаемости после сбоев без потери данных. 229 | 230 | **Процесс ETL состоит из трех основных стадий:** 231 | 232 | * Извлечение данных На этой стадии отбираются и описываются данные внешних источников (начинают формироваться метаданные ХД), которые должны храниться в ХД (релевантные данные). 233 | * Преобразование данных На этой стадии релевантные данные преобразуются в формат представления данных в ХД, правила преобразования сохраняются в метаданных ХД, формируются ключевые поля таблиц физической структуры ХД, выполняется очистка данных. 234 | * Загрузка данных На этой стадии данные загружаются в ХД, выполняется построение агрегатов. 235 | 236 | **Подходы к реализации ETL-процесса** 237 | 238 | Существует несколько подходов к реализации процесса ETL. Общепринятый подход состоит в извлечении данных из систем источников, размещении их в промежуточной области дисковой памяти (Data Staging Area), выполнении в этой промежуточной области процедур преобразования и очистки данных, а затем загрузки данных в ХД. Размещение извлеченных данных в промежуточной области означает запись данных в БД или файлы дисковой подсистемы. 239 | 240 | Еще один подход к реализации процесса ETL: 241 | 242 | Преобразование данных выполняется на сервере ХД, в процессе их загрузки. Использование такого подхода определяется вычислительными возможностями сервера ХД. Обычно такой подход применяется для [MPP серверов](https://coderoad.ru/2984338/%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D0%BC%D0%B0%D1%81%D1%81%D0%BE%D0%B2%D0%B0%D1%8F-%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F-%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-MPP) ХД. 243 | 244 | В зависимости от того, **кто** извлекает данные из систем источников, реализация ETL-процесса может быть выполнена следующими способами. 245 | 246 | * ETL-сервер периодически подключается к системам, источникам данных, опрашивает их, извлекает результаты выполнения запросов и размещает их у себя для дальнейшей обработки. 247 | * Триггеры систем источников данных отслеживают изменения в данных и размещают измененные данные в отдельных таблицах, которые затем экспортируются на ETL-сервер. 248 | * Специально разработанное приложение в системах источниках данных периодически опрашивает их и экспортирует данные на ETL-сервер. 249 | * Используются log-журналы БД систем источников, которые содержат все транзакции изменения данных. Измененные данные извлекаются из log-журналов и сохраняются на сервере системы источника данных для последующего импорта в ETL-сервер. 250 | 251 | В зависимости от того, **где** выполняется процесс извлечения данных из систем источников, реализация ETL-процесса может быть выполнена следующими способами. 252 | 253 | * ETL-процесс выполняется на выделенном ETL-сервере, который располагается между системами источниками данных и сервером ХД. В этом случае процесс ETL не использует вычислительных ресурсов сервера ХД и серверов систем источников данных. 254 | * ETL-процесс выполняется на сервере ХД. В этом случае сервер ХД должен иметь достаточное дисковое пространство для выполнения ETL-процесса, использование ресурсов сервера не должно сильно влиять на производительность запросов пользователей к ХД. 255 | * ETL-процесс выполняется на серверах систем источников данных для ХД. В этом случае изменения в данных сразу же отражаются в ХД. Такой подход используется при разработке ХД реального времени. 256 | 257 | Таким образом, при проектировании процесса ETL проектировщик ХД должен на основе анализа требований к функционированию ХД совместно с руководителем ИТ-проекта выбрать программно-аппаратное решение для реализации ETL-процесса, а именно – точно определить, где и каким способом будет выполняться ETL-процесс. На это решение может сильно повлиять бюджет проекта. Например, может быть недостаточно финансовых средств, чтобы реализовать процесс ETL на выделенном сервере. 258 | 259 | __ETL на практике__ 260 | 261 | Современные инструменты ETL собирают, преобразуют и хранят данные из миллионов транзакций в самых разных источниках данных и потоках. Эта возможность предоставляет множество новых возможностей: анализ исторических записей для оптимизации процесса продаж, корректировка цен и запасов в реальном времени, использование машинного обучения и искусственного интеллекта для создания прогнозных моделей, разработка новых потоков доходов, переход в облако и многое другое. 262 | 263 | **Облачная миграция** Процесс переноса данных и приложений в облако называют облачной миграцией. Она помогает сэкономить деньги, сделать приложения более масштабируемыми и защитить данные. ETL в таком случае используют для перемещения данных в облако. 264 | 265 | **Хранилище данных** Хранилище данных — база данных, куда передают данные из различных источников, чтобы их можно было совместно анализировать в коммерческих целях. Здесь ETL используют для перемещения данных в хранилище данных. 266 | 267 | **Машинное обучение** Машинное обучение — метод анализа данных, который автоматизирует построение аналитических моделей. ETL может использоваться для перемещения данных в одно хранилище для машинного обучения. 268 | 269 | **Интеграция маркетинговых данных** Маркетинговая интеграция включает в себя перемещение всех маркетинговых данных — о клиентах, продажах, из социальных сетей и веб-аналитики — в одно место, чтобы вы могли проанализировать их. ETL используют для объединения маркетинговых данных. 270 | 271 | **Интеграция данных IoT** То есть данных, собранных различными датчиками, в том числе встроенными в оборудование. ETL помогает перенести данные от разных IoT в одно место, чтобы вы могли сделать их подробный анализ. 272 | 273 | **Репликация базы данных** — данные из исходных баз данных копируют в облачное хранилище. Это может быть одноразовая операция или постоянный процесс, когда ваши данные обновляются в облаке сразу же после обновления в исходной базе. ETL можно использовать для осуществления процесса репликации данных. 274 | 275 | **Бизнес-аналитика** Бизнес-аналитика — процесс анализа данных, позволяющий руководителям, менеджерам и другим заинтересованным сторонам принимать обоснованные бизнес-решения. ETL можно использовать для переноса нужных данных в одно место, чтобы их можно было использовать. 276 | 277 | __Популярные ETL-системы__ 278 | 279 | **Cloud Big Data** — PaaS-сервис для анализа больших данных (big data) на базе Apache Hadoop, Apache Spark, ClickHouse. Легко масштабируется, позволяет заменить дорогую и неэффективную локальную инфраструктуру обработки данных на мощную облачную инфраструктуру. Помогает обрабатывать структурированные и неструктурированные данные из разных источников, в том числе в режиме реального времени. Развернуть кластер интеграции и обработки данных в облаках можно за несколько минут, управление осуществляется через веб-интерфейс, командную строку или API. 280 | 281 | **IBM InfoSphere** — инструмент ETL, часть пакета решений IBM Information Platforms и IBM InfoSphere. Доступен в различных версиях (Server Edition, Enterprise Edition и MVS Edition). Помогает в очистке, мониторинге, преобразовании и доставке данных, среди преимуществ: масштабируемость, возможность интеграции почти всех типов данных в режиме реального времени. 282 | 283 | **PowerCenter** — набор продуктов ETL, включающий клиентские инструменты PowerCenter, сервер и репозиторий. Данные хранятся в хранилище, где к ним получают доступ клиентские инструменты и сервер. Инструмент обеспечивает поддержку всего жизненного цикла интеграции данных: от запуска первого проекта до успешного развертывания критически важных корпоративных приложений. 284 | 285 | **iWay Software** предоставляет возможность интеграции приложений и данных для удобного использования в режиме реального времени. Клиенты используют их для управления структурированной и неструктурированной информацией. В комплект входят: iWay DataMigrator, iWay Service Manager и iWay Universal Adapter Framework. 286 | 287 | **Microsoft SQL Server** — платформа управления реляционными базами данных и создания высокопроизводительных решений интеграции данных, включающая пакеты ETL для хранилищ данных. 288 | 289 | **OpenText** — платформа интеграции, позволяющая извлекать, улучшать, преобразовывать, интегрировать и переносить данные и контент из одного или нескольких хранилищ в любое новое место назначения. Позволяет работать со структурированными и неструктурированными данными, локальными и облачными хранилищами. 290 | 291 | **Oracle GoldenGate** — комплексный программный пакет для интеграции и репликации данных в режиме реального времени в разнородных IT-средах. Обладает упрощенной настройкой и управлением, поддерживает облачные среды. 292 | 293 | **Pervasive Data Integrator** — программное решение для интеграции между корпоративными данными, сторонними приложениями и пользовательским программным обеспечением. Data Integrator поддерживает сценарии интеграции в реальном времени. 294 | 295 | **Pitney Bowes** предлагает большой набор инструментов и решений, нацеленных на интеграцию данных. Например, Sagent Data Flow — гибкий механизм интеграции, который собирает данные из разнородных источников и предоставляет полный набор инструментов преобразования данных для повышения их коммерческой ценности. 296 | 297 | **SAP Business Objects** — централизованная платформа для интеграции данных, качества данных, профилирования данных, обработки данных и отчетности. Предлагает бизнес-аналитику в реальном времени, приложения для визуализации и аналитики, интеграцию с офисными приложениями. 298 | 299 | **Sybase** включает Sybase ETL Development и Sybase ETL Server. Sybase ETL Development — инструмент с графическим интерфейсом для создания и проектирования проектов и заданий по преобразованию данных. Sybase ETL Server — масштабируемый механизм, который подключается к источникам данных, извлекает и загружает данные в хранилища. 300 | 301 | __Open source ETL-средства__ 302 | 303 | Большинство инструментов ETL с открытым исходным кодом помогают в управлении пакетной обработкой данных и автоматизации потоковой передачи информации из одной системы данных в другую. Эти рабочие процессы важны при создании хранилища данных для машинного обучения. 304 | 305 | Некоторые из бесплатных и открытых инструментов ETL принадлежат поставщикам, которые в итоге хотят продать корпоративный продукт, другие обслуживаются и управляются сообществом разработчиков, стремящихся демократизировать процесс. 306 | 307 | Open source ETL-инструменты интеграции данных: 308 | 309 | **Apache Airflow** — платформа с удобным веб-интерфейсом, где можно создавать, планировать и отслеживать рабочие процессы. Позволяет пользователям объединять задачи, которые нужно выполнить в строго определенной последовательности по заданному расписанию. Пользовательский интерфейс поддерживает визуализацию рабочих процессов, что помогает отслеживать прогресс и видеть возникающие проблемы. 310 | 311 | **Apache Kafka** — распределенная потоковая платформа, которая позволяет пользователям публиковать и подписываться на потоки записей, хранить потоки записей и обрабатывать их по мере появления. Kafka используют для создания конвейеров данных в реальном времени. Он работает как кластер на одном или нескольких серверах, отказоустойчив и масштабируем. 312 | 313 | **Apache NiFi** — распределенная система для быстрой параллельной загрузки и обработки данных с большим числом плагинов для источников и преобразований, широкими возможностями работы с данными. Пользовательский веб-интерфейс NiFi позволяет переключаться между дизайном, управлением, обратной связью и мониторингом. 314 | 315 | **CloverETL** (теперь CloverDX) был одним из первых инструментов ETL с открытым исходным кодом. Инфраструктура интеграции данных, основанная на Java, разработана для преобразования, отображения и манипулирования данными в различных форматах. CloverETL может использоваться автономно или встраиваться и подключаться к другим инструментам: RDBMS, JMS, SOAP, LDAP, S3, HTTP, FTP, ZIP и TAR. Хотя продукт больше не предлагается поставщиком, его можно безопасно загрузить с помощью SourceForge. CloverDX по-прежнему поддерживает CloverETL в соответствии со стандартным соглашением о поддержке. 316 | 317 | **Jaspersoft ETL** — один из продуктов с открытым исходным кодом TIBCO Community Edition, позволяет пользователям извлекать данные из различных источников, преобразовывать их на основе определенных бизнес-правил и загружать в централизованное хранилище данных для отчетности и аналитики. Механизм интеграции данных инструмента основан на Talend. Community Edition прост в развертывании, позволяет создавать витрины данных для отчетности и аналитики. 318 | 319 | **Apatar** — кроссплатформенный инструмент интеграции данных с открытым исходным кодом, который обеспечивает подключение к различным базам данных, приложениям, протоколам, файлам. Позволяет разработчикам, администраторам баз данных и бизнес-пользователям интегрировать информацию разного формата из различных источников данных. У инструмента интуитивно понятный пользовательский интерфейс, который не требует кодирования для настройки заданий интеграции данных. Инструмент поставляется с предварительно созданным набором инструментов интеграции и позволяет пользователям повторно использовать ранее созданные схемы сопоставления. 320 | 321 | # Разработка ETL-процесса 322 | 323 | ([наверх](#sections)) 324 | 325 | Разработка ETL-процесса 326 | Как правило, при конструировании процесса ETL для ХД придерживаются следующей последовательности действий. 327 | 328 | * [Планирование ETL-процесса](#Planning-the-ETL-process), которое включает в себя разработку диаграммы потоков данных от систем-источников, определение преобразований, метода генерации ключей и последовательности операций для каждой таблицы назначения. 329 | * [Конструирование процесса заполнения таблиц измерений](#Designing-a-Process-for-Populating-Measurement-Tables), которое включает в себя разработку и верификацию процесса заполнения статических таблиц измерений, разработку и верификацию механизмов изменения для каждой таблицы измерений. 330 | * [Конструирование процесса заполнения таблиц фактов](#Designing-a-process-for-populating-fact-tables), которое включает в себя разработку и верификацию процесса первоначального заполнения и периодического дополнения таблиц фактов, построение агрегатов и разработку процедур автоматизации процесса ETL. 331 | 332 | **Планирование ETL-процесса** 333 | 334 | 335 | Сначала создается обобщенный план, в котором отражается перечень систем –источников данных и указываются планируемые целевые области данных (данных, которые будут размещаться в ХД). Источник целевых данных определяется на основе сформулированных бизнес-требований к ХД. Как правило, источники данных существенно различаются: от БД и текстовых файлов до SMS-сообщений. Это обстоятельство может значительно усложнить задачу преобразования данных. 336 | 337 | Назначение таких высокоуровневых описаний источников дает, с одной стороны, разработчикам представление и о создаваемой системе, и о существующих источниках данных, а с другой, руководству организации, — понимание сложности, связанной с процессами преобразования данных. 338 | 339 | К составлению обобщенного плана лучше всего приступать, когда разработана многомерная модель ХД. Тогда для каждой таблицы многомерной схемы можно определить таблицы – источники данных. 340 | 341 | На этой стадии планирования необходимо зафиксировать все обнаруженные расхождения в определениях данных и схемах кодирования. 342 | 343 | Детальное планирование ETL-процесса во многом зависит от использования выбранных ETL-инструментов. К настоящему времени разработано достаточно много таких инструментов как компаниями производителями комплексных решений в области ХД (IBM, Oracle, MicroSoft), так и сторонними производителями программного обеспечения (Sunopsis). Поэтому задача выбора подходящих ETL-инструментов должна быть решена до того, как приступать к детальному планированию. 344 | 345 | Программное обеспечение этого класса предназначено для извлечения, приведения к общему формату, преобразованию, очистки и загрузки данных в хранилище. Существуют два подхода к написанию ETL-процедур: 346 | 1) их можно написать вручную; 347 | 2) можно воспользоваться специализированными средствами ETL. 348 | 349 | Каждый из подходов имеет ряд преимуществ и недостатков, поэтому выбор того или иного метода реализации процедур ETL определяется требованиями к подсистеме загрузки данных в каждом конкретном случае. 350 | 351 | _Написание вручную:_ 352 | * возможность использования широко распространенных парадигм программирования, например, объектно-ориентированного программирования; 353 | * возможность применения многих существующих методик и программных средств, позволяющих автоматизировать процесс тестирования разрабатываемых процедур загрузки данных ; 354 | * доступность человеческих ресурсов; 355 | * возможность построения наиболее производительного решения с использованием при программировании всех преимуществ систем управления базами данных (СУБД), задействованных в проекте; 356 | * возможность построения наиболее гибкого решения. 357 | 358 | _Применение ETL-инструментов:_ 359 | 360 | * упрощение процесса разработки, и, главное, процесса поддержания и модификации процедур ETL; 361 | * ускорение процесса разработки системы, возможность использования готовых наработок, поставляемых вместе со средствами ETL; 362 | * возможность использования встроенных систем управления метаданными, позволяющих синхронизовать метаданные между СУБД, средством ETL, а также инструментами визуализации данных; 363 | * возможность автоматической документации написанных процедур; 364 | * многие средства ETL предоставляют собой средства увеличения производительности подсистемы загрузки данных, которые включают в себя возможность распараллеливания вычислений на различных узлах системы, использование хеширования и многие другие. 365 | 366 | 367 | **Конструирование процесса заполнения таблиц измерений** 368 | 369 | 370 | Для таблиц измерений ХД, которые не будут изменяться со временем, в разработке процесса ETL первой основной задачей является выбор первичного ключа таблицы. Выбор ключа осуществляется проектировщиком ХД на основе анализа источников данных. 371 | 372 | Второй основной задачей является проверка наличия в измерении отношений "один к одному" и "один ко многим". Как правило, для такой проверки используется сортировка. 373 | 374 | Затем следует рассмотреть изменяющиеся измерения, определить тип изменений и описать процедуры работы с такими измерениями. 375 | 376 | Загрузка таблиц измерений выполняется либо путем перезаписи таблицы измерения (для небольших по объему таблиц), либо загружаются только изменения в данных таблиц измерений. 377 | 378 | **Конструирование процесса заполнения таблиц фактов** 379 | 380 | При конструировании процесса заполнения таблиц фактов проектировщик решает следующие основные задачи: 381 | 382 | * проанализировать построенные таблицы фактов; 383 | рассмотреть процесс загрузки таблиц фактов; 384 | * рассмотреть и проанализировать построенные агрегаты; 385 | * рассмотреть процесс загрузки агрегатов. 386 | 387 | Процесс загрузки таблиц фактов бывает двух типов: первоначальная загрузка и периодическая загрузка изменений. 388 | 389 | Проблемы, связанные с первоначальной загрузкой, состоят в том, что с большой долей вероятности вы не получите корректных исторических данных из-за больших объемов данных. Поэтому важно оценить, какой тип загрузки для какой таблицы фактов подходит наилучшим образом. 390 | 391 | ## Элементы ETL-процесса 392 | 393 | ([наверх](#sections)) 394 | 395 | **Извлечение данных** 396 | 397 | Целью процесса извлечения данных является быстрое извлечение релевантных данных из источников данных. 398 | 399 | Процесс извлечения данных из источников данных можно разбить на следующие основные типы: 400 | 401 | * извлечение данных при помощи приложений, основанных на выполнении SQL-команд. Эти приложения функционируют совместно с другими приложениями систем источников данных; 402 | * извлечение данных при помощи встроенных в СУБД механизмов импорта/экспорта данных. Использование таких механизмов, как правило, обеспечивает более быстрое извлечение данных, чем с помощью команд SQL; 403 | * извлечение данных с помощью специально разработанных приложений. 404 | 405 | Процесс извлечения данных может выполняться ежедневно, еженедельно или, в редких случаях, ежемесячно. Отметим, что существует целый класс систем бизнес-аналитики, которые требуют извлечения данных в режиме реального времени: например, системы, анализирующие биржевые операции (каждую секунду), или системы в области телекоммуникаций. 406 | 407 | Процесс извлечения данных может выполняться либо в среде оперативных систем обработки данных (источников), либо в среде функционирования ХД. 408 | 409 | **Преобразование данных** 410 | 411 | Процесс преобразования данных источников включает в себя следующие основные действия. 412 | 413 | * Преобразование типов данных: 414 | - преобразования, связанные с кодировкой данных, например, EBCDIC -> ASCII / UniCode; 415 | - преобразование строковых данных; 416 | - преобразование форматов данных для представления даты или времени. 417 | * Преобразования, связанные с нормализацией или денормализацией схемы данных: 418 | - преобразование денормализации схемы с целью увеличения производительности выполнения запросов к ХД; 419 | - нормализация схемы ХД с целью обеспечения простоты SQL-запросов. 420 | * Преобразования ключей, связанные с обеспечением соответствия бизнес-ключей суррогатным ключам ХД. 421 | * Преобразования, связанные с обеспечением качества данных в ХД. 422 | 423 | Как правило, данные источников не обладают необходимым уровнем качества данных. Заметим, что данные в ХД должны быть: 424 | 425 | * точными – данные должны содержать правильные количественные значения метрик или давать объяснения, почему невозможно такие значения иметь; 426 | * полными – пользователи ХД должны знать, что имеют доступ ко всем релевантным данным; 427 | * согласованными – никакие противоречия в данных не допускаются: агрегаты должны точно соответствовать подробным данным; 428 | * уникальными – одни и те же объекты предметной области должны иметь одинаковые наименования и идентифицироваться в ХД одинаковыми ключами; 429 | * актуальными – пользователи ХД должны знать, с какой частотой данные обновляются (т.е. на какую дату данные действительны). 430 | 431 | Для обеспечения качества данные при преобразовании подвергаются процедуре очистки. Процедура очистки данных необходима, поскольку системы бизнес-аналитики не работают с несогласованными и неточными данными, иначе бизнес-анализ становится бессмысленным. 432 | 433 | Процедура очистки данных включает в себя согласование форматов данных, кодирование данных, исключение ненужных атрибутов (например, комментариев), замещение кодов значениями (например, почтового индекса наименованием населенного пункта), комбинирование данных из различных источников под общим ключом (например, собрать все данные о покупателях), обнаружение одинаково поименованных атрибутов, которые содержат различные по смыслу значения. 434 | 435 | Очистку данных можно разделить на следующие типы: 436 | 437 | * конвертация и нормализация данных (приведение к одинаковому кодированию текста, форматам даты и т. д.); 438 | * стандартизация написания имен, представления адресов, устранение дубликатов; 439 | * стандартизация наименований таблиц, индексов и т.д.; 440 | * очистка, основанная на бизнес-правилах предметной области. 441 | 442 | Процедуры очистки также включают в себя создание меток статуса фактов в таблицах измерения (нормальный, ненормальный, невозможный, выходящий за границы, анализируемый или нет и т.д.), распознавание случайных и зашумленных значений (замещение их NULL-значением или оценкой), унификация использования NULL-значений, маркирование фактов с изменившимся статусом (например, покупатель аннулировал контракт), агрегирование фактов и т.п. 443 | 444 | **Загрузка данных** 445 | 446 | Основная цель процесса загрузки данных состоит в быстрой загрузке данных в ХД. Отметим некоторые особенности выполнения процесса загрузки данных в ХД. 447 | 448 | * Во-первых, загрузка данных, основанная на использовании команд обновления SQL, является медленной. Каждая команда SQL выполняется СУБД по определенному плану выполнения, и ее обработка включает выполнение нескольких фаз. Поэтому загрузка с помощью встроенных в СУБД средств импорта/экспорта является предпочтительной. 449 | 450 | * Во-вторых, индексы таблиц загружаются медленно. Во многих случаях целесообразно удалить индекс и построить его заново. 451 | 452 | * В-третьих, следует максимально использовать параллелизм при загрузке данных. Измерения могут производиться одновременно с фактами и секциями таблиц. Аналогично факты и секции таблиц могут загружаться одновременно с измерениями. 453 | 454 | Следует заметить, что при загрузке данных должна быть гарантирована ссылочная целостность данных, а агрегаты должны быть построены и загружены одновременно с подробными данными. 455 | 456 | Настройка производительности загрузки данных в ХД выполняется администратором ХД с помощью набора процедур, предусмотренных используемой СУБД. 457 | 458 | # Что такое Hadoop? 459 | 460 | ([наверх](#sections)) 461 | 462 | Hadoop - инструмент для обработки Big Data. Hadoop - это проект Apache, является системой для распределённых вычислений. При этом эта система является масштабируемой и отказоустойчивой. 463 | 464 | __История Hadoop__ 465 | Начинался как проект в Apache Nutch 466 | В 2004 году Google публикует статьи про GFS и MapReduce 467 | На основе этих статей формируется распределённая файловая система 468 | 469 | __Системные принципы Hadoop__ 470 | * Горизонтальное (Scale-out) масштабирование вместо вертикального (Scale-Up) 471 | * Отправление кода к данным 472 | * Умение обрабатывать падения нод и отказы оборудования 473 | * Инкапсуляция сложности работы распределённых и многопоточных приложений 474 | 475 | __Масштабирование__ 476 | * Вертикальное 477 | - Добавить дополнительные ресурсы к существующему железу (CPU, RAM) 478 | - Если нельзя улучшить железо, то надо покупать более мощное новое 479 | - Закон Мура не успевает за ростом объёма данных 480 | * Горизонтальное 481 | - Добавить больше машин к существующему кластеру 482 | - Приложение поддерживает добавлние/удаление серверов 483 | - Просто масштабировать "вниз" 484 | 485 | # Data Vault 486 | 487 | ([наверх](#sections)) 488 | 489 | Большинство компаний сегодня накапливают различные данные, полученные в процессе работы. Часто данные приходят из различных источников — структурированные и не очень, иногда в режиме реального времени, а иногда они доступны в строго определенные периоды. Все это разнообразие нужно структурированно хранить, чтоб потом успешно анализировать, рисовать красивые отчеты и вовремя замечать аномалии. Для этих целей проектируется хранилище данных (Data Warehouse, DWH). 490 | 491 | Data Vault - это один из подходов к построению такого универсального хранилища. 492 | 493 | Data Vault состоит из трех основных компонентов — **Хаб** (Hub), **Ссылка** (Link) и **Сателлит** (Satellite). 494 | 495 | **Хаб** 496 | 497 | Хаб — основное представление сущности (Клиент, Продукт, Заказ) с позиции бизнеса. Таблица-Хаб содержит одно или несколько полей, отражающих сущность в понятиях бизнеса. В совокупности эти поля называются «бизнес ключ». Идеальный кандидат на звание бизнес-ключа это ИНН организации или VIN номер автомобиля, а сгенерированный системой ID будет наихудшим вариантом. Бизнес ключ всегда должен быть уникальным и неизменным. 498 | Хаб так же содержит мета-поля _load timestamp_ и _record source_, в которых хранятся время первоначальной загрузки сущности в хранилище и ее источник (название системы, базы или файла, откуда данные были загружены). 499 | 500 | Таблицы Хабы 501 | 502 | ![Таблицы Хабы](https://habrastorage.org/r/w780/webt/8q/r3/ik/8qr3ikyx5nwg2dsjaqbxdrw7y4a.png) 503 | 504 | **Ссылка** 505 | 506 | Таблицы-Ссылки связывают несколько хабов связью многие-ко-многим. Она содержит те же метаданные, что и Хаб. Ссылка может быть связана с другой Ссылкой, но такой подход создает проблемы при загрузке, так что лучше выделить одну из Ссылок в отдельный Хаб. 507 | 508 | Таблица-ссылка 509 | 510 | ![Таблица-ссылка](https://habrastorage.org/r/w780/webt/sr/q1/p2/srq1p2pdfcgx-xmqjl6xrsh_hpq.png) 511 | 512 | **Сателлит** 513 | 514 | Таблицы-Сателлиты содержат все описательные атрибуты Хаба или Ссылки (контекст). Помимо контекста Сателлит содержит стандартный набор метаданных (_load timestamp_ и _record source_) и один и только один ключ «родителя». В Сателлитах можно без проблем хранить историю изменения контекста, каждый раз добавляя новую запись при обновлении контекста в системе-источнике. Для упрощения процесса обновления большого сателлита в таблицу можно добавить поле hash diff: MD5 или SHA-1 хеш от всех его описательных атрибутов. Для Хаба или Ссылки может быть сколь угодно Сателлитов, обычно контекст разбивается по частоте обновления. Контекст из разных систем-источников принято класть в отдельные Сателлиты. 515 | 516 | Таблицы-Сателлиты 517 | 518 | ![Таблицы-Сателлиты](https://habrastorage.org/r/w780/webt/kl/fa/7r/klfa7re28amqqotkvwxovutlpo8.png) 519 | 520 | Таблицы Data Vault: хабы, ссылки, спутники 521 | 522 | ![Таблицы Data Vault: хабы, ссылки, спутники](https://www.bigdataschool.ru/wp-content/uploads/2020/04/%D0%B4%D0%B0%D1%82%D0%B0%D0%B2%D0%BE%D0%BB_1.png) 523 | 524 | **Как с этим работать?** 525 | 526 | ![Building a Scalable Data Warehouse with Data Vault 2.0](https://habrastorage.org/r/w780/webt/2v/q_/kv/2vq_kviv6uebjj_m1svk5rafubi.png) 527 | 528 | Сначала данные из операционных систем поступают в staging area. Staging area используется как промежуточное звено в процессе загрузки данных. Одна из основных функций Staging зоны это уменьшение нагрузки на операционные базы при выполнении запросов. Таблицы здесь полностью повторяют исходную структуру, но любые ограничения на вставку данных, вроде not null или проверки целостности внешних ключей, должны быть выключены с целью оставить возможность вставить даже поврежденные или неполные данные (особенно это актуально для excel-таблиц и прочих файлов). Дополнительно в stage таблицах содержатся хеши бизнес ключей и информация о времени загрузки и источнике данных. 529 | 530 | После этого данные разбиваются на Хабы, Ссылки и Сателлиты и загружаются в Raw Data Vault. В процессе загрузки они никак не агрегируются и не пересчитываются. 531 | 532 | Business Vault — опциональная вспомогательная надстройка над Raw Data Vault. Строится по тем же принципам, но содержит переработанные данные: агрегированные результаты, сконвертированные валюты и прочее. Разделение чисто логическое, физически Business Vault находится в одной базе с Raw Data Vault и предназначен в основном для упрощения формирования витрин. 533 | 534 | Когда нужные таблицы созданы и заполнены, наступает очередь витрин данных (Data Marts). Каждая витрина это отдельная база данных или схема, предназначенная для решения задач различных пользователей или отделов. В ней может быть специально собранная «звезда» или коллекция денормализованных таблиц. Если возможно, таблицы внутри витрин лучше делать виртуальными, то есть вычисляемыми «на лету». Для этого обычно используются SQL представления (SQL views). 535 | 536 | **Заполнение Data Vault** 537 | 538 | Cначала загружаются Хабы, потом Ссылки и затем Сателлиты. Хабы можно загружать параллельно, так же как и Сателлиты и Ссылки, если конечно не используется связь link-to-link. 539 | 540 | Есть вариант и вовсе выключить проверку целостности и загружать все данные одновременно. Как раз такой подход соответствует одному из основных постулатов DV — «Загружать все доступные данные все время (Load all of the data, all of the time)» и именно здесь играют решающую роль бизнес ключи. Суть в том, что возможные проблемы при загрузке данных должны быть минимизированы, а одна из наиболее распространенных проблем это нарушение целостности. Подход, конечно, спорный, но лично я им пользуюсь и нахожу действительно удобным: данные все равно проверяются, но после загрузки. Часто можно столкнуться с проблемой отсутствия записей в нескольких Хабах при загрузке Ссылок и последовательно разбираться, почему тот или иной Хаб не заполнен до конца, перезапуская процесс и изучая новую ошибку. Альтернативный вариант — вывести недостающие данные уже после загрузки и увидеть все проблемы за один раз. Бонусом получаем устойчивость к ошибкам и возможность не следить за порядком загрузки таблиц. 541 | 542 | **Преимущества и недостатки** 543 | 544 | [+] Гибкость и расширяемость. 545 | С Data Vault перестает быть проблемой как расширение структуры хранилища, так и добавление и сопоставление данных из новых источников. Максимально полное хранилище «сырых» данных и удобная структура их хранения позволяют нам сформировать витрину под любые требования бизнеса, а существующие решения на рынке СУБД хорошо справляются с огромными объемами информации и быстро выполняют даже очень сложные запросы, что дает возможность виртуализировать большинство витрин. 546 | [+] Agile-подход из коробки. 547 | Моделировать хранилище по методологии Data Vault довольно просто. Новые данные просто «подключаются» к существующей модели, не ломая и не модифицируя существующую структуру. При этом мы будем решать поставленную задачу максимально изолированно, загружая только необходимый минимум, и, вероятно, наша временнáя оценка для такой задачи станет точнее. Планирование спринтов будет проще, а результаты предсказуемы с первой же итерации. 548 | [–] Обилие JOIN'ов 549 | За счет большого количества операций join запросы могут быть медленнее, чем в традиционных хранилищах данных, где таблицы денормализованы. 550 | [–] Сложность. 551 | В описанной выше методологии есть множество важных деталей, разобраться в которых вряд ли получится за пару часов. К этому можно прибавить малое количество информации в интернете и почти полное отсутствие материалов на русском языке (надеюсь это исправить). Как следствие, при внедрении Data Vault возникают проблемы с обучением команды, появляется много вопросов относительно нюансов конкретного бизнеса. К счастью, существуют ресурсы, на которых можно задать эти вопросы. Большой недостаток сложности это обязательное требование к наличию витрин данных, так как сам по себе Data Vault плохо подходит для прямых запросов. 552 | [–] Избыточность. 553 | Довольно спорный недостаток, но я часто вижу вопросы об избыточности, поэтому прокомментирую этот момент со своей точки зрения. 554 | 555 | # Apache Kafka 556 | 557 | ([наверх](#sections)) 558 | 559 | Кафка - это распределённое, отказоусойчивое, горизонтально масштабируемое хранилище, основной структурой данных в котором является append-only лог, которое поддерживает потоковую обработку данных и имеет развитую экосистему коннектеров для интеграции с базами данных и другими хранилищами 560 | 561 | Apache Kafka - в силу своей архитектуры Kafka может быть и базой данных, и системой очередей и платформой для потоковой обработки данных. 562 | С одной стороны кафка позваляет публиковать потоки данных, сообщения, метрики, логи или картинки и с другой стороны подписываться. При этом кафка умеет справляться практически с любыми объемами информации, отлично масштабируется горизонтально, хранит все данные на диске, обладает высокой отказоустойчивостью. 563 | 564 | **Распределённое хранилище** - это система, которая как правило работает на нескольких машинах, каджая из этих машин в свою очередь является кусочком хранилища. Для пользователя это все представляется в виде единого целого. 565 | 566 | **Горизонтальное масштабирование** - эта техника позволяющая обеспечивать работоспособность системы даже в случае увеличенной нагрузки. Путём добавляния машин. 567 | 568 | **Потоковая обработка данных** - получение на входе некого непрерывно-пополняющегося набора данных, такая же непрерывная обработка этих данных и подача результата на выход. 569 | 570 | **Kafka vs Queue** 571 | 572 | Системы очередей обычно состоят из 3х базовых компонентов: 573 | * Сревер 574 | * Продюсер - отправляет сообщения в именнованную очередь 575 | * Консюмер - считывает сообщения (pull и push) 576 | 577 | Жизненный цикл сообщений в системе очередей: 578 | * Продьюсер отправляет сообщение на сервер 579 | * Консьюмер фетчит сообщение и его уникальный идентификатор сервера 580 | * Сервер помечает сообшение 581 | * Консьюмер обрабатывает сообщение следую некой бизнес логике 582 | * Отправляет запрос обратно на сервер либо подтверждая успешную обработку сообщения, либо сигнализирую об ошибке 583 | * В случае успеха, сообщение удаляется с сервера навсегда 584 | * В случае неудаче сообщение отправляется другому консьюмеру 585 | 586 | Отличие кафки от очередей - то как сообщения хранятся на сервере(брокере) и как отправляются консьюмерам. Сообщения в кафке не удаляются по мере обработки консьюмерами, данные в кафе хранятся сколько угодно. Одно и тоже сообщение может быть обработано несколько раз разными консьюмерами и в разных контекстах. 587 | 588 | **Структура данных** 589 | 590 | Каждое сообщение состоит из: 591 | * Ключа (key) 592 | * Значения (Value) 593 | * Timestamp 594 | * Опциональный набор метаданных (Headers) 595 | 596 | Партиция - распределённый отказоустойчивый лог 597 | 598 | Сообщения хранятся в именнованных топиках, каждый топик состоит мз одной и более партицей, распределёных между брокерами внутри одного кластера. Это важно для горизонтального масштабирования кластера, так как она позволяет клиентам писать и читать сообщения с нескольких брокеров одновременно. 599 | Когда новое сообщение добавляется в топик, оно записывается в одну из партицей этого топика. Сообщения с одинаковыми ключами записываются в одну и туже партицию. 600 | У каждой партиции есть лидер, или брокер, который работает с клиентами лидер принимает сообщения от продьюсеров и отдаёт консьюмерам. 601 | 602 | # Greenplum 603 | 604 | ([наверх](#sections)) 605 | 606 | В основе Greenplum две вещи: 607 | * база данных PostgreSQL; 608 | * архитектурная концепция MPP. 609 | 610 | MPP — massively parallel processing, или массивно-параллельная обработка данных. Такая архитектура весьма сложно устроена под капотом, но ее можно свести к простому концептуальному описанию. Это умная автоматическая разбивка данных по разным серверам (шардинг) с умной автоматической системой выполнения запросов к этим данным. Всё вместе это позволяет хранить петабайты записей и выполнять запросы к ним за вполне разумный срок. 611 | 612 | Разбивку большого количества данных по серверам базы данных (шардинг) можно сделать и руками, например, первый миллион записей хранится на первом сервере, а второй на втором. Если сразу всем клиентам системы понадобится прочитать записи с одного сервера — этот сервер может не выдержать. Масштабировать такую систему тоже очень сложно. 613 | Greenplum берет на себя все эти заботы и организует шардирование своими силами, заботясь обо всех нюансах. А еще Greenplum можно настраивать на различные стратегии выполнения запросов, ориентируясь на количество записей, количество процессоров и памяти на каждой машине. 614 | 615 | Greenplum поддерживает реляционную модель данных, сохраняет неизменность данных, поэтому ее можно применять для данных, чувствительных к точности и структурности. Например, для финансовых операций. Greenplum — хороший выбор для банков, ритейла и других компаний, где проводят большое число транзакций и их нельзя потерять. 616 | 617 | От систем типа ClickHouse Greenplum отличается сферой применения. Если Clickhouse больше подходит для статистики, то Greenplum намного ближе к полноценной СУБД с индексами и хитрыми запросами. Это позволяет быстрее обращаться к определенным записям. При этом Greenplum справляется с аналитическими нагрузками от бизнес-аналитики до машинного обучения. Сама система за хранение данных не отвечает, для этих целей она использует PostgreSQL. 618 | 619 | Главное отличие между PostgreSQL и Greenplum заключается в следующем: 620 | 621 | * архитектура – Greenplum реализует массивно-параллельную обработку без разделения ресурсов, а PostgreSQL – классическую клиент-серверную технологию. В Greenplum для повышения надежности к типовой топологии master-slave добавлен резервный главный сервер (Secondary master instance), включаемый вручную при отказе основного мастера. 622 | * структура хранения данных. Greenplum – это одновременно хранилище данных и база транзакционных или операционных данных с распараллеливанием вычислительных процессов и хранения информации в нескольких экземплярах PostgreSQL на разных физических серверах с функцией колоночного хранения и сжатия. 623 | * сценарии применения. Greenplum предназначен для одновременной обработки транзакционных событий обработки и отлично подходит для обширной OLAP-аналитики больших данных. PostgreSQL – хороший вариант для баз данных небольшого размера с OLTP-кейсами. 624 | 625 | # Распределённая файловая система HDFS 626 | 627 | * [Архитектура HDFS](#HDFS-architecture) 628 | * [Shell-команды](#Shell-commands) 629 | * [Java API](#Java_API1) 630 | 631 | ([наверх](#sections)) 632 | 633 | ## Архитектура HDFS 634 | 635 | 636 | HDFS (Hadoop Distributed File System) - это распределённая файловая система в hadoop. Как и любая другая файловая система она служит для хранения данных. 637 | 638 | HDFS: 639 | * Работает на кластере серверов 640 | * Для пользователя как "Один большой диск" 641 | * Работает поверх обычных файловых систем (ext3, ext4, XFS) 642 | * Не теряет данные если выходят из строя диски или сервера 643 | 644 | HDFS подходит для: 645 | * Хранения больших данных 646 | - Терабайты, петабайты 647 | - Миллионы файлов 648 | - Файлы размером от 100 Мбэ 649 | * Стриминга данных 650 | - Паттерн "write once / read many times" 651 | - Оптимизация под последовательное чтение 652 | 653 | HDFS не подходит для: 654 | * Low-latency reads 655 | - Высокая пропускная способность вместо быстрого доступа к данным 656 | - HBase помогает решить эту задачу 657 | * Большого количество небольших файлов 658 | - Лучше миллион больших файлов, чем миллиард маленьких 659 | * Многопоточная запись 660 | - Один процесс записи на файл 661 | - данные дописываются в конец файла 662 | 663 | __Демоны HDFS__ 664 | ![Демоны HDFS](https://russianblogs.com/images/753/dc2fb07713850c486dd1e421bc6843d9.png) 665 | 666 | **Namenode** 667 | Отвечает за: 668 | * Файловое пространство 669 | * Мета-информацию 670 | * Расположение блоков файлов 671 | Запускается на 1й выделенной машине 672 | 673 | **Datanode** 674 | Отвечает за: 675 | * Хранение и передачу блоков данных 676 | * Отправку сообщений о состоянии на Namenode 677 | 678 | Запускается на каждой машине кластера 679 | 680 | **Файлы и блоки** 681 | 682 | * Файлы в HDFS состоят из блоков 683 | блок - еденица хранения данных 684 | * Управление через Namenode 685 | * Хранится в Datanode 686 | 687 | Реплицируются по машинам в процессе записи: 688 | 689 | * Один и тот же блок хранится на нескольких Datanode 690 | * Фактор репликации по умлочанию равен 3 691 | * Это нужно для fault-tolerance и упрощения доступа 692 | 693 | * Стандартный размер блоков 64 Мб или 128 Мб 694 | * Основной мотив этого - снизить стоимость seek time по сравнению со скоростью передачи данных (transfer rate) 695 | 696 | **Репликация блоков** 697 | 698 | * Namenode определяет, где распологать блоки 699 | * Баланс между надёжностью и производительностью 700 | - Попытка снизить нагрузку на сеть 701 | - Попытка улучшить надёжность 702 | 703 | Фактор репликации по умлочанию равен 3 704 | 705 | - 1-я реплика на локальную машину 706 | - 2-я реплика на другую машину из той же стойки 707 | - 3-я реплика на другую машину из другой стойки 708 | 709 | **Namenode Использование памяти** 710 | 711 | Чем больше кластер, тем больше ОЗУ требуется 712 | Больше размер блока -> меньше блоков 713 | Меньше блоков -> больше файлов в FS 714 | 715 | Если Namenode падает, то HDFS не работает 716 | Namenode - это едина точка отказа 717 | Она должна быть на отдельной надёжной машиной. 718 | 719 | **Доступ к HDFS** 720 | 721 | * Direct Access 722 | - Взаимодействует с HDFS с помощью нативного клиента 723 | - Java, C++ 724 | - Клиент запрашивает метаданные от NN 725 | - Клиент напрямую запрашивает данные от DN 726 | - Используется для MapReduce 727 | * Через Proxy Server 728 | - Доступ к HDFS через Proxy Server - middle man 729 | - ответ в форматие JSON, XML 730 | - Серверы REST, Thrift и Avro - механизм сериализации 731 | 732 | ### Shell-команды 733 | 734 | 735 | ([наверх](#sections)) 736 | 737 | Для работы с HDFS через командную строку 738 | 739 | ```$hdfs dfs (значит, что будем работать непосредственно с фаловой системой) - -