Для чего хранилища данных

Для чего хранилища данных

По Вашему запросу ничего не найдено.

Рекомендуем сделать следующее:

Темы в этом разделе

Хранилище данных — определение

Хранилище данных служит для централизации и консолидации больших объемов данных из различных источников. Аналитические инструменты дают возможность компаниям извлекать из собственных данных ценные для бизнеса сведения и повышать эффективность принятых решений. Со временем в хранилище накапливаются записи за прошедшие периоды, которые представляют большую ценность для специалистов по изучению данных и бизнес-аналитиков. Эти возможности делают хранилища данных “единым источником проверенной информации компании.”

Обычно хранилище данных включает в себя следующие компоненты:

Преимущества хранилища данных

Хранилища данных обеспечивают для компаний обширные преимущества, так как дают возможность анализировать большие объемы разнообразных данных, извлекать из них значительную ценность, а также хранить записи за прошедшие периоды.

Эти уникальные преимущества доступны благодаря четырем отличительным особенностям хранилищ данных, которые описал специалист по вычислительным системам Уильям Инмон (William Inmon). Согласно данному им определению, хранилища данных имеют следующие характеристики.

Хорошо спроектированное хранилище данных обеспечивает быстрое выполнение запросов, эффективное прохождение больших объемов данных и достаточный уровень гибкости, чтобы конечные пользователи могли формировать “продольные и поперечные” срезы данных или уменьшать их объем для более подробного изучения, то есть обеспечивает соответствие самым различным—потребностям в изучении данных как на высшем, так и на самом низовом уровне. Хранилища данных служат функциональной основой для промежуточных сред бизнес-аналитики, которые предоставляют конечным пользователям доступ к отчетам, панелям мониторинга и прочим элементам интерфейса.

Архитектура хранилища данных

Архитектура хранилища данных зависит от потребностей компании. Наиболее распространенными типами архитектур являются следующие.

Эволюция хранилища данных — от анализа данных к ИИ и машинному обучению

Первые хранилища данных появились в конце 1980-х гг., и их задачей было обеспечить обмен данными между операционными БД (БД для поддержки бизнеса) и системами поддержки принятия решения (СППР). Первым хранилищам данных требовалось много копий. Большинство компаний использовали несколько СППР для различных потребностей. Хотя эти СППР обычно использовали одни и те же данные, процессы сбора, очистки и интеграции выполнялись для каждой из них по отдельности.

По мере того как эффективность хранилищ данных росла, они превратились из «складов информации» для поддержки традиционных платформ бизнес-аналитики в обширные аналитические инфраструктуры, которые сегодня обслуживают самые разнообразные потребности компаний, включая операционную аналитику и управление эффективностью.

Эволюция хранилищ данных сделала их важным инструментом для постепенного наращивания бизнес-ценности для предприятия.

На каждом из пяти этапов требуется увеличивать разнообразие наборов данных. На последних трех этапах максимально обширный диапазон данных и аналитических средств является обязательным требованием.

Сегодня технологии ИИ и машинное обучение применяются практически во всех инструментах для промышленности, сферы обслуживания и бизнеса. И хранилища данных не стали исключением. Широкое применение больших данных и внедрение новых цифровых технологий способствуют изменению требований к хранилищам данных и их функциональным возможностям.

Автономные хранилища данных представляют собой наиболее современное решение. Они дают возможность предприятиям извлекать еще больше ценных сведений из данных и в то же время обеспечивают более высокий уровень надежности и эффективности.

Хранилища данных, витрины данных и хранилища операционных данных

Хранилища данных, витрины данных и хранилища операционных данных (ODS) выполняют схожие роли, однако имеют свои отличия. Витрины данных имеют те же функции, что и хранилища данных, однако, как правило, ограничены—одним подразделением или направлением бизнеса. Такая особенность дает возможность создавать витрины легче, чем хранилища данных. Тем не менее использование нескольких витрин может вести к потере целостности данных, так как между ними сложно обеспечить управление данными и контроль.

ODS используются только для поддержки ежедневных операций, поэтому доступ к историческим данным в них весьма ограничен. Они эффективны в качестве источника актуальных сведений и часто используются в этом качестве хранилищами данных, но не поддерживают сложные запросы к историческим данным.

Что такое облачное хранилище данных?

Облачное хранилище данных использует облако для получения и хранения данных из разрозненных источников.

Первоначально хранилища данных создавались на локальных серверах. У таких локальных хранилищ данных и сегодня много преимуществ. В некоторых случаях они могут обеспечивать лучшую управляемость, безопасность и скорость. Однако локальные хранилища данных не настолько гибкие и для них необходимо сложное прогнозирование, чтобы определить, как масштабировать такие хранилища данных для будущих потребностей. Управление такими хранилищами данных тоже может быть непростой задачей.

С другой стороны, облачные хранилища данных отличаются следующими преимуществами.

Лучшие облачные хранилища данных отличает полная управляемость и самоуправляемость, поэтому даже новички могут создавать и начать использовать хранилища данных всего в несколько кликов. Кроме того, в большинстве облачных хранилищ данных используется модель оплаты по мере использования, что обеспечивает дополнительную экономию средств для заказчиков.

Что такое современное хранилище данных?

Разные пользователи в компании, будь то ИТ-группы, инженеры по данным, бизнес-аналитики или специалисты по изучению данных, имеют разные потребности в хранилище данных.

Современная архитектура данных способна удовлетворять разные потребности, предоставляя возможность управления всеми типами данных, нагрузками и аналитикой. Она состоит из эталонных архитектур с необходимыми компонентами, интегрированными для совместной работы в соответствии с лучшими отраслевыми практическими рекомендациями. Современное хранилище данных включает следующее.

Современное хранилище данных может так эффективно оптимизировать рабочие процессы, как ни одно другое хранилище ранее. Это означает, что каждый сотрудник, от аналитика и инженера по обработке данных до специалиста по изучению данных и ИТ-экспертов, может выполнять свою работу более эффективно и заниматься инновациями, помогая компании двигаться вперед без постоянных задержек и излишней сложности.

Проектирование хранилища данных

Проектирование хранилища данных для компании следует начать с определения конкретных бизнес-потребностей, согласования сферы применения и разработки концепции проекта. После этого можно приступать к разработке логической и физической модели хранилища данных. Логическая модель включает в себя взаимосвязи между объектами, в то время как физическая служит для определения оптимального способа хранения и извлечения объектов. Кроме того, она также включает в себя процессы передачи, резервного копирования и восстановления.

При проектировании хранилища данных обязательно нужно учитывать следующие факторы.

Наиболее важным фактором при проектировании является потребность конечных пользователей. Обычно пользователи используют хранилище для анализа, и им нужны данные в обобщенном виде, а не в виде отдельных транзакций. Тем не менее нередко конечные пользователи не знают, какие возможности им нужны до возникновения потребности в них. Таким образом, в процессе планирования необходимо предусмотреть резервные ресурсы для добавления новых возможностей. И наконец, при проектировании хранилища данных необходимо учитывать потребность в расширении по мере развития потребностей конечных пользователей.

