storage что это в компьютере
Немного о Storage Class Memory
За все время существования теории вычислительных машин и систем справедливым оставалось одно утверждение: процессоры гораздо более производительные и дорогие, чем устройства хранения данных. Тот факт, что CPU способен обслуживать множество запоминающих устройств разом, оказал значительное влияние на разработку аппаратного и программного обеспечения для систем самых разных размеров.
Действительно, в таких книгах, как «Вычислительные системы: взгляд программиста» («Computer Systems: A Programmer’s Perspective») Рандала Брайанта (Randal Bryant) и Дэвида О’Халларона (David O’Hallaron) делается упор на иерархию памяти и её влияние на разрабатываемые программы.
Однако дата-центрам и разработчикам ПО нужно готовиться к грядущим изменениям. Появление высокоскоростных энергонезависимых устройств хранения информации, обычно называемых аббревиатурой SCM (Storage Class Memories), пошатнет привычные устои. SCM постепенно набирают популярность, однако для работы с ними требуется выделять один или сразу несколько многоядерных процессоров, чтобы совладать с их производительностью (сотни тысяч IOPS).
Скорость работы долговременных хранилищ всегда была сильно ниже, чем скорость работы CPU, и эта разница только увеличилась за период с начала 90-х до начала 00-х годов. Процессоры стабильно улучшались и совершенствовались, а производительность механических дисков оставалась неизменной – развитию препятствовала физика. На протяжении десятилетий, чтобы сократить этот разрыв и избежать простоев процессора, придумывались различные схемы и методики.
Одним из способов является кэширование. В современных системах кэширование выполняется на всех системных уровнях: процессор кэширует RAM, операционные системы кэшируют целые дисковые секторы и так далее.
Другие способы позволяют в буквальном смысле разменять процессорное время на производительность. Например, сжатие и дедупликация уменьшают размеры обрабатываемых данных, и получается, что «быстрая» память как бы увеличивается в размерах, но за это приходится платить вычислительными ресурсами.
Сжатие остается основной техникой, используемой в системах хранения корпоративного уровня, а также средах, работающих с большими данными. Такие инструменты, как Apache Parquet реорганизуют и сжимают данные на дисках, чтобы уменьшить время чтения.
От всех этих недостатков освобождены флеш-хранилища. Эта технология не нова, а SAS и SATA SSD можно приобрести уже лет десять как. Однако SCM переводит флеш-устройства на новый уровень: флеш-память подключается к PCIe-шине, вместо медленных шин SAS и SATA, что увеличивает скорость обмена данными.
Более того, зарождаются такие SCM, как например NVDIMM. NVDIMM производится в виде DIMM-модулей и, по сути, представляет собой гибридную память, объединяющую оперативную память DRAM и флеш-память NAND.
В обычных условиях модули NVDIMMвыполняют функцию обычной DRAM-памяти, но в случае сбоя или выключения системы данные из DRAMперемещаются в энергонезависимую флеш-память, где могут храниться неограниченно долго. Когда компьютер возобновляет работу, данные копируются обратно. Такой подход позволяет ускорить процесс запуска машины и снизить вероятность потери важных данных.
Чтобы максимизировать эффективность использования дорогих SCM, системы хранения должны постоянно обеспечивать их работой, то есть держать их занятыми. Получается, что мы не можем просто заменить магнитные диски – нам придется перерабатывать аппаратные системы и программное обеспечение.
К этому вопросу нужно подходить осторожно, поскольку слишком большое количество флеш-устройств приведет к значительным затратам денежных средств, а слишком малое их количество – к сложностям обращения к ним. Найти правильный баланс не так уж и просто.
Также стоит помнить и о временном разделении ресурсов. На протяжении многих лет для взаимодействия жесткого диска и процессора использовались прерывания. Для ядра, работающего на частотах, измеряемых гигагерцами, не составляет труда обслужить прерывание каждые несколько секунд. Одно ядро может управлять десятками или сотнями дисков, не рискуя «захлебнуться». Однако с появлением низколатентных устройств хранения этот подход больше неприменим.
Эта модель должна серьезно измениться. Серьезный прирост в производительности получили не только устройства хранения данных – ускорение работы сетевых устройств также имело место: сначала до 10G, потом до 40G, затем до 100G. Может удастся «подсмотреть» решение в этой сфере?
Однозначного ответа дать не получится, поскольку слишком велика разница в ускорении: сети стали быстрее в тысячу раз, а запоминающие устройства – в миллион. Более того, при работе с памятью часто приходится поддерживать сложные функции сжатия, кодирования и дедупликации, потому методики оптимизации, применяемые для работы с пакетами, скорее всего, не подойдут.
В сетях для снижения латентности применяется способ, когда всеми пакетами управляет приложение в обход ядра. Однако между сетями и устройствами хранения данных есть разница: сетевые потоки независимы и могут обрабатываться параллельно на нескольких ядрах, в случае ЗУ все запросы придется координировать.
Очевидно, что это непрактично. Один контроллер неспособен управлять доступом к огромному количеству SCM-устройств одновременно. Аппаратное обеспечение будет использоваться в пол силы, потому нужен иной подход.
Требования нагрузки к емкости и производительности не совпадают с аппаратными возможностями, что ведет к ограничениям в использовании высокоскоростных дисков. Например, данные объемом 10 ТБ с ожидаемой нагрузкой в 500k IOPS задействуют лишь половину возможностей дисков, если будут храниться на SCM-устройствах объемом в 1ТБ, способных обрабатывать до 100k IOPS каждый.
Однако нужно помнить о том, что большая часть данных не является «горячей», поэтому неэффективно хранить их все на высокоскоростных флеш-устройствах. Во многих случаях нагрузка согласуется с распределением Парето: 80% всех обращений адресовано 20% данных.
Гибридная система с различными уровнями хранилищ (с различными характеристиками производительности) является хорошим решением для смешения «холодных» и «горячих» данных, когда SCM-устройства выступают в качестве кэша для медленных дисков. Но нужно помнить, что шаблоны доступа со временем изменяются – надо своевременно на это реагировать и перемещать данные.
В грамотно построенных системах такой способ позволяет эффективно использовать аппаратное обеспечение без снижения производительности. Однако системы должны иметь гибкие политики, которые бы запрещали активным, но низкоприоритетным задачам вмешиваться в работу бизнес-критических приложений. Грамотная реализация и отладка этих механизмов – это совсем не тривиальная задача.
Так что же нас ждет в будущем?
Как было сказано выше, уже есть разработанные SCM-устройства. PCIe SSD – наиболее известный тип SCM и уже оказал значительное влияние на инфраструктуру дата-центров. Вторым примером может служить NVDIMM, которая имеет характеристики производительности, сравнимые с DRAM. Такие устройства уже доступны сегодня и продолжают развиваться.
SCM-технологиями занимается компания HP. Их проект под названием The Machine не что иное, как попытка разработать новую компьютерную архитектуру на мемристорах. Существование мемристора – четвёртого базового компонента электрических схем было предсказано в 1971 году Леоном Чуа (Leon O. Chua), однако лабораторный образец запоминающего элемента был создан только в 2008 году коллективом учёных во главе со Стэнли Уильямсом (Stanley Williams) в исследовательской лаборатории фирмы Hewlett-Packard.
Этот пассивный элемент способен запоминать собственное состояние. Можно сказать, что это резистор, сопротивление которого изменяется в зависимости от протекающего через него заряда. Когда элемент обесточивают, измененное сопротивление сохраняется.
В настоящее время ведутся разработки коммерческой реализации мемристора. Как только это произойдет, появится возможность для создания новых видов памяти, способных помимо хранения данных еще и обрабатывать их.
Что касается The Machine, то в ней нет границы между оперативной памятью и постоянным хранилищем данных. Вся память представляет собой оперативную. Это нивелирует проблемы, связанные с передачей информации между устройствами, работающими с разной скоростью.
Думается, что SCM-технологии призваны побороть неэффективность, возникающую при «общении» медленной и быстрой памяти. Тем интереснее наблюдать за происходящим: как новые разработки затронут все уровни инфраструктурного стека. Все еще только начинается.
Комментирует руководитель отдела развития проекта 1cloud.ru Сергей Белкин:
«Разные типы дисков могут требоваться для решения различных задач. Использование дисков различных типов может быть оправданным при создании многоуровневых систем хранения данных – данные, которые часто используются приложениями, можно размещать на более быстрых дисках.
К примеру, если существует сервис, который активно работает с базой данных, то ее имеет смысл перенести на отдельный SSD-диск – это поможет оптимизировать скорость ее работы. При этом, саму операционную систему логично оставить на более медленных дисках. Одновременное использование различных типов дисков позволяет сделать общее инфраструктурное решение более гибким, эффективным и оптимизированным по цене.
Что касается новых разработок в сфере твердотельных накопителей, то в прошлом году компании Intel и Micron анонсировали 3D XPoint (произносится как «кросспойнт») – безтранзисторную трехмерную архитектуру и заявили, что срок эксплуатации и скорость работы таких ЗУ превысит возможности памяти NAND в 1000 раз. Если это решение станет коммерческим, то, я думаю, оно с большой долей вероятности будет использоваться в центрах обработки данных для хранения часто запрашиваемых «горячих» данных»
Мнение Джорджа Крампа (George Crump) из Storage Switzerland:
«SCM – это новый тип хранилища, которое может стать промежуточным звеном между высокопроизводительной DRAM и дешевыми HDD. SCM-память способна обеспечить скорость считывания, близкую к скорости чтения DRAM, и скорость записи, во много раз превышающую возможности жестких дисков.
Это стало возможным благодаря интерфейсу PCIe, через который флеш-хранилище подключается напрямую к процессору. Однако не любой SSD-накопитель, подключенный по PCIe, является SCM-устройством.
Некоторые поставщики в погоне за производительностью устанавливают несколько контроллеров на свои карты, каждый из которых отвечает за свою область флеш-памяти. На первый взгляд, это кажется здравой идеей, однако в этом случае у контроллера нет возможности записывать или читать блоки, которые находятся за пределами его компетенции.
Если блок большой – это, наоборот, может негативно повлиять на скорость работы. Эта и другие проблемы с производительностью, возникающие из-за неэффективности существующих интерфейсов, тормозят процесс адаптации технологии»
Мнение Скотта Дэвиса (Scott Davis), технического директора Infinio:
«SCM-технологии станут доступны для коммерческого использования не раньше конца 2016 года.
Скорее всего, это будет ранняя реализация технологии 3D XPoint от Intel. HP и SanDisk также анонсировали, что работают над совместным проектом, однако их продукт, вероятно, выйдет на рынок не раньше начала 2017 года.
Стоит учитывать, что, как в случае со многими новыми технологиями, SCM-устройства первое время будут обладать ограниченной областью применимости. Препятствием для выхода на широкий рынок станет стоимость устройств»
Хранение данных. Или что такое NAS, SAN и прочие умные сокращения простыми словами
TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.
Зачем это все?
Хранение данных — одно из важнейших направлений развития компьютеров, возникшее после появления энергонезависимых запоминающих устройств. Системы хранения данных разных масштабов применяются повсеместно: в банках, магазинах, предприятиях. По мере роста требований к хранимым данным растет сложность хранилищ данных.
Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей — весьма интересная и сложная инженерная задача.
Хранение данных
Под хранением обычно понимают запись данных на некоторые накопители данных, с целью их (данных) дальнейшего использования. Опустим исторические варианты организации хранения, рассмотрим подробнее классификацию систем хранения по разным критериям. Я выбрал следующие критерии для классификации: по способу подключения, по типу используемых носителей, по форме хранения данных, по реализации.
По способу подключения есть следующие варианты:
подключение дисков в сервере
дисковая полка, подключаемая по FC
По типу используемых накопителей возможно выделить:
Если рассматривать форму хранения данных, то явно выделяются следующие:
По реализации достаточно сложно провести четкие границы, однако можно отметить:
RAID контроллер от компании Fujitsu
пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure
Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.
Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:
Конфигурации систем с единственным накопителем применяются чаще всего для нетребовательных нагрузок, обычно для домашнего применения. Для профессиональных целей, а также промышленного применения чаще всего используется несколько накопителей, объединенных в RAID-массив программно, либо с помощью аппаратной карты RAID для достижения отказоустойчивости и\или более высокой скорости работы, чем единичный накопитель. Также есть возможность организации кэширования наиболее часто используемых данных на более быстром, но менее емком твердотельном накопителе для достижения и большой емкости и большой скорости работы дисковой подсистемы компьютера.
Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.
Давайте разберем более детально устройство SAN, для этого логически разделим ее на две важных части, сервера с HBA и дисковые полки, как оконечные устройства, а также коммутаторы (в больших системах — маршрутизаторы) и кабели, как средства построения сети. HBA — специализированный контроллер, размещаемый в сервере, подключаемом к SAN. Через этот контроллер сервер будет «видеть» диски, размещаемые в дисковых полках. Сервера и дисковые полки не обязательно должны размещаться рядом, хотя для достижения высокой производительности и малых задержек это рекомендуется. Сервера и полки подключаются к коммутатору, который организует общую среду передачи данных. Коммутаторы могут также соединяться с собой с помощью межкоммутаторных соединений, совокупность всех коммутаторов и их соединений называется фабрикой. Есть разные варианты реализации фабрики, я не буду тут останавливаться подробно. Для отказоустойчивости рекомендуется подключать минимум две фабрики к каждому HBA в сервере (иногда ставят несколько HBA) и к каждой дисковой полке, чтобы коммутаторы не стали точкой отказа SAN.
Недостатками такой системы являются большая стоимость и сложность, поскольку для обеспечения отказоустойчивости требуется обеспечить несколько путей доступа (multipath) серверов к дисковым полкам, а значит, как минимум, задублировать фабрики. Также в силу физических ограничений (скорость света в общем и емкость передачи данных в информационной матрице коммутаторов в частности) хоть и существует возможность неограниченного подключения устройств между собой, на практике чаще всего есть ограничения по числу соединений (в том числе и между коммутаторами), числу дисковых полок и тому подобное.
Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети — сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети — что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.
Unified storage
Универсальные системы, позволяющие совмещать в себе как функции NAS так и SAN. Чаще всего по реализации это SAN, в которой есть возможность активировать файловый доступ к дисковому пространству. Для этого устанавливаются дополнительные сетевые карты (или используются уже существующие, если SAN построена на их основе), после чего создается файловая система на некотором блочном устройстве — и уже она раздается по сети клиентам через некоторый файловый протокол, например NFS.
Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.
Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).
N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.
Пример SDS на основе GlusterFS
Из преимуществ SDS — можно построить отказоустойчивую производительную реплицируемую систему хранения данных с использованием обычного, возможно даже устаревшего оборудования. Если убрать зависимость от основной сети, то есть добавить выделенные сетевые карты для работы SDS, то получается решение с преимуществами больших SAN\NAS, но без присущих им недостатков. Я считаю, что за подобными системами — будущее, особенно с учетом того, что быстрая сетевая инфраструктура более универсальная (ее можно использовать и для других целей), а также дешевеет гораздо быстрее, чем специализированное оборудование для построения SAN. Недостатком можно назвать увеличение сложности по сравнению с обычным NAS, а также излишней перегруженностью (нужно больше оборудования) в условиях малых систем хранения данных.
Гиперконвергентные системы
Подавляющее большинство систем хранения данных используется для организации дисков виртуальных машин, при использовании SAN неизбежно происходит удорожание инфраструктуры. Но если объединить дисковые системы серверов с помощью SDS, а процессорные ресурсы и оперативную память с помощью гипервизоров отдавать виртуальным машинам, использующим дисковые ресурсы этой SDS — получится неплохо сэкономить. Такой подход с тесной интеграцией хранилища совместно с другими ресурсами называется гиперконвергентностью. Ключевой особенностью тут является способность почти бесконечного роста при нехватке ресурсов, поскольку если не хватает ресурсов, достаточно добавить еще один сервер с дисками к общей системе, чтобы нарастить ее. На практике обычно есть ограничения, но в целом наращивать получается гораздо проще, чем чистую SAN. Недостатком является обычно достаточно высокая стоимость подобных решений, но в целом совокупная стоимость владения обычно снижается.
Облака и эфемерные хранилища
Логическим продолжением перехода на виртуализацию является запуск сервисов в облаках. В предельном случае сервисы разбиваются на функции, запускаемые по требованию (бессерверные вычисления, serverless). Важной особенностью тут является отсутствие состояния, то есть сервисы запускаются по требованию и потенциально могут быть запущены столько экземпляров приложения, сколько требуется для текущей нагрузки. Большинство поставщиков (GCP, Azure, Amazon и прочие) облачных решений предлагают также и доступ к хранилищам, включая файловые и блочные, а также объектные. Некоторые предлагают дополнительно облачные базы, так что приложение, рассчитанное на запуск в таком облаке, легко может работать с подобными системами хранения данных. Для того, чтобы все работало, достаточно оплатить вовремя эти услуги, для небольших приложений поставщики вообще предлагают бесплатное использование ресурсов в течение некоторого срока, либо вообще навсегда.
Из недостатков: могут заблокировать аккаунт, на котором все работает, что может привести к простоям в работе. Также могут быть проблемы со связностью и\или доступностью таких сервисов по сети, поскольку такие хранилища полностью зависят от корректной и правильной работы глобальной сети.
Заключение
Надеюсь, статья была полезной не только новичкам. Предлагаю обсудить в комментариях дополнительные возможности систем хранения данных, написать о своем опыте построения систем хранения данных.
Обзор технологий хранения больших данных. Плюсы, минусы, кому что подойдет
Если вы собираетесь построить или перестроить свое хранилище данных, то столкнетесь с внушительным списком технологий на рынке. Пробовать каждую из них в поисках подходящей именно вам — долго и затратно.
На нашей конференции 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 октября онлайн. Программа еще составляется, но если вас заинтересовал этот пост — вероятно, среди новых докладов вы тоже обнаружите много интересного вам. В таком случае есть смысл обратить внимание уже сейчас: билеты со временем дорожают.