Материал этой заметки послужил основой для одной из глав книги "СУБД для программиста. Базы данных изнутри".

* * *

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

Прежде всего, у человека с дефрагментированными мозгами (процедура необходима из-за обрывочной поступающей информации) должен возникнуть естественный вопрос: "Большие - это сколько?"

Во время написания заметки словом "большие" оценивались объемы, начиная примерно с 1-10 петабайт.

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

Следующий не менее естественный вопрос, который должен возникать у нормального человека с техническим или научным образованием: "А почему, собственно, 1 петабайт, а не 1 терабайт или 1 зетабайт?"

Для ответа на него нам придется переместиться на машине времени в прошлое.

В 1975 году конференция (т.е. сообщество специалистов) по базам данных ввела в обиход проблематику очень больших баз данных (Conference on Very Large Databases). Название с точки зрения маркетинга, было менее удачным, всего лишь скупая аббревиатура VLDB.

В 1979 году на поднимающейся волне интереса к большим базам данных (точнее, платежеспособного спроса на прогрессирующую аппаратуру) была образована компания с говорящим названием Teradata. И уже в 1984 году на рынке появился её продукт Teradata database, предназначенный для массивно параллельной обработки (MPP) больших объемов данных. Да-да, именно для того, чтобы в 1984 году обрабатывать ту "бигдату". А большими, в соответствии с аппаратными возможностями ЭВМ той эпохи, считались тогда данные порядка 1 терабайта.

Примерно к началу-середине 1990-х стоимость носителей информации стала подъемной даже для средних предприятий. Вышли на рынок массово доступные продукты для анализа данных. Маркетинговым "кейсом" для ЛПР было незабвенное: "Анализ выявил, что изменение местоположения прилавков с бананами увеличит их продажу на 146%". Поезд стал набирать ход, к 2000 году средства анализа данных были включены в СУБД ведущих поставщиков (например, Microsoft OLAP). Sybase выпускает специализированную СУБД "IQ" (поколоночное хранение, входной язык SQL).

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

Из-за того, что сегодня вы можете купить себе домой жесткий диск объемом в 1 терабайт по цене поездки на такси из аэропорта в центр города, такие данные не перестали быть достаточно большими. Заполнить подобную БД осмысленной информацией и потом попытаться её анализировать с приемлемым временем отклика - задача, которая, по-прежнему, под силу только профессиональным аналитикам в содружестве со специалистами СУБД.

Чтобы не быть голословным, приведу примеры. База данных перемещений всех пассажиров парижского региона (допуская, что все они имеют именные магнитные карты) за год укладывается в этот самый 1 терабайт. В тот же 1 терабайт укладываются неагрегированные данные за 3-5 лет бухгалтерий всех основных компаний по добровольному медстрахованию национального уровня (десятки миллионов застрахованных, десятки финансовых операций в месяц на человека) с 30-40 уровнями аналитики (измерений). Контора по веб-маркетингу умещает в БД размером порядка 1 терабайта данные всей активности пользователей национальной службы (порядок 10 миллионов профилей) с примерно 30 измерениями за 1-2 года. База данных сбора информации с устройств национальной электрической сети (сотни тысяч устройств, пакеты приходят каждые 10 минут) за 5 лет накапливает 3-4 терабайта.

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

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

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

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

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

"Нагенерировать" данные - не проблема. Проблема "нагенерировать" осмысленные данные. Броуновское движение в капле воды "нагенерит" и петабайты и экзабайты всего за несколько минут если выбрать соответствующую дискретность. Потом из полученных "больших данных" можно выводить астрологические законы природы. Описанная на молекулярном уровне структура кофейной гущи на блюдце также займет петабайты (lire dans le marc de café).

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

С другой стороны, теоретики и практики СУБД еще с 1990-х ворчат на тему "засилья" реляционных БД. Несмотря на известные проблемы, РСУБД являются универсальными и решают свои задачи хранения и обработки данных с приемлемым качеством в большинстве случаев. Такая ситуация привела к некоторому "застою", когда тройка поставщиков СУБД имеет (во всех смыслах) более 90% всего рынка. Теоретикам и практикам оказалось не под силу вписаться в эту ситуацию и реализовать свои решения в сколь-нибудь массовом продукте. Все ограничивается нишевыми специализированными решениями.

Для таких специалистов "большие данные" открывают новые сцены и рынки. Перекрестим принцип ACID в BASE (Basically Available, Soft-state, Eventual consistency). Не будем вспоминать, что распределенные БД существовали в 1980-90-х годах (ключевые слова: репликация, сервер репликации, двухфазная фиксация) и что от них при первой возможности избавлялись всеми силами по причине гораздо более высоких расходов на разработку и эксплуатацию по сравнению с централизованными решениями. Сформулируем принцип CAP: есть три качества распределенных систем — Consistency, Availability и Partition Tolerance, выбирайте любые два. Назовем этот принцип теоремой, которую, правда, никто всерьёз не будет доказывать.

Одним словом, пытаются ломать прежний тренд.

Что имеем в итоге на сегодняшний день. Позитивные моменты:

• облегчение работы с объемами данных, считавшимися большими 30 лет назад (за счет развития аппаратуры и универсальных РСУБД);
• подвижки в теоретических работах и их реализации;
• возможность сбора и анализа большего объема информации в научной сфере;
• относительная общедоступность решений по обработке данных, считающихся большими сегодня (Hadoop, MapReduce и др.).

Не обошлось и без негативных:

• на практике принцип сбора данных "на случай если они вдруг понадобятся в будущем" быстро превращает хранилище в помойку и кладбище;
• в научной сфере развернулись дискуссии, потому что при широком доступе к результатам экспериментов найденные в данных закономерности выдаются за подтвержденные гипотезы без объяснений природы связи. Самая настоящая астрология въехала в науку на колесах телеги "больших данных";
• за исключением случаев необходимости использования специализированных СУБД, пользуясь некомпетентностью в области баз данных части разработчиков и руководителей проектов, ведется достаточно агрессивная пропаганда против универсальных РСУБД;
• освоение бюджетов проектами с неизвестной рентабельностью с одной стороны, повышение расходов на мейнфреймы для поддержки существующих систем 40-50-летней давности - с другой.

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

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

Ссылки

• Патологии больших данных. Адам Якобс. Перевод: Сергей Кузнецов
• О точности диагностики патологий. Сергей Кузнецов
• Смутное время СУБД. Леонид Черняк. «Открытые системы», № 02, 2012