Облачные хранилища и хранилища данных

Облачные хранилища данных имеют те же свойства и возможности, что и локальные, а также обеспечивают преимущества облачных вычислений, таких как гибкость, масштабируемость, маневренность, безопасность и экономичность. Использование облачных хранилищ данных дает возможность компаниям полностью сфокусироваться на извлечении полезных сведений из собственных данных вместо того, чтобы заниматься созданием и обслуживанием аппаратной и программной инфраструктуры, необходимой для поддержки хранилища данных.

Зачем нужно озеро данных?

Компании используют озера и хранилища данных для хранения больших объемов данных, полученных из разных источников. Выбор способа хранения зависит от того, как эта компания намеревается использовать данные. Ниже описаны рекомендуемые способы применения каждого из типов хранилищ.

Почему среда OLTP не подходит для аналитики данных?

Хранилища данных представляют собой реляционные среды, которые используют для анализа данных, прежде всего за прошедшие периоды. Компании используют хранилища данных для обнаружения вырабатывающихся со временем закономерностей и взаимосвязей в данных.

В отличие от них транзакционные среды применяются для непрерывной обработки транзакций, то есть ввода заказов и совершения финансовых и розничных операций. В них не используются исторические данные. Более того, в средах OLTP данные за прошедшие периоды обычно архивируют или даже удаляют, чтобы улучшить эффективность.

Хранилища данных и системы OLTP значительно отличаются друг от друга.

Беспроблемное развертывание. Autonomous Data Warehouse

Наиболее современной разновидностью хранилищ данных являются автономные хранилища. В них применяются технологии на основе ИИ и машинного обучения. Это дает возможность устранить потребность в ручном выполнении задач по установке, развертыванию и управлению. Автономные хранилища данных предоставляются в виде облачных сервисов и не требуют вмешательства пользователя для администрирования, настройки аппаратного обеспечения или установки ПО.

Создание хранилища данных, резервное копирование, исправления и обновления, а также увеличение и уменьшение размера базы данных выполняются автоматически.—Это обеспечивает высокие показатели гибкости, масштабируемости, маневренности, безопасности и экономичности, столь популярные в облачных решениях. Использование автономного хранилища данных дает возможность упростить обслуживание, ускорить развертывание и высвободить ресурсы. Так компании могут больше уделять времени на увеличение прибыли.

Oracle Autonomous Data Warehouse

Oracle Autonomous Data Warehouse — простое в использовании, полностью автоматизированное хранилище данных, которое обеспечивает эластичную масштабируемость, быстрое выполнение запросов и не требует администрирования. Настройка Oracle Autonomous Data Warehouse не требует много времени и усилий.

Источник

Виды облачных хранилищ

Зачем мне использовать облачные технологии и какое облачное хранилище выбрать? Наверняка подобными вопросами вы задавались хотя бы раз в жизни. Если нет — самое время разобраться, что представляют из себя облачные хранилища, какое лучше и почему они незаменимы в современном мире.

Что такое облачное хранилище

Чтобы обменяться файлами или сохранить большой объём данных, уже не обязательно использовать флешки, жесткие диски и кабели — они постепенно уходят в прошлое. Необходимость скидывать или скачивать материалы на внешний носитель отпадает, если есть возможность использовать надежное облачное хранилище.

Со стороны любого пользователя облачное хранилище представляет собой обычный интернет-сервис. Вы заходите в интернет, открываете сайт сервиса и можете управлять файлами — загружать, удалять, скачивать. Но на самом деле все материалы и документы хранятся на сервере — удалённом мощном компьютере, который постоянно подключён к интернету. Таким образом, облачное хранилище — это онлайн-хранилище на удаленном сервере,с помощью которого можно хранить, отправлять и получать данные (файлы, цифровые объекты, документы).

Конечно, по эту сторону монитора вся структура сети не видна. Если мы заходим в хранилище, то получаем доступ к «облаку» — одному большому виртуальному серверу. При этом физически этот сервер может состоять из сотен компьютеров, находящихся в разных точках мира. Эта особенность позволяет хранить файлы не на одном, а на нескольких устройствах.

Возможности облачного хранилища

Зачем использовать облачное хранилище, если можно хранить материалы и файлы на личном компьютере или на съёмном диске?

Облачные хранилища позволяют:

Однако, как и любая технология, облачные хранилища имеют некоторые недостатки.

Минусы использования облачных хранилищ:

Хранение данных можно организовать разными способами, поскольку существуют разные типы облачных хранилищ. Хранилища обладают определёнными характеристиками: что хорошо подходит для решения одной задачи, например, совместной работы, будет не совсем удачным для решения другой, допустим, резервного копирования ценной информации. Каждый тип хранилища поддерживает определённую единицу хранения. Давайте посмотрим, какие существуют облачные хранилища.

Типы облачных хранилищ

Облачные диски (блоки)

Облачные диски очень часто путают с сервисами — Dropbox, OneDrive, Google Drive и так далее. Называть эти онлайн-сервисы дисками некорректно, так как их невозможно отформатировать в файловую систему. Облачные диски можно настроить на своём облачном сервере. Дисковое пространство хранилища действительно может быть предоставлено компьютеру через интернет в качестве локального диска. Для этого даже существуют специальные интернет-протоколы. Благодаря им создаются сети хранения данных, например — SAN (Storage Area Network).

Облачные папки (файлы)

Для многих пользователей разница между сетевым диском и папкой незначительна. Однако на уровне работы систем это совершенно разные понятия. Облачные папки — это те самые Dropbox, OneDrive и Облако@mail.ru, которые уже упоминались. Облачная папка — востребованный и полезный ресурс как в налаживании рабочих и бизнес-процессов, так и в частном использовании. Все преимущества облачных папок мы подробно рассмотрим чуть ниже.

СУБД, хранилища данных (наборы данных)

СУБД — система управления базами данных. Наибольшее распространение имеют системы управления на основе специальных SQL-запросов к реляционным базам данных. Реже применяются неструктурированные или мало структурированные базы данных. СУБД принимают запросы и возвращают наборы данных (datasets) — выборки, оформленные в списки и таблицы.

Объектные хранилища (объекты)

Объектные хранилища позволяют хранить файлы вместе с дополнительными сведениями (метаданными). Эти сведения позволяют обрабатывать файлы в качестве прикладных объектов — видеофильмы, товары, проекты, бухгалтерские документы. Для взаимодействия с облачным объектным хранилищем используется программный интерфейс (API), который позволяет записывать объект в хранилище с помощью специальных команд, а не «перетаскиванием». Выбор облачного хранилища зависит от ваших целей и предпочтений. Наиболее «понятным» и часто используемым типом облачного хранилища являются облачные папки. Папки позволяют организовать совместный доступ к файлам и документам. Расскажем о них подробнее.

