МОГучие способности: новые приемы анализа больших данных

Джеффри Коэн, Брайен Долэн, Марк Данлэп, Джозеф Хеллерстейн, Кейлэб Велтон.
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

3. FOX Audience Network

FOX Audience Network (FAN) является рекламной сетью, обсуживающей несколько Internet-издательств, включая MySpace.com, IGN.com и Scout.com. При наличии более 150 миллионов пользователей она является одной из крупнейших в мире рекламной сетью.

Хранилище данных FAN сегодня реализуется на основе системы Greenplum Database, работающей на сорока двух узлах: из которых сорок узлов используется для обработки запросов, а два являются управляющими узлами (один для восстановления после отказов). В узлах обработки запросов используются машины Sun X4500 ("Thumper") с двумя двухъядерными процессорами Opteron, 48 500-гигабайтными дисковыми устройствами и 16 гагабайтами основной памяти. В EDW компании в настоящее время сохраняется 200 терабайт индивидуальных производственных данных, которые зеркалируются для обеспечения возможности восстановления после сбоев. EDW быстро растет: каждый день в хранилище данных FAN поступает от четырех до семи миллиардов строк из журналов сервера управления рекламой, что составляет примерно пять терабайт. Основная таблица фактов о восприятии рекламы наращивается с октября 2007 г. и представляет собой сейчас единую таблицу с более чем полутора триллионами строк. Миллионы строк данных измерений о рекламодателях и рекламных компаний ежедневно поступают от системы управления связями с заказчиками (Customer Relationship Management, CRM) FAN. Кроме того, имеются подробные данные о каждом из более чем 150 миллионов пользователей. EDW компании FAN является единственным репозиторием, в котором все три источника данных интегрируются для использования в исследовательских целях или для производства отчетов.

EDW рассчитано на поддержку самых разных пользователей от менеджеров по учету продаж до ученых-исследователей. Потребности этих пользователей очень различаются, и к хранилищу данных каждый день применяются различные программные средства построения отчетов и обработки статистики. Непосредственно для этого хранилища данных компания MicroStrategy реализовала средство BI, поддерживающее генерацию отчетов по продажам, макетингу и большинству других направлений бизнеса компании. У исследователей также имеется доступ к тому же хранилищу данных в режиме командной строки. Так что экосистема запросов является очень динамичной.

По-видимому, никакой набор предопределенных агрегатов не смог бы обеспечить ответ на любой вопрос. Например, легко представить себе вопросы, в которых комбинируются переменные рекламодателей и пользователей. В FAN это обычно означает непосредственное обращение к таблице фактов. Например, торговый агент мог бы легко задать следующий вопрос: Сколько энтузиасток Всемирного фонда природы в возрасте более 30 лет повторно посетило страницу сообщества Toyota в течение последних четырех дней и обратило внимание на средний прямоугольник? ("Средний прямоугольник" ("medium rectangle") – это стандартный формат рекламного баннера в Web.) Цель состоит в том, чтобы обеспечить ответы на такие непредвиденные вопросы в течение минут, и не допускается отвергать запросы, ответы на которые заранее не вычислены.

В этом примере можно обойтись простым SQL-запросом, но в подобных сценариях всегда далее задается сравнительный вопрос: Насколько эти дамы похожи на тех, которые повторно посетили страницу Nissan? На этой стадии мы начинаем заниматься многомерным статистическим анализом, для которого требуются более сложные методы. В FAN исследователи предпочитают использовать R, а пакет RODBC часто применяется для организации непосредственного интерфейса с хранилищем данных. Если для формирования ответов на такие вопросы оказывается достаточно данных объемом не более пяти миллионов строк, подобные данные часто экспортируются и анализируются в R. Случаи, в которых это невозможно, являются основным побудительным мотивом данной статьи.

В дополнение к хранилищу данных, группа машинного обучения FAN использует несколько крупных кластеров Hadoop. Эта группа применяет десятки алгоритмов классификации, управляемого и неуправляемого обучения, нейронных сетей и обработки текстов на естественном языке. Такие методы не относятся к тем, которые традиционно поддерживаются в РСУБД, и их реализация в среде Hadoop приводит к потребности в миграции крупных объемов данных для выполнения любого одноцелевого исследования. Доступность методов машинного обучения прямо в хранилище данных позволила бы существенно сократить расходы по времени, обучению и управлению системой, и обеспечение этой доступности является одной из целей работы, описываемой в данной статье.

4. Проектирование МОГучих баз данных

Традиционная философия хранилищ данных связана с дисциплинированным подходом к моделированию информации и процессов на предприятии. Словами сторонника хранилищ данных Билла Инмона (Bill Inmon), это "планируемая среда" [13]. Как демонстрируется ниже, эта точка зрения по поводу хранилищ данных не согласуется с принципами магнетизма и гибкости, поддержка которых требуется во многих новых аналитических средах.

