В нашей компании мы регулярно пробуем и анализируем новые интересные технологии в области хранения и управления большими данными. В апреле с нами связались представители компании Snowflake Computing и предложили попробовать их продукт Snowflake Elastic Data Warehouse — облачное хранилище данных. Они работают над созданием эластичной системы, которая могла бы легко расширяться по мере необходимости — при увеличении объема данных, нагрузки и прочих неприятностях.

Обычно СУБД работают в условиях, когда объем доступных ресурсов ограничен имеющимся оборудованием. Чтобы добавить ресурсов, надо добавить или заменить сервера. В облаке же ресурсы доступны в тот момент, когда они понадобились, и их можно вернуть, если они больше не нужны. Архитектура Snowflake позволяет воспользоваться всеми преимуществами облака: хранилище данных может мгновенно расширяться и сжиматься, не прерывая выполняющиеся запросы.

Как и в прошлом году, выступил на HighLoad++. На этот раз мой доклад шел в секции «Базы данных», я рассказывал о том, какие системы хранения рационально использовать для задач многомерного анализа больших данных. Слайдов на сайте организаторов пока нет, как только появятся — я добавлю ссылку. Вкратце, презентация была построена так:

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

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

Вчера было мое выступление на HighLoad++. Тезисы и слайды на сайте организаторов. Конференция организована, кстати, отлично. Но времени на полноценное выступление было мало — 45 минут с вопросами. Тестовый прогон у меня занял 60 минут, после некоторой реорганизации и без вопросов на HL я уложился за 42. Некоторые важные архитектурные моменты пришлось проговаривать быстро и без примеров, от чего, конечно, страдала ясность. Я пытался построить презентацию таким образом, чтобы показать, как мы необходимым образом пришли к Вертике и к текущей архитектуре, и в то же время сделать акцент на важных архитектурных принципах работы с большими данными вообще. Не уверен, что цель была в полной мере достигнута. Мало, мало времени. Но я всегда открыт для вопросов. Вертика, впрочем, вызвала заслуженный интерес, вопросы были по делу.

А сегодня было выступление Криса Бонна из etsy.com, и, удивительное дело, он тоже рассказывал про Вертику.

Предисловие

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

В среду вечером мы провели мероприятие в формате meetup, посвященное большим системам и большим данным: habrahabr.ru/events/836

Если среди читателей есть те, кто там был (а это 80-100 человек из примерно 150 зарегистрировавшихся), то огромное вам спасибо. И огромное спасибо всем, кто помогал в организации и проведении.

Я не знаю, как правильно перевести слово meetup на русский. Не митапом же называть. Это не еще одна конференция, это другое. На больших конференциях, типа HighLoad, РИТ и т.д., специалисты из крупных компаний рассказывают о задачах, проблемах и решениях, которые часто находятся за пределами горизонта возможностей компаний поменьше. Это бывает очень интересно и познавательно, но по большой части малополезно с практической точки зрения. Формат meetup — он совсем другой, и больше напоминает «круглый стол». Его цель — обменяться опытом с коллегами из других компанией, с клиентами и партнерами. Обменяться «шишками» и «граблями», чтобы учиться не только на своих, но и на чужих ошибках. В Силиконовой долине такие мероприятия обычно проходят либо в офисах компаний-организаторов, либо в каких-нибудь нейтральных кафе. В Москве мы попробовали собрать людей после работы в Digital October. И это вполне получилось.

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

Часть 3. Vertica. Simply Fast

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

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

Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.

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

Что же делать?

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

Часть 1. Немного истории, теории и практики

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

Первая версия “инфраструктуры” была сделана “на коленке” за два дня в далеком 2006 году, когда в компании было 4 человека разработчиков, и примерно столько же людей из бизнеса.

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

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

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

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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

Munin очень неплохая штука для мониторинга серверов, особенно одного-двух. Однако если количество серверов растёт работает он всё хуже и хуже. Под катом рассказ как я разгонял его до мониторинга больше чем 1000 виртуалок (275K rrd файлов в системе).

Мой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.

Обычный подход к репликации — это синхронный или асинхронный перенос бинарного лога с одной базы данных (мастер) на другие (слейвы). В бинарном логе строго последовательно записываются все операции, которые модифицируют данные. Если его «проиграть» на другой системе с той же начальной точки, то должно получиться точно такое же состояние данных, как и на исходной. «Проигрывание» происходит по одной операции или по одной транзакции, то есть очень маленькими кусочками.

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

Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.

Недавно компании Box.net и Zynga устроили презентацию об использовании в своей инфраструктуре публичных вычислительных облаков. Тема заинтересовала меня, особенно, в свете отказа в апреле 2011 года нескольких зон доступности (Availability zones) облака Amazon EC2, сделавшего недоступными несколько крупных интернет ресурсов и игр на Facebook на несколько дней. Презентации были изложены очень кратко, конкретные детали реализации докладчики не раскрыли. Но даже поверхностные данные представляют интерес.