Облачные папки

Если сервис для хранения данных нужен только в качестве файлообменника, то при выборе сервиса стоит обратить внимание на бесплатный объем хранилища, тарифы и максимальный размер загружаемого файла (в некоторых сервисах есть такое ограничение). Это главные характеристики, но есть и другие, также влияющие на удобство.

Практически все облачные папки поддерживают предварительный просмотр файлов. Однако в каждом конкретном случае под файлами может подразумеваться разное. Например, где-то доступен просмотр только фотографий и документов, а где-то аудио- и видеофайлов. Если это важно для вас, стоит обратить внимание на список поддерживаемых форматов.

Для некоторых сервисов можно подключить услуги повышения безопасности, которые позволяют зашифровать файлы — все материалы становятся доступны только по ключу, расположенному на устройстве.

Определить, подходит ли вам та или иная облачная папка можно оценив следующие параметры: объём бесплатного пространства, дополнительные платные и бесплатные возможности, скорость загрузки/выгрузки файлов.

Кратко рассмотрим самые популярные облачные папки.

Яндекс.Диск

Российский сервис от Яндекса. Основа работы — синхронизация данных между разными устройствами, например, Яндекс. Почтой. Может интегрироваться в офисный пакет Microsoft Office. Есть возможность автоматически загружать видеофайлы и фотографии с цифровых камер в папку.
Объём:

Есть приложения для: Windows, macOS, Linux, iOS, Android, LG Smart TV.
Синхронизация: высокая скорость.
Дополнительные возможности:

Google Drive

Облачная папка для хранения данных от Google. Заточен на интеграцию с другими службами Google Фото, Google Docs и др. Удобен для владельцев устройств на Android — приложение установлено на устройствах изначально. На Google Drive можно хранить 30 типов файлов (музыку, фото, видео). Выдержан в общем стиле Google-сервисов. Заядлым пользователям Google будет привычно и удобно.
Объём:

Есть приложения для: Windows, macOS, iOS, Android.
Синхронизация: высокая скорость.
Дополнительные возможности:

Однако, кроме увеличения доступного дискового пространства, премиум-аккаунт не даёт никаких иных преимуществ: все возможности Google Drive в равной мере доступны всем его пользователям.

OneDrive

Облачный интернет-сервис для хранения файлов и файлообмена от Microsoft. Имеет встроенное в систему приложение «Фото», которое позволяет использовать ОneDrive для синхронизации всех изображений. Также он интегрируется с Office 365, так что создавать и редактировать документы Excel, Word, PowerPoint можно прямо из приложения.

Для пользователей Windows преимущество сервиса Microsoft OneDrive перед аналогами очевидно — его не нужно устанавливать. Также не нужно создавать отдельный аккаунт — для входа в облако достаточно ввести данные своей учётной записи Microsoft.
Объём:

Есть приложения для: Windows, macOS, iOS, Android, Windows Phone, Xbox.
Синхронизация: средняя скорость.
Дополнительные возможности:

В платных версиях:

Dropbox

Старейшее облачное хранилище, на котором можно загружать файлы и обмениваться ими. Работа построена на синхронизации данных. Dropbox рекомендуется использовать в связке с BoxCryptor, который обеспечивает шифрование файлов перед синхронизацией. Это повышает конфиденциальность сервиса.
Простой в использовании, Dropbox работает стабильно и быстро. Переключиться между рабочим и личным облачным пространством можно, не выходя из учётной записи. Для каждого пространства выделено по 2 Гб памяти.

Основное преимущество Dropbox перед конкурентами в том, что при редактировании файлов сервис не копирует их полностью, а передаёт только изменённую часть документа. Это обеспечивает «молниеносную» скорость работы в сравнении с аналогами.
Объём:

Есть приложения для: Windows, macOS, Linux, iOS, Android.
Синхронизация: высокая скорость.
Дополнительные возможности:

В платных версиях:

Облако@mail.ru

Хранилище от компании Mail.Ru Group, которое позволяет хранить и синхронизировать данные на устройствах. Интегрируется с Mail.ru, «Одноклассники» и другими продуктами Mail.Ru. Имеется автозагрузка фотографий со смартфона — сделанные фото сразу же помещаются в хранилище. Имеет удобную программу для просмотра с флеш-плеером.
Объём:

Есть приложения для: Windows, macOS, Linux, iOS, Android, Windows Phone.
Синхронизация: средняя скорость.
Дополнительные возможности: — есть инструмент для мгновенного создания скриншотов и их сохранения в облаке; — организация совместного доступа; — возможность настроить функцию — уведомления об изменениях; — поиск по сервису.
Если вы работаете с хранилищами на разных устройствах, для синхронизации можно использовать как веб-версию, так и клиенты, которые существуют для разных операционных систем. Работает это путём создания локальной папки, содержимое которой синхронизируется с облачной папкой. Такие приложения есть для всех сервисов, о которых идёт речь в статье. Определённые сервисы поддерживают протокол WebDAV, по которому можно подключить хранилище к ПК в качестве сетевого диска.
Теперь вы знаете, какие существуют виды облачного хранилища и можете сделать оптимальный выбор.

Источник

Обзор технологий хранения больших данных. Плюсы, минусы, кому что подойдет

Если вы собираетесь построить или перестроить свое хранилище данных, то столкнетесь с внушительным списком технологий на рынке. Пробовать каждую из них в поисках подходящей именно вам — долго и затратно.

На нашей конференции SmartData ведущий разработчик в Яндексе Максим Стаценко рассказал про плюсы и минусы различных решений для хранения данных: облака или железо, Hadoop, Vertica, ClickHouse, Exasol, Greenplum, Teradata и не только.

Работая в крупных компаниях, Максим попробовал много решений, сравнил их на одинаковых данных и задал вопросы их разработчикам и поставщикам.

Видео и расшифровка доклада — под катом. Далее повествование будет от лица Максима.

Мой доклад ориентирован на людей, которые начинают строить хранилище данных либо задумываются о том, как его переделать, а также на junior-разработчиков, только планирующих стать дата-инженерами. Я сконцентрируюсь на том, как бы я выбирал решения и как хранить данные.

О чем и зачем этот доклад?

Рассказать о технологиях, о которых говорят меньше, чем о хайповых технологиях

Поделиться опытом, полученным в рамках PoC (proof of concept) на большом объеме данных

Поделиться опытом принятия решений, как и где строить хранилище.

Перейдем к тому, что же побудило меня прочитать этот доклад. Кроме работы я преподавал в вузах: МГУ, Бауманке. Так у меня появилось много знакомых, которые любят создавать стартапы или работать в маленьких организациях. Периодически они приходят ко мне и говорят: «Макс, мы хотим создать хранилище или хотим переделать наше хранилище, потому что оно не удовлетворяет нашим требованиям».