4.1. Новые требования

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

Эти требования к скорости поступления и широте охвата новых данных создают напряженность в отношениях с ортодоксами хранилищ данных. Инмон описывает традиционную точку зрения следующим образом:

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

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

В условиях возрастающей сложности аналитических методов и увеличивающейся значимости аналитики мы принимаем ту точку зрения, что намного более важно обеспечить аналитикам гибкость, чем стремиться к иллюзорному идеалу полной интеграции. В действительности, в любой организации именно аналитики притягивают, отыскивают интересные данные, которые должны стать частью единой большой картины. Они могут также действовать как система раннего обнаружения касательно проблем качества данных. Ради возможности познакомиться с данными первыми они готовы смириться с наличием "грязных" данных, и они будут сами следить за тем, чтобы операционные данные выверялись до их поступления в хранилище данных. У аналитиков обычно имеются более высокие стандарты качества данных, чем у типичного бизнес-подразделения, работающего с инструментами BI. Они не боятся больших плоских таблиц, хранящих полные наборы данных, пренебрегая образцами и агрегатами, которые могут маскировать ошибки и приводить к потере важных характеристик на хвостах распределений.

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

В конечном счете, аналитика производит новые продукты данных, обладающие высокой значимостью для предприятия. Аналитики – это не только потребители, но и производители корпоративных данных. Для этого требуется подготовить хранилище данных к преобразованию данных, генерируемых аналитиками, в продукты данных, пригодные для использования в стандартных средствах бизнес-отчетности.

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

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

1. В данном бизнесе производится анализ для определения областей потенциального совершенствования.
2. Бизнес либо реагирует на результаты этого анализа, либо их игнорирует.
3. Реагирование приводит к появлению новых или изменению существующих методов ведения бизнеса (возможно, новых процессов или систем взаимодействия подразделений), которые обычно генерируют новые наборы данных.
4. Аналитики включают новые наборы данных в свои модели.
5. Бизнес опять задается вопросом "Как можно еще усовершенствоваться?"

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

4.2. Обретение большего МОГущества

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

Для практического воплощения этих идей мы предлагаем трехуровневый подход. При загрузке необработанных таблиц фактов или журналов следует использовать переходную (Staging) схему. Данными в этой схеме разрешается манипулировать только инженерам и некоторым аналитикам. В производственной схеме хранилища данных (Production Data Warehouse) сохраняются агрегаты, служащие большинству пользователей. К этой схеме предоставляется доступ подготовленным пользователям, комфортно чувствующим себя в крупномасштабной среде SQL. Поддерживается отдельная отчетная (Reporting) схема, содержащая специализированные статические агрегаты, используемые средствами генерации отчетов и случайными пользователями. Эта схема должна быть настроена таким образом, чтобы обеспечивать быстрый доступ к умеренным объемам данных.

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

Производственная схема обеспечивает быстрые ответы на распространенные вопросы, которые пока еще не настолько распространены, чтобы по ним требовались отчеты. Многие из этих вопросов предвосхищаются во время исталляции, а многие – нет. Долгое ожидание данных может привести к "маниакальному обжорству" ("feeding frenzies"), когда по отношению к этим данным начинает задаться один вопрос за другим. На этой стадии, когда бизнес-аналитики начинают проникать в новую среду, очень важна гибкость. Им нужна ежедневная или ежемесячная информация. Вопросы относительно ежедневных характеристик превращаются в информационные панели (dashboard).

Аналитикам следует предоставить внутри хранилиза данных еще и четвертый класс схем, который мы называем "песочницей" ("sandbox")¹. Схема-песочница находится под полным контролем аналитиков и может использоваться для управления их экспериментальными процессами. Аналитики являются ухищренными в данных разработчиками, и им часто требуется отслеживать свою работу и ее результаты и сохранять соответствующие данные в базе данных. Например, как мы увидем в разд. 5, для структуризации задачи кодирования при разработке сложных конструкций на языке SQL принято использовать SQL-представления в качестве "подпрограмм". В течение разработки, вероятно, эти представления будут определяться и часто редактироваться. Аналогично, аналитикам может понадобиться материализовать результаты запросов, выполненных при выполнении их исследований, и позже повторно их использовать; эта материализация может также помочь процессу разработки программного обеспечения и повысить эффективность в условиях итеративной разработки аналитического потока работ. Кроме того, аналитикам для собственного удобства часто хочется отложить про запас свои любимые наборы данных, чтобы использовать их при разработке новых методов над известными данными.

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

---

¹Не следует это путать с созданием изолированной среды программных процессов (sandboxing) с целью обеспечения компьютерной безопасности. Здесь мы понимаем слово "песочница" как место для игр.

Назад Содержание Вперёд