На чем лучше хранить информацию
Выбираем способ хранения данных и важной информации: руководство Overclockers.ru (страница 2)
Магнитные ленты
А ведь многие пользователи уже не знают, что это такое – стример (по-английски – «tape drive», а не «streamer», кстати). Опять-таки, в девяностых годах прошлого века такой способ хранения считался практически вечным – кассеты с магнитными лентами не подходили для ежедневного чтения информации, но для долговременного более чем.
Как и сегодня; лентам дают минимум двадцать пять лет жизни, а то и больше. И не теоретической: вспомните, сколько уже десятков лет исполнилось данному способу хранения информации.
реклама
Большой минус стримеров и расходников к ним – цена. И да, их все еще выпускают. Стоимость стримера на Амазоне составляет от 100 евро, еще пару десятков нужно выложить за многотерабайтные кассеты (объемом от 320 Гбайт до 50 Тбайт) – в общем, такой способ бэкапирования данных и создания файлопомоек подойдет лишь организациям или людям, которым не очень жалко денег.
Да и организациям-то не самым маленьким, потому что фирмы поменьше подумают и выложат деньги за что-нибудь подоступнее, поскольку в их случае объем информации уместится на одну кассету.
В принципе, стримеры являются практически идеальным долговременным хранилищем, если не брать в расчет стоимость мегабайта. Потому как она запредельная. И, кстати, желательно помнить о том, что кассеты можно размагнитить. Но лучше не нужно.
Жесткие диски (HDD)
Жесткие диски сегодня являются самым дешевым устройством для хранения данных при учете фактора «цена за мегабайт». Легко можно купить трехтерабайтный «винчестер» менее чем за 100 евро, и он будет служить верой и правдой, пока у него не «полетят головки» (худший вариант) или же он просто однажды не посыплется «бэдами». В таких случаях пользователи обычно нецензурно выражаются – да так, что грузчики в порту позавидуют. Потому что накопленные за долгие годы данные могут умереть в момент.
Технологии в производстве HDD кардинально не развиваются уже лет пятнадцать, за исключением повышения оборотов шпинделей; а различные многобуквенные сочетания надежности по большому счету не добавляют, разве что информированности. Кроме того, восстановление данных с жесткого диска в случае безвременной кончины последнего – весьма дорогостоящая процедура, а если модель еще и десятилетней давности или более, сумма возрастает совершенно непропорционально.
Да, трава раньше была зеленее, а «винчестеры» – надежнее. Потому что, к примеру, восстановление «голов» может вам обойтись далеко не в один десяток тысяч рублей, и критическая информация станет поистине золотой.
реклама
Выходом из этого может служить вышеупомянутый способ зеркалирования. Это значит, вы покупаете два HDD одинакового объема, но разных производителей, и проводите ежедневное автоматическое копирование данных с одного на другой. Такой способ можно назвать максимально бюджетным и при этом достаточно надежным (да и найти бесплатное приложение для зеркалирования не проблема). Можно, конечно, и в RAID их запихать – только вот развалится массив, и плакали ваши данные. Поэтому рекомендую проверенный годами способ.
Твердотельные накопители (SSD)
Твердотельные накопители – это новый и очень удобный способ хранения информации на рабочем компьютере, поскольку при большей раз в десять скорости (если говорить о нормальных SDD) относительно HDD они уже не стоят заоблачных многих сотен долларов. Но у них по-прежнему остается проблема ограниченного числа часов работы и циклов записи/чтения, и это всего лишь несколько лет.
Поэтому SSD можно рассматривать как прекрасное средство для работы, но в качестве средства для хранения данных о них нужно вспоминать в последнюю очередь. Как минимум потому, что цена за мегабайт у них значительно выше, чем в случае HDD.
С другой стороны, умирают такие накопители гораздо медленнее и с уведомлениями (в зависимости от модели) об этом. Можно успеть и купить новый, и переписать на него все данные, и даже устроить грандиозную вечеринку, и не раз – прежде чем твердотельный отдаст концы. Кроме того, восстановить информацию с SSD бывает проще, чем с HDD, из-за более простой структуры и отсутствия движущихся частей.
Наконец, никто не заставляет вас пользоваться таким способом хранения данных постоянно: то есть записали – отключили и забыли. По идее, если SSD не дергать, он проживет долгие декады. Хотя никто пока еще не знает, как и в случае с CD.
Резюмирую: хранить данные на них можно, если вас не смущает высокая цена за мегабайт, сильно превосходящая таковую для HDD. В крайнем случае, успеете спасти.
Кстати, в качестве экзотического варианта можно рассмотреть хранение данных на флэшках. У которых ровно те же проблемы, разве что скорость ниже, чем у SSD как таковых. Впрочем, возиться с такими крошечными объемами никто не захочет, так ведь?
Муки выбора
Если у вас после прочтения так и не появилось ясности, попробую ее внести. В случае если необходим наиболее выгодный вариант цены за мегабайт – выбирайте жесткие диски и/или DVD. Последние выглядят предпочтительнее в плане надежности, поскольку HDD достаточно капризны и могут умереть, даже лежа на диване круглые сутки; в отличие от них, диски DVD обладают более устойчивой психикой.
реклама
К тому же, пишущий привод сегодня стоит менее тысячи рублей, а набор из десяти «болванок» 4.37 Гбайт так и вообще пару сотен. Ну а не самый дешевый жесткий диск объемом три терабайта будет стоить от шести тысяч, причем о надежности можно думать очень долго.
Если же финансовый вопрос не стоит остро – присмотритесь к SSD-драйвам. Да, они дороги, но, если не использовать SSD с сенситивными данными в постоянном режиме, то он может прожить долго и счастливо. Если же у вас денег куры не клюют – выбирайте стримеры. С другой стороны, можно купить какой-нибудь отремонтированный или бывший в употреблении экземпляр – например, один такой производства HP в комплекте с пятью трехтерабайтными кассетами формата LTO5 продается в момент написания этой статьи на eBay всего за 150 евро. Нетрудно подсчитать, что это будет даже выгоднее HDD.
В случае «а мне забить на все» можно воспользоваться облачным хранилищем. Но желательно каким-нибудь надежным – тем же Google или его вечным конкурентом Microsoft. А если хочется почувствовать себя совсем крутым – купить за неразумные деньги терабайта два на Dropbox. А еще лучше не ограничиться двумя, и сделать одну половинку зеркалом второй.
Заключение
Одним словом, выхода нет только из гроба. А найти идеальные для себя способы хранения и бэкапирования информации можно достаточно легко, если воспользоваться рекомендациями выше. Главное – делать это в принципе. Ибо надежность превыше всего.
Все мы храним информацию в электронном виде, но, к сожалению, не все делают это правильно. Её можно хранить на жёстком диске, внешних накопителях (смартфонах, переносных жёстких дисках, флешках, картах памяти, CD и DVD дисках), а также в облачных хранилищах.
реклама
Итак, представим, что у нас есть первый компьютер, и мы хотим грамотно организовать хранение нашей информации. Первое, о чём следует позаботиться, это хранение паролей. Поскольку форумы, социальные сети, сетевые игры, электронная почта и Ютуб (если вы хотите сохранять историю просмотров и оставлять комментарии), требуют регистрации. Рассмотрим специальные программы для защиты Ваших паролей, причём они защищают их как от взлома, так и от случайной утери.
Например, есть приложения для смартфонов вроде программы «Сейф+» и ей подобных, которые надёжно зашифруют ваши логины и пароли. Можно также воспользоваться более простым способом, создать архив с паролем и хранить его на флешке в укромном месте. Пароли нужно хранить как минимум в двух экземплярах!
Также нам регулярно требуются сканы документов, их лучше хранить также в двух экземплярах, первый на смартфоне, в формате PDF или Jpeg (на карте памяти, на случай поломки смартфона или сдачи его в ремонт). Второй экземпляр на флешке или в облачном хранилище.
реклама
Облачные хранилища это прежде всего Google Диск и Яндекс.Диск. В них можно хранить как текстовые файлы, так и фотографии, музыку, видео. Рассмотрим их подробнее.
Google Диск предоставляет в бесплатное пользование 15 Гб свободного места, если хотите больше, то оформляйте подписку. Не стоит забывать, что компания Гугл (Google) является разработчиком мобильной операционной системы Андроид (Android), и если у Вас на смартфоне стоит одна из его версий, то аккаунт на mail.google.com будет обязательным. Он позволит сохранять в облако записную книжку смартфона и резервные копии приложений типа Ватсап (WhatsApp).
Внимание! Если ваш ребёнок просит сделать ему канал на Ютубе, чтобы стать блогером, то обязательно создавайте для него новый аккаунт! Поскольку если его неожиданно забанят, то Ваши данные останутся в целости и сохранности. Аналогично если Вы сами пишите много комментариев «о накипевшем», пишите их с «чистого» аккаунта.
реклама
Яндекс.Диск может безлимитно загружать фотографии с телефона, и бесплатное место для остальных данных может варьироваться в зависимости от участия в акциях. Например, у меня бесплатный лимит равен 40 Гб, а для новых пользователей доступно только 10Гб.
Когда вы удаляете файлы в программе Яндекс.Диск, они попадают в «Корзину» и хранятся в ней 30 дней. После этого они автоматически удаляются с сервера. Восстановить удаленные с сервера файлы невозможно! Однако восстановить файлы из «Корзины» вполне возможно, но только в веб-интерфейсе Яндекс.Диска. Если вы хотите удалить файл с компьютера, но сохранить на сервере, настройте выборочную синхронизацию.
Переносные жёсткие диски, у меня их целых три, рационально использовать для хранения сеймейных фото- и видеоархивов, установочных файлов программ, которые могут пригодиться в любой момент, но занимают много места. Я, например, самый ёмкий жёсткий диск (объёмом на 1Тб) использую для хранения мультиков и детских фильмов.
реклама
Также есть сетевые хранилища, которые представляют из себя корпус из пластика или металла, в котором содержатся как минимум пара жёстких дисков и специальная плата с операционной системой. Фактически это автономный компьютер и его можно подключать в локальную или глобальную сеть для получения общего доступа нескольким пользователям. Эти хранилища стоят довольно дорого, но имеют свои преимущества. Например, не нужно бояться, что Вас могут забанить за резкий комментарий под роликом на Ютубе, или что Вы потеряете пароль от вашей учётной записи. Также сетевые диски позволяют создавать Рэйд (RAID) массивы, их существует несколько видов, но наиболее популярный так называемый «зеркальный», в котором вся информация, записываемая на один жесткий диск, автоматически дублируется и на второй.
В современных ПК зачастую отсутствует DVD привод, но зато обычно есть картридер для чтения карт памяти всевозможных форматов. Поэтому содержимое дисков плавно перекочевало на флешки. Так появились загрузочные USB, с которых можно устанавливать Windows и запускать тестовые утилиты для диагностики жёсткого диска и оперативной памяти, а также можно запустить антивирус для лечения ПК от вирусов. Кстати, среди утилит зачастую есть и программа для сброса забытого пароля у операционной системы, я сам ей пользовался ещё будучи студентом, когда младшая сестра установила пароль на компьютере и благополучно его забыла.
Для самых ленивых есть даже образы дисков с операционной системой и основными программами, включая полный комплект Майкрософт Офиса (Microsoft Office), но тут стоит учитывать, что это пиратские версии программ и они работают не всегда корректно.
Очень полезная вещь – портативные (portable) версии программ, которые можно запускать с флешки и при желании переносить на ПК обычным копированием. Так меня часто выручает portable версия браузера Мозилла Фаерфокс (Mozilla Firefox), которая позволяет мне пользоваться браузером со всеми вкладками и закладками на любом компьютере, с любой версией Виндовс.
Вторая по полезности portable программа – почтовое приложение Мозилла Тандебёрд (Mozilla Thunderbird), позволяющая работать с почтой сразу из нескольких почтовых ящиков. У меня она долгое время была на флешке и получала почту сразу с шести е-мейлов нажатием одной кнопки! Если Вы торговый представитель или юрист, то возможность носить на флешке всю вашу почту поможет сэкономить уйму времени.
И напоследок небольшой совет для меломанов, у которых есть редкие музыкальные CD диски. Если Вы хотите перенести свою музыку на ПК, то самый простой вариант – найти эту музыку в Интернете. Зачастую она будет доступна на различных сайтах (где за просмотр рекламы можно слушать музыку), в разном качестве звучания. Если её в глобальной сети нет, то отчаиваться не стоит, есть программы, называемые аудио-грабберы (Audiograbber), способные переносить музыкальные треки на жёсткий диск ПК. Кстати копировать музыку с аудио дисков умеет стандартный медиаплеер в Windows XP.
«Облако», HDD или SSD: где лучше сохранится информация спустя 20−50 лет и как умирают данные
Какого-то единственного правильного решения такой задачи нет, поскольку исходя из личного опыта многие пользователи предлагают разные достижения поставленной цели. После прочтения постов на разных форумах становится понятно одно — хранить важную информацию на неиспользуемых на постоянной основе накопителях нельзя. Дело не только в размагничивании самих дисков или деградации ячеек памяти, но и увеличении энтропии, ведущей к искажению данных, то есть появлению битых файлов.
Кстати, насчет энтропии: это одна из причин, почему космическое оборудование намного слабее того, которым мы пользуемся на Земле. Все дело в плотности микросхем, так как современное «железо» стремится к уменьшению техпроцесса, а чем плотнее компоненты, тем они более уязвимы к космическому излучению и солнечной радиации. Долгосрочное хранение информации на жестких дисках и SSD имеет аналогичные проблемы, поскольку электромагнитные излучения, перепады температур и влажности еще никто не отменял. Так как же правильно хранить важные файлы, как снизить риск их потери и как, собственно, умирают данные — с этим мы и намерены сегодня разобраться.
Деградация ячеек и размагничивание данных на диске
Сначала разберемся с размагничиванием пластин в жестких дисках, ведь там считывание информации зависит от трех главных параметров: точности позиционирования механизма считывающей головки, чувствительности головок и мощности магнитного поля болванок. В нормальных условиях, когда соблюдаются рекомендуемые производителем показатели влажности, температуры в помещении, а также отсутствуют механические удары и вибрация, сильные электромагнитные поля, деградация магнитного поля пластин составляет около 1% в год.
При этом сказать, что через условные 50 лет половина диска станет нечитаемой, будет неправильно. Обычно в таких случаях наличие битых файлов или вовсе их исчезновение будет связано не столько с ухудшением магнитной записи, сколько с деградацией материалов, отвечающих за точность позиционирования и чувствительность считывающих головок. Поэтому переживать за сохранность информации не стоит, поскольку неработающий должным образом такой жесткий диск всегда можно отнести к специалистам, которые без проблем считают и восстановят 100% данных напрямую с пластин. Это касается и вышедших из строя жестких дисков, в которых сломалась электроника, но «блины» не были повреждены механически ни считывающей головкой, ни наличием трещин и сколов. Единственный минус: стоимость услуг по восстановлению файлов может обойтись в копеечку.
Стоит ли так рисковать и оставлять на полке жесткий диск на 5−10−20 лет? На самом деле, нет. Несмотря на то, что многие могут похвастаться, что их жесткие диски успешно были считаны спустя 10−15 лет простоя на пыльной полке, есть много и негативных отзывов, когда после длительного хранения «харды» попросту отказывались раскручивать пластины. Связано это с тем, что жесткие диски предназначены для постоянной работы, поскольку в процессе своей жизнедеятельности они постоянно обновляют магнитный слой пластин и тем самым могут работать без сбоев десятки лет. Поэтому лучшим решением является постоянная перезапись данных с одного носителя на другой раз в год, если это действительно очень важные файлы.
Если планируется перезапись информации с одного «харда» на другой, то для этих целей лучше использовать проверенные временем устройства 3−5 летней давности (можно и больше) без наличия битых секторов! Жесткие диски, особенно современные модели, подвержены «детской смертности» — они до 40 раз имеют больше шансов выйти из строя в первые год-два эксплуатации, чем старшие собратья, отработавшие минимум 3 года.
Деградация ячеек на SSD
Большая часть современных SSD-накопителей используют метод ловушки заряда в ячейки памяти — CTF (Charge Trap Flash). Сами же ячейки на сегодняшний день в зависимости от стоимости твердотельного накопителя могут быть 4-х видов: SLC (хранение 1 бита информации), MLC (2 бита), TLC (3 бита) и QLC с хранением в ячейке 4 бит данных. В зависимости от количества хранимых бит в одной ячейке варьируется и емкость SSD — чем больше, тем лучше. Но у этого свойства есть и обратная сторона медали: чем выше количество бит в одной ячейке, тем больше уровней напряжения требуется для записи информации, а потому материал диэлектрика в ячейках памяти изнашивается быстрее. Важно уточнить, что деградация происходит только при записи данных, а при их считывании нагрузки на диэлектрик практически нет.
Значит ли это, что SSD можно единожды записать и хранить его долгие годы вне компьютера, а после удачно считать с него важную информацию? Можно, но ограниченное время. Например, компания DELL в документации к производимым твердотельным накопителям указывает, что ее SSD способны хранить информацию без подключения к питанию минимум 10 лет. При этом бренд отмечает, что если flash-память уже значительно изношена, то без питания данные могут храниться на накопителях до 3 месяцев для MLC и до 6 месяцев для SLC-ячеек.
Вечного архива не существует
Подводя итог о долгосрочном хранении данных на жестких дисках и SSD — ни первые, ни вторые не проектируются производителями для многолетнего архивирования информации. Для этих целей у компаний есть специальные оптические диски «архивного уровня», как например, DWD + RW или Blu-Ray диски, срок службы которых может достигать до 30 лет и даже больше. Что касается безмятежного и безопасного хранения данных на срок до 100 лет, то таких решений на сегодняшний день еще не найдено.
Стоит ли хранить данные в «облаке»?
Если отбросить устоявшиеся мифы о том, что данные пользователей, хранящиеся в «облаке» с легкостью могут украсть хакеры, или исчезнуть в результате стихийного бедствия, то облачные хранилища действительно надежны по состоянию на 2021 год. Крупные корпорации, которым принадлежат огромные сервера в разных странах, куда серьезнее относятся к безопасности и сохранности данных, нежели простые пользователи. Поэтому если и делать выбор между локальным хранением информации на HDD/SSD или предоставить эту услугу «облаку», то в плане надежности второй вариант предпочтительнее. К слову, он и удобнее, так как доступ к файлам будет всегда и везде — достаточно иметь под рукой смартфон и выход в Интернет. С другой стороны, такое удобство и безопасность в финансовом плане обойдется дороже.
Значит ли это, что данные в «облаке» никогда не исчезнут? Несмотря на то, что дата-центры имеют подстраховку в виде резервных копий, иногда и они безвозвратно теряют данные. Случается это крайне редко и теряется лишь малая часть информации, но факт остается фактом. Например, в 2015 году очень не повезло дата-центру компании Google, расположенному в Бельгии. В него 4 раза подряд ударил разряд молнии, и несмотря на все попытки восстановить все данные, безвозвратно было потеряно около 0,000001% информации. За последние 6 лет подобных происшествий больше не случалось несмотря на неоднократные неприятные инциденты, связанные с серверами (например, в марте 2021 года полностью сгорел страсбургский OVH SBG2, но ни один важный файл потерян не был).
Удалить с «облака» не так уж просто
Когда пользователь что-то удаляет с облачного хранилища, это не значит, что стертые файлы исчезают бесследно. Наглядным примером служит история, случившаяся в 2017 году, когда облачный сервис Dropbox из-за бага восстановил для части пользователей удаленные несколько лет назад данные.
Как умирают файлы на дисках
Что на жестких дисках, что на SSD информация умирает плюс-минус одинаково: обычно видеоролики «рассыпаются» на крупные пиксели различных цветов, разъезжаются на полосы или картинка застывает/видеозапись обрывается. Что касается фотографий, то они начинают демонстрировать артефакты (снова пиксели, полосы, часть картинки может быть залита одним или несколькими цветами), а музыкальные файлы начинают «булькать», издавать резкие звуки, обрываться на воспроизведении в любой момент. Прочие документы могут и вовсе не открываться.
При этом стоит понимать, что файлы сами по себе не могут деградировать. Если они открываются, то с вероятностью 99,9% они содержат ровно тот же код, что и при записи. Почему тогда они становятся «битыми»? Здесь проблема кроется в основном в некорректности считывания и последующей записи. Для HDD, как мы уже говорили, это потеря чувствительности и сбой позиционирования считывающих головок при полной сохранности данных на самих болванках. Для SSD ситуация сложнее, ведь там могут «барахлить» и контроллер памяти, и сама NAND-память. К слову, именно поэтому с SSD восстановить информацию сложнее, а порой и невозможно, в отличие от жестких дисков.
Как лучше хранить данные: локально или онлайн?
Какой вывод можно сделать насчет долгосрочного архивирования важной информации? Лучшим вариантом станет хранение файлов на жестких дисках, проверенных временем (3−5 лет без BAD-секторов) с периодической перезаписью данных раз в год на резервный HDD. При этом еще лучше иметь бэкап в «облаке», чтобы на 100% быть уверенным, что важные данные никогда и никуда не потеряются в течение как минимум нескольких десятков лет. Увы, но обойтись одним единственным решением сейчас невозможно, поскольку соответствующих технологий еще не разработано.
Обзор технологий хранения больших данных. Плюсы, минусы, кому что подойдет
Если вы собираетесь построить или перестроить свое хранилище данных, то столкнетесь с внушительным списком технологий на рынке. Пробовать каждую из них в поисках подходящей именно вам — долго и затратно.
На нашей конференции 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 октября онлайн. Программа еще составляется, но если вас заинтересовал этот пост — вероятно, среди новых докладов вы тоже обнаружите много интересного вам. В таком случае есть смысл обратить внимание уже сейчас: билеты со временем дорожают.