Общаясь с ними, я понял, что есть популярные универсальные решения, про которые знают все, а мне хочется рассказать, что есть хорошие большие решения, о которых у нас знают меньше, и поделиться опытом проведения proof of concept в Mail.ru. Мы проводили proof of concept на терабайтах данных кликстрима, и с нами активно работали вендоры различного программного обеспечения.

Разберем план моего доклада. Сначала мы решим, где разворачивать наше хранилище: в облаке или на железе. Потом выберем технологию для хранения данных, затем обсудим то, что не влезло в доклад, и почему я не пытался впихнуть это в презентацию.

Что мы строим?

Мы строим аналитическое хранилище данных. В моем видении аналитическое хранилище данных в первую очередь ориентировано на людей.

Сотрудники должны иметь доступ к данным 24/7. В вашем сервисе может что-то пойти не так в любой момент времени. Аналитики — это люди, которые могут объяснить, почему у вас внезапно просели продажи, почему на сайт перестали приходить люди, почему упала рекламная выручка. Если у вас сработал мониторинг, то аналитик подключится и будет разбираться с проблемой.

Когда вы вырастете (или уже выросли), вам придется разграничивать доступ к данным. Вы не захотите, чтобы junior-разработчик имел доступ к зарплатам сотрудников, затратам и т. д.

Доступ должен быть BI. Я часто привожу пример с мобильным телефоном. Если вы хотите посмотреть, сколько времени в часах осталось работать вашему телефону, вам не нужно писать код на Python, вы просто заходите в меню и смотрите. В бизнесе основные метрики должны быть доступны точно так же, чтобы люди, у которых нет времени и навыков программирования, могли посмотреть ключевые показатели и провести несложную аналитику.

Еще одна важная вещь: аналитическое хранилище данных появляется, когда ваш сервис уже вырос из SMP-системы. Стандартный процесс роста аналитической системы:

Мы живем на той же базе, что и прод.

Аналитики начинают мешать проду по производительности, делают реплику.

Реплика не справляется по производительности.

Начинаем задумываться о переходе на другое решение.

Специфика современности

То, что я сейчас рассказал, было актуально и 30, и 20 лет назад. Но сейчас на дворе 2020 год, и несмотря на коронавирус и прочие проблемы, есть определенные особенности. Дальше я приведу свой чек-лист, на который я смотрю, когда принимаю решения об архитектуре хранилищ.

Первое, о чем бы я советовал помнить при построении аналитических хранилищ, — с 2000 года количество данных начало расти гораздо быстрее, чем вычислительные мощности. Как следствие, старые подходы больше не работают. А SMP-системы были придуманы в 70–80е года, и они немного не подходят под эту парадигму.

Третий критерий выбора — сложность найма сотрудников. Де-факто SQL, Python/R — это стандарты доступа к данным. Если для вашей системы нужны будут более специфические навыки, то найти специалистов будет сложнее. Например, если вы захотите нанять C++ разработчика, который будет писать ETL, то будете страдать и предлагать большие деньги. А разработчики будут говорить: «Что? Я буду «прокидывать» поля на C++, обрабатывать логи? Нет, это не интересно». Это мой опыт, и я вам не советую его повторять.

Четвертый фактор, влияющий на принятие решения — это машинное обучение, которое находится на вершине своего хайпа. Это очень популярная технология, на это тоже смотрят и вендоры. Сейчас странно начинать бизнес и не пытаться предсказать вашу выручку, затраты, спрос. Важно следить за тем, чтобы ваше аналитическое хранилище имело возможность предоставлять данные для машинного обучения.

Наконец, нюанс, о котором часто забывают, — проектирование системы. Многие не думают о том, что хороший аналитик сейчас достает не только те данные, которые есть в хранилище. Он может купить данные в других компаниях, скачать их в интернете, пойти к вашему бэкенд-разработчику и попросить достать их из логов. Не важно как, но когда он собрал данные, которые, как ему кажется, решат его задачу, нужно, чтобы эти данные взаимодействовали с данными из хранилища.

Если мы посмотрим старый пайплайн, то для решения этой задачи он попросил бы дата-инженера залить данные в хранилище и разложить их так, чтобы они лежали в третьей нормальной форме и чтобы все могли ими пользоваться. А значит, он поставит задачу в JIRA, которая уходит в бэклог. Дальше аналитик ждет, когда придут данные. Когда у вас много хороших аналитиков, бэклог разрастается, дата-инженеры страдают, а процессы движутся медленно. Кажется, что все было бы лучше, если бы аналитики могли бы сами загружать такие «одноразовые» и абы как структурированные данные.

Сейчас такие возможности есть, благодаря чему упрощается проведение экспериментов, проверка гипотез и выкатка MVP, так как больше не нужно привлекать дата-инженеров, чтобы добавить в хранилище данные, которые, может быть, больше никогда не понадобятся.

Хранение данных в Storage

На слайде ниже я широкими мазками нарисовал схему аналитического хранилища данных. Шина данных — это интерфейс, через который данные поступают в хранилище, а UI и ETL Manager управляют данными и предоставляют к ним доступ.

Схема аналитического хранилища данных

Мы сфокусируемся на Storage. Схема простая, но если присмотреться, она может оказаться и сложнее.

Здесь я нарисовал широкую схему лямбда-хранилища, где у вас есть:

база данных, в которую вы закидываете предпосчитанные агрегаты;

облако в S3, куда вы помещаете старые данные.

Варианты, где строить

Глобально есть пять вариантов, где строить наше DWH. Первые три варианта я буду объединять в группу «Ваш собственный сервер».

Сервер в кладовке, то есть в собственной серверной

Аренда стойки в дата-центре

Аренда виртуальной машины в облаке

Managed Services в облаке.

Последний вариант очень классный. Я открыл его для себя недавно, года два назад. Managed Services появились сейчас и в российских, и в зарубежных облаках. Вы заказываете не сервер, а необходимое программное решение.

Например, вам интересен кластер Hadoop с Zeppelin, Spark и всем прочим. Открываете интерфейс и накликиваете, например, 16 нод Hadoop, в каждой ноде по 1 ТБ данных, определенное количество CPU. Нажимаете на кнопку — и всё появилось.

Так же работает ClickHouse или любой другой сервис, который поддерживает выбранный вами вендор и облако. Таким образом вы получаете систему аналитики данных, по крайней мере, инфраструктуру под нее, точно так же, как вы заказываете еду на своем мобильном телефоне.

Далее у меня будет много консультационных слайдов. Я не буду проходить по всей таблице, но рассмотрю только некоторые пункты. Я пометил знаком доллара в таблице скрытые траты, о которых не стоит забывать, когда вы выбираете, где хранить данные.

Первая важная вещь: если вы разворачиваете кластерное решение сами, то вам нужен очень хороший админ. Например, есть очень неприятная задача — обновление программного обеспечения кластера. Если вы не хотите допускать даунтайм вашего решения, то вам нужно брать кусок нод, выводить их из ротации. При этом вы должны убедиться, что у вас в ротации осталась хотя бы одна реплика всех данных. Далее вы накатываете новую версию софта, возвращаете в ротацию. Если случится так, что ваша база данных не поедет с новой версией, то откатывать придется точно так же.

