Проблемы работы со сверхбольшими массивами данных

PwC: Работая в TransUnion вы опробовали многие технологии обработки больших объемов данных. Что вы думаете о Hadoop и MapReduce?

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

PwC: Какой класс задач вы имеете в виду?

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

Стек с открытым кодом отлично подходит для экспериментов, однако проблема в том, что, по нашим наблюдениям, Hadoop вовсе не Google, это всего лишь попытка группы умных парней повторить технологии Google. Они проделали хорошую работу, но, как и большинство программ с открытым кодом, их система доработана только на 80%. А недостающие 20% и есть самое сложное. С точки зрения экспериментов мы добились немалых успехов, доказывая, что вычислительные формулы, лежащие в основе MapReduce, действительно работают, однако программное обеспечение, которым мы располагаем сегодня весьма ненадежно и сложно в эксплуатации. Там есть неустраненные баги, и программа не слишком хорошо работает в операционном режиме. Кроме того, в нем заложен ряд загадочных ограничений, проявляющихся при увеличении масштабов и производительности вычислений.

Мы обнаружили ряд проблем с использованием стека данных HDFS/Hadoop/HBase для выполнения задач, которые по имеющейся документации должны были решаться. Однако на практике заложенные в коде ограничения привели к отказу задолго до того, что мы сочли бы подходящим теоретическим пределом. Конечно, доступность исходного кода является положительным аспектом. Однако это в то же время и отрицательный аспект. Для работы с таким программным продуктом исходный код необходим, но это совсем не то, чем мы хотели бы заниматься в своей повседневной деятельности. У меня есть немало хороших инженеров, но я вовсе не хочу, чтобы они тратили все свое время на техническую поддержку продукта, который должен был бы войти в нашу архитектуру в готовом виде. Да, этот продукт имеет определенный потенциал, но пройдет немало времени, прежде чем он достигнет достаточной стабильности, чтобы я был готов делать на него ставку.

PwC: За последние пару лет цены на оборудование для хранения данных значительно снизились. Если речь не идет о критически важных данных, то как компания может убедиться, что она не тратит на их хранение больше, чем необходимо?

ДП: Пожалуй, мы не слишком типичный пример, поскольку наша работа заключается как раз в анализе данных. Мы готовы заплатить любую цену за возможность получить более точные и быстрые ответы, поскольку мы закладываем эти расходы в стоимость наших услуг. Проблема сегодня в том, что новейшие инструменты не всегда работают как надо. Эта проблема актуальна как для аппаратного, так и для программного обеспечения. Многие поставщики заканчивают тестирование своих приложений на уровне 80 или 85% их теоретической готовности. В рабочем режиме мы загружаем их на 110% теоретиче- ских возможностей, и они отказывают. Меня не беспокоят тактические затраты на технологии, которые я рассчитываю быстро заменить. Такие расходы возникают постоянно. Но если уж я плачу деньги, я рассчитываю, что эта штука будет работать. И слишком часто оказывается, что она не работает.

PwC: Вы вынуждены использовать только проверенные технологии из-за опасения выйти за границы надежности?

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

PwC: Вы что-то используете вместо Hadoop?

ДП: В сущности мы применяем метод перебора. Мы используем Ab Initio, это очень удачная система распараллеливания задач по перебору. Я имею в виду определенные свойства в Ab Initio распараллеливании — извлекая, трансформируя и выполняя — таким путем я могу раздробить задачу.

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

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

TransUnion ежегодно получает 100 млн обновлений кредитных файлов. Мы обновляем большое хранилище данных, содержащее всю финансовую и сопутствующую информацию. Кроме того, ежедневно мы генерируем от 1 до 20 временных хранилищ, на использовании которых фактически и строится наша работа. Наши продукты объединяют то, что мы называем индикативные данные, — ту информацию, которая идентифицирует конкретного человека; структурированные данные, которые мы получаем из транзакционных записей, и неструктурированные данные, привязанные к дескрипторам. Мы складируем эти информационные продукты в процессе работы, поскольку данные могут меняться каждый день, иногда в день по нескольку раз.

Одна из стоящих перед нами задач заключается в том, чтобы точно определить место для каждого фрагмента данных. Например, у нас есть Джо Смит, проживающий по адресу Мэйн-стрит, дом 13, и есть Джо Смит, проживающий на Мэйн-стрит, дом 31. Это два разных Джона Смита или это просто опечатка? Нам приходится принимать такие решения по 100 миллионов раз на дню с помощью ряда специальных ал- горитмов поиска по шаблону и вероятностных алгоритмов.

PwC: С каким из этих трех типов данных труднее всего работать?

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

PwC: Работать с неструктурированными данными труднее потому, что они поступают из множества различных источников и во множестве различных стандартов, не так ли?

ДП: Да. У нас 83 тыс. источников данных. Не все они поставляют нам данные каждый день. Данные поступают примерно в 4 тыс. стандартов, невзирая на то, что у нас есть собственные стандарты обмена информацией. Чтобы иметь возможность обрабатывать данные достаточно быстро, мы должны перевести их все в единый формат обмена данными, соответствующий тому, который мы используем внутри компании. Все это сопряжено со сложными вычислительными проблемами.

PwC: Это и есть те проблемы обработки данных, с которыми компании в других отраслях столкнутся через три-пять лет?

ДП: Я думаю, да.

PwC: Какие еще проблемы, по вашему мнению, получат широкое распространение?

ДП: Вот несколько простых практических примеров. В целом по нашим контролем находится 8,5 петабайт данных. Когда ваши объемы данных значительно превышают 100 терабайт, накопители данных приходится менять каждые четырепять лет. Перенос 100 терабайт данных — это огромная физическая задача, занимающая много времени. Ее немного облегчает рост скорости соединения, но массивы могут перемещаться только с той скоростью, с какой происходит чтение и запись, и увеличить эту скорость обмена невозможно. А компании, находящиеся ниже нас по уровню сложности задач, не могут себе предста вить, что цикл обновления данных может занять месяц. Положим, цикл обновления компьютеров может занимать месяцы, но каждый отдельный его фрагмент занимает всего пару часов. Когда я перемещаю данные из одного массива в другой, я могу остановиться только тогда, когда процесс будет полностью закончен. И к тому же мне приходится иметь дело с багами и проблемами стабильности.

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

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

PwC: Компания Cloudera [разработчик решений на базе Hadoop] предложила бы перенести вычисления к данным.

ДП: Это годится только для определенных типов данных. Мы уже осуществляем все большие распределенные вычисления на основе системы файлов, а не баз данных. Кроме того, мы предусматриваем вычислительные циклы для архивации данных, чтобы перемещать меньше бит информации, затем разархивируем данные, считаем и снова архивируем их, чтобы экономить место на хранении данных. Оперируя четвертым по величине коммерческим кластером GPFS [общая параллельная файловая система, файловая система распределенных вычислений, разработанная IBM] в мире, мы обнаружили, что, когда вы выходите за пределы определенных размеров, средства управления параллелизацией попросту перестают работать. Именно поэтому я утверждаю, что Google работает не на Hadoop. Возможно, команда Google и решила эту проблему, но если это и так, они не собираются рассказывать, как они это сделали.