Объемы данных и требования к скорости их обработки за последние десятилетия многократно выросли. Системы управления базами данных (СУБД) пытаются соответствовать новым реалиям и претерпевают значительные эволюционные и революционные изменения. Одним из таких эволюционных факторов является движение в сторону т.н. вертикальных (column-based) систем хранения.

Рассел Гарленд (Russell Garland), WSJ

Майкл Стоунбрейкер (Michael Stonebraker) при создании новой компании не стремится к большой прибыли, вместо этого он думает о развитии идеи, которая может революционизировать целую отрасль.

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

Некоторые из этих стартапов уже были приобретены, в том числе самый первый, Ingres Corp., и, например, компания Vertica в настоящее время приобретена Hewlett-Packard, сумма сделки не разглашается. Одна из нескольких должностей в настоящее время − директор по технологиям (CTO) в Paradigm4 Inc., секретном стартапе, развивающем аналитику для массивных наборов данных.

Стоунбрейкер работал с рядом известных венчурных компаний, в их числе Accel Partners, Bessemer Venture Partners, Highland Capital Partners, Kleiner Perkins Caufield & Byers, New Enterprise Associates и Sigma Partners.

Майкл является одним из ведущих мыслителей следующей волны инноваций в хранилищах данных (как в управлении, так и в аналитике), которая получила название «большие данные» (“big data”). Недавно он модерировал обсуждение по этому вопросу на мероприятии, организованном Массачусетским Советом технологических лидеров (the Massachusetts Technology Leadership Council).

Мы говорили с Майком Стоунбрейкером о предпринимательстве и его проектах. Вот отредактированное

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

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

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

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

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

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

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

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

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

Часть 3. Vertica. Simply Fast

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

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

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

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

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.

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

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

В качестве вступительного слова

На Хабре и других источниках уже было описание HP Vertica, но, в основном, вся информация сводилась к теории. До недавнего времени в реальной промышленной эксплуатации Vertica использовалась (так как мы называем ее Вертика, предлагаю назначить женский род) в Штатах и немного в Европе, на Хабре же о ней писали ребята с LifeStreet Media. Уже прошло полтора года работы с Vertica, наше хранилище данных содержит десятки терабайт данных. В минуту сервер данных обрабатывает тысячи запросов, многие из которых содержат десятки миллиардов записей. Загрузка данных идет не переставая в реалтайме объемами порядка 150 гб в сутки … В общем я подумал, что стоит восполнить пробел и поделиться ощущениями от езды на реально современных новых технологиях под BigData.

Кому это будет полезно

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

В один абзац о том, как мы выбирали

Кратко без повода к холивару:
При выборе сервера хранилищ данных нас интересовали принципы ценообразования, высокая производительность и масштабируемость работы с большими объемами данных, возможность загрузки данных в реалтайм с множества разных источников данных, легкость стартапа проекта своими силами и минимальная стоимость сопровождения: в итоге по всем этим показателям лучше всего для нас выступила Vertica, победив IBM Netezza и EMC GreenPlum. Последние не смогли полностью удовлетворить всем нашим требованиям. Это могло вылиться в дополнительные издержки на разработку и сопровождение нашего проекта, имеющего не сильно большой бюджет.

Как выглядит Verica с точки зрения архитектора

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

На что влияет техническая архитектура

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

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

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

В декабре 2013 года вышла новая, седьмая версия HP Vertica. В продолжении традиции большого строительства «не маленьких данных», версия получила название «Кран» (шестая версия называлась «Бульдозер»). В этой статье я опишу, что же изменилось в новой версии.

Работа с неструктурированными данными — Flex Zone

Самым главным шагом вверх по лестнице работы с большими данными в новой версии HP Vertica можно назвать появление поддержки прямой работы с неструктурированными данными CSV и JSON форматов. В шестой версии поддерживалась загрузка данных из CSV файлов и выполнение запросов к ним, как к внешним глобальным таблицам. Если данные файлов имели заранее неизвестную, плавающую структуру, то единственным способом загрузки и работы с такими данными в Vertica являлась их предварительная обработка во внешних приложениях, таких, как ETL инструменты.

Теперь Vertica умеет работать с неструктурированными данными так же просто, как и со структурированными. Выглядит это так:


HP Vertica Flex Zone — это специальная область хранения и обработки неструктурированных данных. В БД Vertica можно создавать flex таблицы, загружать в них данные из файлов с CSV и JSON форматами и выполнять к ним запросы, соединяя эти данные в запросах с реляционными таблицами Vertica. Загруженные данные в flex таблицах хранятся на нодах кластера сервера в специальном формате, но по тем же принципам, что и реляционные данные БД. Для них так же поддерживается сжатие, зеркалирование и сегментирование данных (распределение между нодами кластера). При таком хранении, неструктурированные данные при обработке используют все преимущества MPP архитектуры Vertica, работают в отказоустойчивой масштабируемой архитектуре и участвуют в резервном копировании.