Когда вы выбираете решение, не стоит забывать о реакции на аварии и мониторинге.

Во-первых, если у вас собственный сервер, то вам придется подумать о возможности выхода из строя каких-то железных компонентов. Например, у вас может полететь диск, а если у вас большой кластер, то диски будут лететь почти каждый день. У вас может отказать сеть, может пойти что-то не так со свичами.

Чем больше решение завязано на вас, тем больше этих проблем на вас ляжет. Вам нужно будет это решать, предугадывать, закупать заранее диски и свичи, если вы расширяете свои личные дата-центры или даже маленькую серверную. Все эти проблемы нужно решать, и чем больше ответственности вы перекладываете на облако, тем больше рутины будут делать за вас. Это достаточно удобно. Лично я, поскольку вырос из разработчика, не люблю настраивать и реагировать на «железные» аварии, поэтому люблю облака.

Еще одна важная вещь — это мониторинги. Если вы сами сетапите ваш сервер, вам придется самим придумывать систему мониторинга, отслеживать, что у вас максимальная нагрузка на CPU или же легла база данных, или нода Hadoop вышла из ротации, писать об этом сообщения в Telegram, рисовать дашборды. И если вы поднимете виртуалку, то скорее всего, эту работу вам тоже придется делать самим. При использовании managed-сервисов базовые метрики будут сделаны за вас. Появится страница, на которой всегда можно будет посмотреть, что происходит. Самое главное, кто-то отреагирует за вас и скажет: «О, у нас упал кластер Hadoop, давайте срочно его чинить». Вы, скорее всего, даже не заметите этого.

Мое мнение

Сразу скажу, это только мое мнение, мой опыт. Возможно, у кого-то из вас другой опыт. Собственное железо дает психологическое спокойствие и спокойствие вашего офицера безопасности. По опыту Mail.ru или Министерства образования я знаю, что адаптировать облачное решение под требования офицера безопасности очень тяжело. В конце концов офицер безопасности говорит: «Я хочу, чтобы доступ на сервер был только через решение Cisco, при этом вы должны авторизоваться через SMS и сессия не должна длиться более 30 минут». Из коробки ни один вендор облака не даст такое решение, и вам придется разговаривать с ним отдельно. На своем сервере вы сможете настроить всё что угодно.

Вторая вещь — это чувствительность данных в вашей инфраструктуре. Я немного параноик и очень переживаю, что данные могут утечь. Когда ты сам отвечаешь за них, то немного спокойнее, потому что можно на ночь отключить провод Ethernet от сервера, и никто не залезет в базу. Доступ к серверу, если он хорошо настроен, есть только у твоих сотрудников. Такие вещи придают спокойствие, но в то же время в облачных решениях давно придумали и применяют современные технологии, которые обеспечивают безопасность на высоком уровне. Но психологически иметь свои чувствительные данные как-то надежнее и приятнее.

Кроме того, когда вы выбираете вендора, лучше спросить, все ли ресурсы ваши. Хоть эта история становится всё менее актуальной, перестраховаться всё же стоит. Раньше вендоры закладывались на то, что вы не сможете занять все забронированные вами ресурсы. Это работает как овербукинг на самолетных рейсах. Вендор продает мощностей больше, чем у его есть на самом деле, надеясь на то, что никто из клиентов не будет использовать свои ресурсы на 100%. И если вам не повезет, то ресурсы достанутся процессам, которых их заняли первыми, а ваши задачи будут работать на остаточных мощностях или вообще будут висеть в очереди. Например, вам предлагают 128 Гб оперативной памяти, когда фактически у вендора всего 64 свободных Гб. Неприятная ситуация, современные вендоры с этим борются. Но стоит обсудить, как они гарантируют квоту и всегда ли вы сможете получить доступ ко всем ресурсам, которые вы купили.

Что касается своего железа, то оно более привычно для пользователей. Но к плюсам виртуалок можно отнести их гибкость и простоту. Приведу два примера.

Допустим, у вас есть большое хранилище, и вы хотите попробовать перевести его на другую технологию, скажем, на ClickHouse. Если у вас свое железо, то вам нужно найти другие серверы. Если их нет, то купить, подождать, пока они приедут, поставить ClickHouse, залить данные. А если ClickHouse вам не понравился, то что делать с купленными серверами? В облаке же вы можете загрузить данные, недельку поиграть, удалить весь этот кластер и быстро разобраться, нужен ли вам ClickHouse.

Второй пример — кейс моих знакомых. Для своей фирмы они наняли специалиста по машинному обучению, которого попросили прогнозировать спрос. Это была сторонняя контора, она начала активно учить свои модели и загрузила аналитическую систему «в потолок» так, что никто кроме них самих не смог работать. Тогда они в облаке просто скопировали свой кластер со спросом и всеми данными и сказали: «Вот вам данные, обучайтесь, туда никто не будет ходить, а аналитика продолжит работать в реальной системе». Когда модель фирмы-подрядчика показала хороший результат, ее начали интегрировать в общую аналитическую систему и увеличивать ресурсы системы под хорошую модель. Так вы получаете гибкость — можно скопировать данные и передать их подрядчику.

И последняя плюшка виртуалки — перевод рутины на других людей. За настройку безопасности и реакцию на аварии будут отвечать специальные сотрудники.

Проблемы облака за пределами РФ

В целом они связаны с законодательством и возможными скрытыми тратами на сеть, если вы загружаете данные из облака или в него.

Согласно постановлению Правительства Российской Федерации № 728 от от 26 июня 2018 года, храним данные пользователей на территории РФ.

Федеральный закон «О персональных данных» от 27 июля 2006 года (№ 152-ФЗ) содержит нормативы, как безопасно хранить данные. Трансграничная передача персональных данных на территории иностранных государств может быть запрещена или ограничена.

Не везде есть русскоязычная поддержка — повышается стоимость специалистов, которые будут работать с облаком.

Валютные риски: стоимость услуг зависит от курса рубля. Стоимость инфраструктуры может удвоиться, как это случилось, когда курс доллара вырос в два раза.

Если надо заливать и выгружать большие объемы данных, то нужен хороший канал. Чем больше точек связности между двумя машинами, тем меньше вероятность, что будет хороший канал.

Стоимость канала до европейского ЦОД может быть равна стоимости ресурсов для проекта DWH в облаках РФ.

Выбор программного продукта

Перейдем к MPP-системам (англ. massive parallel processing). Мне придется немного побыть Капитаном Очевидность, но несколько раз мне лично пришлось доказывать нескольким финансовым директорам, что ценник за продукт — это не вся цена, которую придется заплатить. Я очень люблю Hadoop, но в этом докладе буду его активно хейтить и шеймить. Hadoop можно получить бесплатно, но придется потратить кучу сил, чтобы заставить его нормально работать. Можно купить коробочное решение, за него придется заплатить, но сравнивая с годом-двумя поддержки Hadoop, оно может оказаться намного дешевле.

Еще советую не ориентироваться на тендеры, а проводить proof of concept. Тендеры, отзывы, советы экспертов предвзяты. У вашего бизнеса свои особенности, собственный паттерн использования данных. Поговорите с вендором продукта, попросите его дать вам попробовать продукт. Как правило, можно договориться о триале на месяц или два, вы загрузите туда данные, погоняете на своих запросах и поймете, подходит ли вам это решение или нет.

Может оказаться так, что супернепопулярное решение выстрелит именно в вашем случае. Самый простой пример — автомобиль Лада, который нигде не нужен за пределами РФ, а у нас Лада — популярный продукт, так как его можно починить молотком и кувалдой. Все системы, о которых буду рассказывать дальше, — MPP. На схеме ниже они показаны справа, а слева — более архаичные SMP-системы (англ. symmetric multiprocessing).

Как видите, в MPP-системах мы стараемся хранить данные раздельно. На каждой ноде кусочек данных: от A до F, от G до R, от S до Z. При этом каждая нода старается обрабатывать свой кусочек данных, не заглядывая в чужие. В каких-то кейсах, например, при неудачных джойнах, происходит обмен данными между нодами, и дальше повторяется процесс, где каждая нода пытается обрабатывать только свой кусок. Это хорошо тем, что легко произвести масштабирование в ширину. Это проще и дешевле, чем масштабирование в высоту, поскольку так мы упираемся в некий потолок производительности.

Давайте посмотрим на несколько решений. Для каждого из них я расскажу про его QUERY LANGUAGE, про транзакционность, наличие точки отказа и наличие или отсутствие бесплатной версии. Также я расскажу о том, что отличает это решение от остальных.

Почему эти четыре пункта

SQL — не самое современное решение, но оно же — порог входа. Курсов по SQL очень много, почти все умеют писать на SQL, и вам гораздо проще найти людей. Поверьте, это важно.

Транзакции — это возможность пользователям не мешать друг другу и сохранять целостность данных. Допустим, у вас есть операция по переводу денег со счета на счет. При определенном хранении данных это две операции: списать деньги со счета и записать деньги на другой счет. Если у вас не произойдет одна из операций, то вторую тоже надо отменить. В таком случае операции объединяют в блоки, и такой блок операций называется транзакцией.

Наличие выделенной ноды для меня лично очень важно, поскольку это сигнал, что в системе есть узкое место. Если вы станете большими и у вас будет много пользователей, это место может начать не справляться, и вы с этим ничего не сделаете.

Платное/бесплатное — тут понятно, деньги интересуют всех.

Перед тем как показать табличку, я расскажу про Hadoop. Я очень люблю Hadoop, потому что это комбайн, в нем можно делать все. В нём есть SQL, транзакции, возможность сохранения данных удобным способом, ML из коробки. Можно писать низкоуровнево, сохранять в облаке, в общем, делать всё, что хотите.

Но де-факто Hadoop — это боль.

Первое, что ее вызывает — безопасность. За безопасность в Hadoop отвечает Kerberos (есть и другие решения, но это — самое популярное). Накатывание Kerberos на кластер у всех, кого я знаю, превращается в целый проект, который занимает квартал, полгода, и при этом вы будете решать проблемы, про часть из которых не написано даже на Stack Overflow. В архитектуре Hadoop ваш пользователь записан в переменную окружения. Если вы хотите стать админом, то вы просто пишете в консоли: set HADOOP_USER=“admin” и получаете доступ ко всем данным на кластере. Естественно, ни о какой безопасности тут речи не идет, и нужно устанавливать другие дополнительные системы, например, Kerberos.

Второе — в Hadoop есть платные и бесплатные сборки. Если вы выбрали путь бесплатной сборки, Vanilla Hadoop, то, скорее всего, там будет много багов. Например, мы обновили Hive, и в нем обнаружился баг: если у вас есть JOIN типа поле из одной таблицы равно COALESCE поля из другой таблицы, то оно просто не срабатывало. Это условие не выполнялось, и JOIN работал некорректно. Но мы были крутой командой Java-разработчиков, что нам стоило пофиксить Java-код Hadoop? Мы месяц ковырялись в исходниках Hadoop. В итоге нашли и пофиксили проблему, но это заняло месяц, поскольку делали это впервые. Пока мы этим занимались, наши аналитики нашли еще одну проблему. Когда мы представили, что нам придется еще раз пройти весь этот путь, мы сделали страничку на Wiki, где описали, как делать нельзя. Конечно, кто-то всё равно так делал, получал неправильные результаты, в целом — такое себе решение.

Еще одна боль в Hadoop — разделение ресурсов, оно есть в очень грубом варианте, это очереди YARN или отдельные инстансы Spark. Это не лучшее решение, которое имеет много неприятных нюансов.

Нет BI с быстрым откликом — думаю, все это знают.

Если вы хотите взять данные в Spark или Hive из JDBC-базы и загрузить их в Hadoop и проработать, то, скорее всего, вам нужно будет взять Sqoop или подключать JDBC-коннектор в Spark.

NameNode — узкое место. Я расскажу вам, как джун положил наш Hadoop-кластер. Он много ходил на курсы, разбирался с Hadoop. Там он узнал, что классно складывать данные в отдельные бакеты, кластеризируя их по полю. В рамках запроса он сделал кластеризацию по полю с миллионом уникальных значений так, чтобы каждое уникальное значение помещалось в отдельный файл. Hadoop начал работать очень медленно. У нас не было мониторингов, которые говорили бы, что в Hadoop увеличилось количество файлов. Мы долго разбирались и только в конце дня поняли, что у нас медленно отвечает NameNode, потому как в одной директории появились миллионы файлов размером по 16 Кб. В Hadoop от этого никак не защититься.

Многие считают Hadoop исчадием ада. Наверное, Hadoop — самый простой вариант. Я не знаю систем, которые так же легко запускаются, но я знаю более эффективные. Teradata (о которой речь пойдет ниже) тоже неплохо работает, она может затянуть неструктурированные и неоптимизированные данные из S3 и дальше обработать их за счет адаптивного оптимизатора. И это будет как минимум не медленнее, чем в Hadoop.

В то же время Hadoop и Spark классные. Hadoop — сложный инструмент, который тяжело поддерживать, но открывающий большие возможности. Я бы сравнил Hadoop с языком С, где вы сможете написать любую сложную программу эффективно, но при этом вы с очень высокой вероятностью ошибетесь.