UPD: Продолжение статьи по ссылке — habrahabr.ru/company/avito/blog/322510

О чем статья

Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд.

Постановка задачи

Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно — это Авито ;)).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.

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

О том, как решение НР Software по аналитике позволяет выявить скрытые проблемы сети и бизнес-приложений и многом другом, под катом

Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.

Демонстрация Hadoop пользователям

Уникальная по своим возможностям СУБД HPE Vertica легко справляется с обработкой данных не только бизнес-транзакций, но также межмашинного взаимодействия и Интернета вещей, позволяя управлять миром умных устройств в реальном времени.



Глобальная экономика входит в эпоху Интернета вещей и массового межмашинного взаимодействия. Это значит, отмечает Дэвид Джонс, старший вице-президент и генеральный директор бизнес-подразделения HPE по управлению информацией и ее организации, что уже скоро, примерно к 2020 году, по всему миру придется обрабатывать данные от 50 миллиардов смарт-устройств и одного триллиона приложений ― всего около 44 Збайт. Нет сомнений, что прежние СУБД, ориентированные на обработку транзакционных данных, циркулирующих в традиционных бизнес-приложениях, не справятся с такой нагрузкой. На смену им приходят СУБД нового поколения, изначально рассчитанные на работу с большими объемами и потоками данных. Одна из них ― HPE Vertica, способная анализировать в реальном времени огромные объемы информации, получаемой от всевозможных «генераторов» данных — не только традиционных транзакционных систем, но также датчиков и устройств Интернета вещей, систем межмашинного взаимодействия, АСУТП, веб-сайтов и прочих источников.

Типовой сценарий работы «just in time» хранилища данных выглядит так: десятки (ETL) сессий почти непрерывно захватывают с источников данные и вставляют их в хранилище. Параллельно множество других (ELT) сессий отслеживают поступление данных, заполняют консолидированный слой и ведут расчет агрегатов и витрин. Одновременно с этим, на поступающих первичных и рассчитанных данных, выполняют запросы пользователи, BI и другие системы. Вся эта каша должна ладно вариться в рамках сервера хранилищ данных, без тормозов и затыков, какими бы не были пиковые нагрузки.

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

По умолчанию после установки сервера Vertica на созданной базе данных это выглядит примерно так:

В данной статье я хочу продолжить тему сравнения баз данных, которые можно использовать для построения хранилища данных (DWH) и аналитики. Ранее я описал результаты тестов для Oracle In-Memory Option и In-Memory RDBMS Exasol. В данной же статье основное внимание будет уделено СУБД Vertica. Для всех описанных тестов использовались tpc-h benchmark на небольшом объёме исходных данных (2 Гб) и конфигурация БД на одном узле. Эти ограничения позволили мне многократно повторить бенчмарк в разных вариациях и с различными настройками. Для выбора аналитической СУБД под конкретный проект призываю читателей проводить испытания на своих кейсах (данные, запросы, оборудование и другие особенности).

Какое-то время назад я написал статью на Хабре. В ней же пообещал продолжение через пару недель. Но, как известно, обещанного три года ждут  —  и с тех пор действительно прошло три года. Если вы не запомнили со времён той статьи, то напомню  —  я работаю в Avito, строю хранилище на основе Vertica.
Из того, что поменялось — теперь я могу не просто написать статью, а сделать это в блоге компании. И, надеюсь, не один раз. Самопиар окончен, теперь к делу.

Привет! Меня зовут Сергей, я работаю главным инженером в Сбертехе. В ИТ-сфере я примерно 10 лет, из которых 6 занимаюсь базами данных, ETL-процессами, DWH и всем, что связано с данными. В этом материале я расскажу о Vertica — аналитической и по-настоящему колоночной СУБД, которая эффективно сжимает, хранит, быстро отдает данные и отлично подходит в качестве big data решения.

Аннотация

В данной статье я хочу поделиться собственным опытом работы с машинным обучением в хранилище данных на Vertica.

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

Machine Learning библиотека Vertica

Начиная с 7 версии Vertica дополнили библиотекой Machine Learning, с помощью которой можно:

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

Библиотека идет сразу в комплекте с инсталляцией Vertica для всех версий, в том числе бесплатной Community. Работа с ней оформлена в виде вызова функций из-под SQL, которые подробно описаны в документации с примерами использования на подготовленных демонстрационных данных.