Я работал с Hadoop, ClickHouse, Greenplum, Teradata, Exasol, Vertica. В первой таблице указаны в основном технические характеристики. Остановлюсь на особой важности Storage Type. Есть два Storage Type — колоночное и построчное хранилище. Колоночное хранилище в среднем быстрее дает селект данных и лучше сжимает данные. Для долгого хранения оно подходит больше. При этом ставить данные в колоночное хранилище — это более долгая операция. В случае построчного хранилища вам не нужно проводить сложные операции для вставки данных. Но каждый раз, когда вы прочитали ряд, вам нужно сделать операцию seek, пока вы не дойдете до нужной колонки. Если в колоночном хранилище вы выполняете ее один раз, чтобы дойти до нужной колонки, то в случае построчного вам нужно делать seek для каждой строки.

Еще одна важная вещь — наличие UDF-функций. Тут нужно смотреть, насколько широкие возможности дает тот язык, на котором можно писать собственные функции для хранилища. Многие поддерживают Python, у Greenplum есть PL/SQL, у ClickHouse — расширенный синтаксис SQL. Exasol умеет в Lua, Vertica — в Python, C++ и не только. В последней, если вы написали UDF на C++, то она запускается внутри базы данных, не поднимаются JRE и питоновский исполнитель, а просто происходит нативный процесс.

Дальше я поделюсь моим опытом работы с системами и своим взглядом на них. Информацию о пользователях системы я брал не с официальных сайтов вендоров, а из открытых источников, где сами пользователи рассказывают о своем опыте. Мне кажется, так будет более честно.

ClickHouse

Достаточно новая база, публичная версия вышла в 2016 году. Зародилась она в Яндекс.Метрике, стала дико популярной. Откуда такая популярность?

Человечество тяготело к матрицам и матричным вычислениям, даже когда не было компьютеров. Математики занимались линейной алгеброй. Так у нее появился хороший математический аппарат, и в 60–70е годы ей стали заниматься только появляющиеся программисты. Сейчас машинное обучение любят проводить на GPU-процессорах.

Почему видеокарточка для игрушек подошла для машинного обучения? Дело в том, что визуализация изображения — это тоже матричные операции, и видеокарта хорошо их выполняет. В машинном обучении тоже много матричных операций. Создатели ClickHouse написали на С++ все операции, которые производятся векторизованно. Это позволяет хорошо распараллелить и очень быстро их проводить. Система немного другая логически и иногда позволяет достичь очень крутых результатов.

И еще одна особенность. Синтаксис SQL немного урезан от классического для оптимизации под матричные векторизованные процессы. Взамен вам предлагают много функций, например, лямбда-функции над массивами, которые являются стандартным типом в ClickHouse. Это своеобразная, но очень быстрая система. Как-то раз я встречался с руководителем технического департамента одного банка, он говорил: «Мы тут ClickHouse взяли, но используем его, чтобы парсить JSON, а далее загружаем его в наше хранилище». Потом мы сами стали использовать ClickHouse, когда парсим JSON, так как он написан на С++ и все операции проходят в нем очень быстро.

Greenplum

В опенсорсе с 2015 года; предыдущие версии — с 2005 года.

Это, наверное, самая логичная по своей эволюции база данных. Представим, что вам не хватает вашей SMP-системы для хранения данных. В Greenplum решили сделать MPP-систему, которая состояла бы из кучи маленьких стоящих рядом SMP-систем. Конкретно в случае GreenPlum в качестве основы использовался PostgreSQL. Фактически Greenplum — это толпа PostgreSQL, которые пытаются обработать ваши запросы, под капотом раскидывая данные и задачи обработки между собой. Почти все, что у вас работает под PostgreSQL, вы можете адаптировать под Greenplum; и для многих внешних систем Greenplum выглядит как большой PostgreSQL. Сложности известны, их решения тоже есть, но отметим один неприятный нюанс: Greenplum часто базируется на старых PostgreSQL, поэтому будьте внимательны.

Exasol

На рынке с 2000 года.

Exasol — не очень раскрученная БД. Она выросла из SMP базы данных Oracle. Когда Oracle перестало хватать на OLAP-обработку, ребята написали Exasol. Он работает на своей операционке, и это одна из БД, которые пытаются автоматизировать часть работы.

В частности они пытаются автоматизировать работу с индексами. Индексы помогают ускорить работу БД, но они специфичны для каждого запроса. Вы не можете создать всевозможные индексы, так как индекс имеет свою накладную стоимость на вставку данных. Когда вы вставляете данные, вы должны вставить их в каждый из индексов. Индексы иногда надо пересортировывать или балансировать, а это дорогостоящая операция.

Проблема в том, что направления бизнесов меняются. Если вы один раз спроектировали БД, создали индексы под текущие запросы аналитиков, отвечающих на требования бизнеса, то когда через полгода ваш бизнес и запросы аналитиков чуть-чуть поменяются, база будет работать не так эффективно. Вам придется запрашивать администратора БД, чтобы он создал новые индексы.

Exasol делает это автоматически. Он смотрит, какие индексы перестали использоваться, удаляет их. Если видит, что какой-то запрос стал частотным и его можно оптимизировать за счет индексов, он их сам поднимает и создает. В этом плане Exasol очень удобен.

Многие мои коллеги считают, что технология AI DBA немного закрытая, это уникальное торговое предложение коллег из Exasol. Они не раскрывают многие секреты, поэтому это кажется «черным ящиком», примерно как и нейросети. В них вы можете посмотреть, какой нейрон активируется на какое изображение. Однако вы не можете сказать, что понимаете, как думает нейросеть.

Если написать какой-то неправильный запрос в Exasol и запустить его много раз, то пострадает не всё, так как индексы имеют какой-то вес и Exasol старается решать задачу по оптимизации. Но если пользователь написал плохой запрос и будет часто его запускать, то система настроится так, чтобы работать быстро. Что касается монетизации, тарифицироваться будут либо сырые данные, которые загружаются в систему, либо оперативная память.

Vertica

На рынке с 2005 года.

Большая компания, представленная и в РФ, и во всем мире. Для меня в Vertica нет ощущения магии. Она производит впечатление понятного надежного инструмента.

Приведу аналогию с коробками передач машин Формулы-1 и машин 24 часов Ле-Мана. Коробка передач в Формуле-1 очень хитрая, она позволяет переключение без смены оборотов двигателя. Коробка машин 24 часов Ле-Мана — это классическая секвентальная коробка, у которой есть очевидный паттерн работы, куда добавлена автоматика. При этом коробка Формулы-1, хоть и выдает космические скорости, предназначена для коротких гонок.

Коробка машин 24 часов Ле-Мана надежная, быстро чинится и ездит в режиме 24 часов. Vertica можно сравнить как раз с такой коробкой. Ее простота в том, что легко понять, как она оптимизирует вычисления. Методы оптимизации: предподсчет агрегатов, оптимизация под Merge Join (джойн за линейное время) и фильтры Блума, то есть ускоренная фильтрация. Логика понятна, и если что-то пойдет не так, вы легко напишете workaround, который позволит вам дождаться, когда коллеги пофиксят проблему.

Teradata

На рынке MPP-систем с 1984 года.

Особенность Teradata — отсутствие универсальных хранилищ. Табличные данные хранятся в одном движке, time series — в другом движке, графы — где-то еще. Есть отдельные процессы для обработки ML, графовых данных. Это позволяет хорошо оптимизироваться. Если ваш запрос не самый оптимальный, система будет пытаться оптимизировать его на ходу и обойти ситуативные кейсы. Если кластер Teradata нагружен, и план выполнения запроса не самый оптимальный, она попытается перестроить его под текущие реалии. У Teradata крупные заказчики, поэтому она высоконадежна. Ее экосистема очень удобна: вы можете настроить под Teradata оркестратор или UI, который позволяет ее администрировать.

Мои ассоциации с каждой системой: Exasol — магия, Teradata — надежный инструмент, ClickHouse — хакерский инструмент, Vertica — швейцарские часы, Greenplum — большой PostgreSQL, Hadoop — черная дыра или НЛО.

Мои ассоциации

Я рассказал только о тех решениях, с которыми работал сам. Есть еще много других: MongoDB, Exadata, SAP HANA, Druid, MemSQL, Tarantool, Qlik.

Важно: если вы выбрали систему, общайтесь с ее представителем. Когда я только начинал общаться с вендорами, мне казалось, что это бесполезно. Как разработчику, выросшему в 90-е, мне казалось, что они предложат купить купоны и продать их коллегам, тогда они дополнительно дадут мне удвоенные купоны.

Но на самом деле модель бизнеса сильно поменялась, и коллеги из вендоров открыто общаются, говорят о слабых и сильных местах системы и даже дают контакты других пользователей, которые могут честно рассказать вам о своем опыте. Например, когда мы тестировали Exasol, нам дали контакты Badoo, мы пообщались и что-то узнали про эту систему.

Общаясь с представителем, вы можете получить скидку или триальную версию для PoC.

Советы

Соблюдайте логику хранения данных

Нельзя взять способ, которым вы хранили данные в Hadoop, и перенести его, например, в Vertica. Каждая система адаптирована под определенное хранение данных. Это могут быть широкие таблицы, звезда-снежинка, Data Vault, Anchor, третья нормальная форма или гибридная модель. Поэтому адаптируйте архитектуру под продукты и задачи и смотрите, что лучше подходит.

Поделюсь моими историями успеха. Для Oracle и PostgreSQL лучше всего подходит третья нормальная форма, для ClickHouse — широкие таблицы. Vertica и Exasol очень хорошо работают с Data Vault. Ходят слухи, что Vertica круто работает с Anchor. Но мы столкнулись с тем, что с Anchor у каждой сущности появляется еще один интовый ключ. На ClickStream было много значений, и Anchor сильно увеличил объем хранимых данных. Пришлось вместо Anchor воспользоваться Data Vault, который позволяет сократить потребление данных. В Hadoop и Teradata хорошо работали вещи, близкие к третьей нормальной форме.

Выберите Spare Parts: шину данных, UI и ETL Manager

История про UI. Коллеги построили хранилище данных и выбрали UI в виде табло. Все были довольны, пока в компанию не пришел новый CEO. Он сказал: «Ваше табло мне не нравится, я привык к Power BI». Поскольку ребята хорошо построили систему, то переключение с табло на Power BI произошло достаточно быстро. Хорошее хранилище должно позволять подключить любой интерфейс, который является более или менее стандартным. Если аналитик считает, что ему удобно пользоваться табло, значит, нужно подключить табло. Если ему нравится Power BI, значит, нужно подключить его. Для этого есть стандартные протоколы, например, JDBC, есть система, которая поддерживает большинство стандартных UI. Обращайте на это внимание, но это не краеугольный камень. Скорее смотрите, чтобы можно было переключиться.

ETL-менеджер может развиваться динамически. Большинство из нас начинало свой ETL как набор задач в cron. Потом это становится трудно мониторить, и вы переходите на Airflow, Luigi, оркестратор Teradata, на что-то другое. Шина данных позволяет стандартизированно загружать данные в хранилище. Вещь важная, поскольку если вы не заложите ее в начале проектирования системы, то однажды поймете, что новых данных все больше и вам нужен какой-то стандарт для единого протокола загрузки в хранилище. Тогда окажется, что в ядре продукта есть логи, которые никто не хочет переделывать. Вам постоянно придется поддерживать это легаси, которое будет тянуться и тянуться, что весьма неприятно. Лучше ее проектировать сразу, хотя шину данных всегда можно поменять. А поменять хранилище тяжело и дорого.

Не бойтесь совмещать технологии

Вы можете использовать для хранения неструктурированных данных тот же Hadoop или S3 и загружать свои данные в другую базу данных. Если у вас есть специфические интерфейсы, например, для OLAP, то можно использовать дополнительные системы. Есть система Apache Kylin, которая работает с HBase в Hadoop и позволяет вам строить OLAP-кубики для стандартных OLAP-интерфейсов. Выбирайте и комбинируйте.

Есть популярный паттерн, когда на стандартную систему вроде Exasol и Vertica накладывается классическая SMP-система OLTP, в которую складываются подсчитанные данные, а далее из этой системы выдаются ответы. Например, если у вас есть личный кабинет клиента, то под него больше подойдет OLTP-система, в которой он будет смотреть отчеты. Сложные системы тяжелы в поддержке, но это компенсируется их плюсами. Нет системы, идеально решающей все задачи. Если у вас есть несколько популярных задач, будьте готовы, что под них нужно адаптировать разные системы.

Вывод

Если у вас нет DWH, то простой MVP можно накликать в облаке. Вы выбираете продукт, который поддерживается managed-сервисом, тот же Hadoop, и у вас уже есть какое-то хранилище. Попробуйте, и вы поймете, что это лучше, чем без хранилища.

Если вас не устраивает ваше DWH, попробуйте посмотреть на технологии вокруг. Для нас это был стресс. Я помню, каким для меня было вызовом, когда мне сказали: «Твой бесплатный Hadoop работает плохо, давайте посмотрим, какие есть платные хорошие решения». Я в ответ: «Что? Мой Hadoop? Да я сейчас напишу на Spark, всё будет работать очень быстро». Но я благодарен своим руководителям за то, что они предложили погонять PoC, и я понял, что коробочные решения могут делать гораздо быстрее и надежнее, чем Hadoop, который нужно настраивать несколько месяцев под одну задачу. Смотрите вокруг, ищите что-то хорошее, читайте Хабр и Medium. Иногда даже специфические продукты взлетают.

А есть ли у вас аналитическое хранилище данных? Где вы располагаете свою инфраструктуру хранилища? Поделитесь опытом в комментариях.

Это был доклад со SmartData 2020 — а мы тем временем вовсю готовим SmartData 2021, которая пройдет с 11 по 14 октября онлайн. Программа еще составляется, но если вас заинтересовал этот пост — вероятно, среди новых докладов вы тоже обнаружите много интересного вам. В таком случае есть смысл обратить внимание уже сейчас: билеты со временем дорожают.

Источник