В России пока не так много предприятий, которые имеют достаточный опыт в реализации проектов больших данных, поэтому сегодня особенно ценно узнать мнение экспертов в этой области. В ходе форума «Управление данными 2019» Артем Меркулов, руководитель бизнес-направления Big Data Solutions компании «Неофлекс», рассказал нам об основных сложностях, возникающих в проектах больших данных, и о путях их преодоления.

- Какие аспекты систем больших данных вызывают трудности у заказчиков?

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

Что касается технических аспектов, то, и по нашим наблюдениям, и по оценкам экспертов, до 80% всех объемов работ приходится на предварительную подготовку и обработку данных, поэтому именно эти процессы требуют от заказчиков наибольшего напряжения.

- При реализациии каких компонентов систем больших данных возникают наибольшие трудности?

Всегда присутствует рутинная часть – например, загрузка информационного «сырья» в хранилище или озеро данных. Такого рода процессы нужно автоматизировать, и мы в нашей платформе Datagram эту функцию реализовали. Вторая группа трудоемких компонентов связана со сложной настройкой трансформации данных. Зачастую загрузка данных происходит отдельно от их преобразования (например, средствами языка Scala). Наша платформа позволяет использовать трансформацию любой сложности, при необходимости прибегая к помощи внешних инструментов. Третья группа связана с DevOps, непрерывной интеграцией и развертыванием создаваемых приложений. Эти инструменты должны пронизывать все решение, поддерживая работу большой, в том числе распределенной команды. Реализация таких инструментальных конвейеров посредством одного лишь ПО с открытым кодом оказывается весьма трудоемкой.

- Какие компоненты являются самыми дорогостоящими?

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

- Нередко компаниям приходится анализировать данные из новых источников. Насколько трудоемкой и затратной оказывается интеграция с ними?

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

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

- Как влияет на архитектуру и реализацию систем больших данных требование анализировать данные Интернета вещей?

Для Интернета вещей характерны две ключевые особенности. Первая – обработка потоков данных в реальном времени. Если система изначально не была спроектирована в расчете на потоковую аналитику, то, скорее всего, в нее придется внести серьезные изменения. Насколько это необходимо, будет зависеть от решаемой задачи. Одно дело – сбор потоковых данных и их анализ с определенной периодичностью (например, раз в сутки) и совсем другое – обработка данных «на лету»: чтобы выявлять аномалии или иные события, на которые надо реагировать немедленно, здесь требуется другая архитектура.

Вторая особенность – очень быстрый рост объемов данных при подключении источников Интернета вещей. Чтобы справляться с их потоком, нужна масштабируемая архитектура. Если возможности масштабирования недостаточны, то проблемы неизбежны, это касается и оборудования, и нагрузок на системные компоненты ПО. Проектируя системы больших данных для Интернета вещей, необходимо это учитывать и закладывать в них некоторый запас.

- Как правило, в проектах больших данных приходится сталкиваться с большим разнообразием источников, типов и форматов данных, а также с разными требованиями к их хранению и обработке. Охватить их одним ИТ-инструментарием часто не удается, поэтому решения получаются сложными. Как можно уменьшить эту сложность?

Первый, широко распространенный путь – использовать готовые дистрибутивы Hadoop. Самые популярные среди них — от Cloudera, объединившейся с Hortonworks, и от российской компании Arenadata. В эти дистрибутивы включены компоненты, которые покрывают около 80% потребностей, возникающих на предприятиях, к тому же они уже интегрированы между собой. Это существенно упрощает реализацию проектов и снижает их стоимость. Недостающие компоненты можно найти на рынке, заказать или разработать самостоятельно.

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

- Есть ли возможность снизить общую стоимость владения решениями для работы с большими данными?

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

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

Два года назад Сергей Золотарев, управляющий партнер Arenadata, в своем интервью Computerworld Россия (см. «Hadoop для цифровой трансформации», Computerworld Россия, 10 мая 2017) заявил, что Hadoop постепенно становится стандартной платформой хранения данных, на которую обратили пристальное внимание ведущие софтверные вендоры. Он также отметил, что в России ее начинают использовать компании «из первой десятки» самых продвинутых отраслей и даже многие госкомпании, это и подвигло российских разработчиков создать свой дистрибутив Hadoop. По окончании форума BIG DATA 2019 мы вновь встретились с Золотаревым, чтобы выяснить, насколько за прошедшее время изменились сам рынок Hadoop, возможности этого ПО и продукт Arenadata.

— Два года назад вы говорили, что в России Hadoop используют компании из самых продвинутых отраслей. Как обстоит дело сейчас?

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

— Что наиболее значимого произошло с Hadoop за это время с технологической точки зрения?

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

Второе — добавлена поддержка графических процессоров и, как следствие, появилась возможность решать задачи глубокого машинного обучения.

Далее, в Hadoop 3 реализована поддержка Docker-контейнеров. Это позволило работать с любыми типами контейнеров, а не только с «собственными» контейнерами Hadoop. Кроме того, раньше для Hadoop была характерна высокая требовательность к ресурсам в связи с необходимостью создания дополнительных копий данных. Эту проблему удалось решить.

— Как будет развиваться Hadoop в дальнейшем?

Если говорить в терминах кривой Gartner, то эта технология вышла на «плато продуктивности». Заказчики поняли, что «умеет» Hadoop и чего «не умеет». Последнее особенно важно, потому что когда Hadoop только появился, многие пытались на нем делать вообще все что придется. И часто разочаровывались — ведь, как правило, технология хороша для решения тех задач, для которых она разрабатывалась. Поэтому был некий закономерный спад, период неудовлетворенности, который уже пройден, и сейчас появилось осознание того, для чего можно использовать Hadoop, для чего — нет. Меняется и сам подход к Hadoop – сейчас заказчику нужен не «дистрибутив вообще», а набор сервисов для решения конкретных задач.

Еще одна важная тенденция — Hadoop уходит в облака. Собственно, одной из причин объединения в конце 2018 года двух крупнейших вендоров, Cloudera и Hortonworks, стало то, что им невозможно было в одиночку противостоять провайдерам типа Amazon, которые начали предоставлять Hadoop из облака.

Постепенно все осваивают возможности Hadoop 3, и я думаю, их активное использование начнется к концу этого года или в начале следующего. Мы тоже готовим версию нашего ПО на Hadoop 3. Она будет уже делаться для новой системы управления, мы уходим от старых систем, в частности от Hortonworks Ambari. Да и сама Hortonworks, вероятно, будет ее поддерживать полтора-два года, не больше.

Ну и, наконец, меняется сам рынок Hadoop. Если пять лет назад было пять или шесть конкурирующих разработчиков дистрибутивов Hadoop, то два года назад осталось трое — Cloudera, Hortonworks и MapR, не считая тех, кто на российском рынке. Сейчас, после объединения Hortonworks и Cloudera, фактически доминирует только одна компания.

И результаты этого объединения очень характерны для любого рынка, на котором идет консолидация и появился лидер, устанавливающий правила игры. У Cloudera была проприетарная система управления, у Hortonworks — открытая. И сейчас очевидно, что открытая система практически не развивается.

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

— А что появилось нового в продуктах Arendata?

Как и планировалось изначально, мы достроили универсальную платформу хранения данных — Arenadata Enterprise Data Platform. Из последних ее дополнений — в прошлом году мы представили «стриминговый» компонент платформы на базе Kafka. В феврале этого года мы выпустили систему управления Arenadata Cluster Manager. С ее помощью появилась возможность не только управлять платформой, но и организовывать процесс ее развертывания в любых средах — на собственных мощностях, в публичных и частных облаках. Это вызвало очень большой интерес — как у заказчиков, так и у облачных провайдеров, прежде всего российских. Ничего подобного на рынке нет.

— Ни у нас, ни на Западе?

У Amazon и Google есть очень похожие решения, но они вышли немного позже. Мы очень сильно угадали полтора года назад, когда начали разрабатывать этот продукт.

— Вы утверждаете, что создаете экосистему вокруг своего продукта. Что вы имеете в виду?

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

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

— Что еще в планах?

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

В целом сейчас идет поиск наилучших способов применения нашей разработки. Скажем, крупным компаниям очень тяжело работать с «открытыми» продуктами, им все-таки надо, чтобы эти продукты были доведены до «корпоративного класса», с соответствующим уровнем надежности, безопасности. Совместно с компанией «Яндекс» мы работаем над выпуском такого продукта на рынок и уже летом планируем представить корпоративную версию ClickHouse с необходимой поддержкой, документацией и т.д.

— А на Запад продавать платформу планируете?

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

Чтобы заложить основы для сбора растущего объема данных новейших моделей автомобилей, а также параметров функционирования своих производственных предприятий, компания Audi внедряет у себя ряд новых технологий с открытым кодом.

Выступая перед полным залом на конференции Dataworks в Берлине, два главных архитектора данных Audi Матиас Грауниц и Карстен Хербе рассказали о построении архитектуры хранения данных, поступающих из новых источников, и о тех уроках, которые им удалось извлечь в ходе этого процесса.

С 2015 года компания Audi, являющаяся крупным клиентом Hadoop, хранит данные в Hadoop Distributed File System (HDFS). «Начав с небольшого кластера в конце 2015 года, мы вместе с клиентами изучали возможность построения и запуска системы, которая отвечала бы предъявляемым к ней бизнес-требованиям, – сообщил Грауниц. – В кластере на базе Hortonworks Data Platform (HDP) имелось четыре узла, 96 ядер и 160 Тбайт пространства хранения».

Сегодня в компании развернуты производственный кластер Hadoop, имеющий 1 петабайт пространства хранения, 6 Тбайт оперативной памяти, 12 узлов и 288 ядер. Производственный кластер Kafka оснащен четырьмя узлами, 128 Гбайт оперативной памяти и 16 Тбайт памяти хранения.

Все это, впрочем, отнюдь не означает, что интеграция была беспроблемной. «Внедрение Hadoop в существующую производственную среду сопровождалось определенными сложностями, – подчеркнул Хербе. – Требовалось интегрировать все это с бизнес-системами и обеспечить соблюдение мер безопасности».

Схема внедрения была разбита на две части: первая касалась отверточной сборки в процессе производства, а вторая – использования данных, собираемых блоками управления автомобилем.

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

Что же касается данных автомобилей, каждая новая модель Audi передает в хранилище HDFS около 25 тыс. беспроводных сигналов, которые в дальнейшем анализируются персоналом компании.

Средства бизнес-анализа (в частности, Tableau) предоставляют сотрудникам основных подразделений доступ к собранной информации и помогают принимать решения при проектировании будущих моделей.

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

Сначала технология была опробована на данных тестовых автомобилей и только после этого внедрена в новейшей модели A8.

Грауниц признает, что сейчас компании не хватает облака. Все, что уже было построено, развернуто во внутренней ИТ-инфраструктуре компании и в ее частном облаке.

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

Для решения этой задачи выбор Audi пал на коннектор HDFS независимого поставщика Confluent, с помощью которого данные через конвейеры Kafka перемещаются в HDFS. Что же касается каталогов метаданных, они располагаются в облаке, поскольку их местоположение не зависит от конкретного места хранения данных.

Что делают с этими данными сотрудники Audi, мы пока не знаем, но будущие модели несомненно будут выстраиваться таким образом, чтобы данные можно было бы обрабатывать в ту же секунду, в которую они были зафиксированы блоками управления A8.

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

Тем не менее, как показали выступления в ходе конференции «Технологии больших данных 2017», поведенной издательством «Открытые системы», будущим рынка эксперты видят консолидацию инструментов – конвергенцию различных решений в рамках универсальных платформ, а главными точками его роста станут нейросети. При этом будет происходить резкий рост числа пользователей, главным образом за счет непрофессиональных аналитиков, которые начинают играть в работе с данными все более важную роль. Текущие же тенденции технологий под зонтиком больших данных заключаются в преобладании открытых платформ, возникновении экосистемы вокруг платформы Hadoop, а также переходе от пакетной обработки данных к обработке в реальном времени.

Не все данные одинаково полезны

«Не всегда ‘больше данных’ означает ‘больше денег’, существуют и обратные примеры. Часто данные обходятся компаниям слишком дорого, причем речь идет не только об их сборе и хранении», — заявил Максим Савченко, руководитель группы разработки моделей «Сбербанк-Технологии». Сама разработка моделей также требует средств, а полученные результаты далеко не всегда получается встроить в операционный контур бизнеса. Наконец, могут возникать регуляторные ограничения, и тогда все потраченные на работу средства окажутся пущенными на ветер, да и клиентам не всегда нравится, что компания хочет знать о них «слишком многое».

Любопытно, что многие виды личной информации, к использованию которой клиенты относятся особенно нервно, по словам Савченко, на самом деле не несут практической пользы. «Мы не лезем в подробности, которые бизнесу не нужны», — подчеркнул он. Например, «показуха» в виде предоставления компаниями в банк анкет о своих показателях работы не слишком эффективна для принятия решений о кредитовании. Гораздо полезнее последить за их транзакционной активностью. Ярким примером такого подхода может служить переход при работе с мелким бизнесом от оценок рисков по традиционным источникам к анализу транзакционных данных. В результате отказа от анкетирования просрочка по задолженностям не выросла, при этом портфель за полгода вырос на 10%, что в масштабах Сбербанка и при текущей экономической ситуации можно признать очень неплохим результатом.

«Перед тем, как пытаться построить какую-либо модель, надо не только собрать данные, но и понять, имеет ли смысл проводить эту работу, будет ли она экономически эффективной», — отметил Александр Сидоров, руководитель службы анализа данных HeadHunter. Выяснилось, что в рекрутинге машинное обучение дает хороший результат. В компании реализовано несколько таких проектов. Первый из них был связан с премодерацией резюме, второй – с подбором лучших вакансий по резюме, третий – с ранжированием откликов на вакансии. Как показала практика, пользователям ресурса очень нравится, когда экономят их время, а в случае HeadHunter речь идет про экономию в несколько человеко-месяцев в день. В долгосрочной перспективе, по мнению Сидорова, речь может идти не только об эффективности подбора и скорости поиска кандидатов, но и о том, что машина сможет взять на себя массу рутинной работы рекрутера.

«Алгоритмы машинного обучения неэффективны для работы с 'сырыми' данными. Данные требуется готовить: отбрасывать лишние из них, группировать факты, относя их к интерпретируемым категориям», — рекомендовал Дмитрий Бабаев, специалист по работе с данными компании МТС. Например, телеком-оператор обладает четырьмя типами фактов: посещенные локации, звонки, SMS и визиты в страны. Напрямую с ними работать очень тяжело. Однако группировка локаций по типам зданий дает возможность вычислить тип и режим работы абонентов, а работа с телефонными номерами – вычислить круги их общения.

«Несколько лет назад нами было принято решение о переходе от продукто-ориентированной к клиенто-ориентированной стратегии. Это означает совсем другие требования к прогнозной аналитике», — рассказал Руслан Хохлов, менеджер проектов ВТБ24. Как следствие, началась деградация производительности корпоративного хранилища, построенного на технологиях Teradata и SAS. Кроме того, решение стало неповоротливым, внесение изменений в него происходило в несколько раз дольше, чем требовалось. Решением стал перенос части функционала хранилища на платформу Cloudera Hadoop. В результате удалось не только взять под контроль производительность хранилища, но и сократить стоимость его расширения. Кроме того, была повышена доступность данных для анализа за счет устранения конкуренции за ресурсы системы действий пользователей и регламентных процессов.

Алексей Натекин: «Личные связи всегда были лучшим инструментом для поиска нужных людей, а в случае с аналитиками это верно вдвойне»

Не мешать работать

Как признал Валерий Артемьев, советник директора центра ИТ Банка России, уже длительное время перед инструментами больших данных сохраняются одни и те же барьеры. Наиболее очевидным из них является сложность комплексного использования инструментов в режиме «сделай сам». Кроме того, усложняется процесс работы с данными: с ростом их объема растет число ложных корреляций. Стоит упомянуть и чисто психологический барьер восприятия менеджментом результатов анализа из «черного ящика».

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

«Личные связи всегда были лучшим инструментом для поиска нужных людей, а в случае с аналитиками это верно вдвойне», — подчеркнул Алексей Натекин, директор Data Mining Labs. Как показывает практика, среднее время жизни специалистов по данным в компаниях очень невелико. Это связано как с частыми провалами начатых проектов (и, как следствие, расформированием команд), так и с тонкой душевной организацией таких сотрудников. Надо понимать, зачем и для чего компании нужны такие специалисты – по словам Натекина, многие проблемы связаны именно с непониманием этого. Важно давать им право на ошибку, но при этом фокусироваться на быстрых проектах, так как риск неудачи действительно очень велик.

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

Ключевыми анонсами конференции Informatica Day 2017, проведенной компанией Informatica в рамках мирового технологического турне совместно с российским партнером DIS Group, стали сообщения о выходе новых решений, ориентированных на конкретные насущные задачи предприятий различного масштаба.

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

Еще одним важным новшеством, по словам Ильи Гершанова, технического менеджера Informatica, стала обновленная версия интеллектуальных облачных сервисов, предназначенная для управления облачными данными в масштабе предприятия, а также ряд решений на базе CLAIRE – для управления данными о клиентах, поставщиках, продуктах предприятия, его НСИ, озерами данных, корпоративными каталогами, для управления данными масштаба организации, а также для обеспечения информационной безопасности источников данных. Появились в портфеле Informatica и решения для управления мастер-данными в системах Больших Данных, способные работать с Hadoop.

Помимо технологических анонсов, на конференции был широко представлен опыт заказчиков. Одни из наиболее масштабных российских проектов реализуются в Сбербанке, который использует технологии Informatica около шести лет. Как рассказал Борис Рабинович, директор центра компетенции развития BI-технологий компании «Сбербанк Технологии», ярким примером применения продуктов Informatica является проект внедрения и использования платформы In-Memory Data Fabric компании GridGain Systems. Технологии Informatica PowerCenter и Test Data Management помогают обеспечить интеграцию баз данных Oracle и Teradata. В текущем году планируется реализовать пилотные проекты по выгрузке данных из Oracle в Hadoop и из Teradata в Hadoop, а также из источников Hive в приемники на базе других СУБД. Кроме того, предполагается обеспечить интеграцию с платформой GridGain, системами машинного обучения и осуществить миграцию с прежних решений на новую платформу.

Еще одно интересное направление проектов Сбербанка – обезличивание данных, призванное обеспечить защищенность персональных данных клиентов банка и предотвратить их утечки в ходе разработок, а также нагрузочного и функционального тестирования совершенствуемых и новых систем. С помощью автоматизированной системы на базе Informatica Test Data Management уже удалось обезличить 30 баз данных общей емкостью 50 Тбайт, используя при этом около 150 уникальных правил. Применяемая в банке технология обезличивания позволяет сохранять некоторые важные признаки, такие, например, как пол клиента, контрольный разряд номера карты и пр. В течение ближайшего года планируется обезличить еще 150 реляционных баз данных и выстроить процесс обезличивания данных в Hadoop, GridGain, а также выбрать технологию псевдообезличивания в Hadoop с применением шифрования, динамического маскирования и других методов, которая позволит безопасно предоставлять данные аналитикам.

В компании Tele2 технологии Informatica PowerCenter применяются в качестве основного ETL-средства в первую очередь при загрузке корпоративного хранилища данных, куда стекается информация из более чем 100 источников. Ключевые направления использования хранилища данных – подготовка кампаний целевого маркетинга и расчет KPI на основе единого слоя данных. По словам Ники Пономаревой, руководителя департамента развития систем машинного обучения и бизнес-анализа Tele2, проект хранилища данных окупился гораздо быстрее, чем рассчитывали. Примечательно, что в ходе его реализации был сформирован офис проектов Больших Данных. Еще одна интересная деталь: при создании новых функциональных возможностей для анализа данных применяются как гибкая (на базе Scrum), так и классическая нисходящая разработка, выбор их производится исходя из целей и задач конкретного проекта.

Три года назад Сергей Золотарев, глава представительства Pivotal в России и СНГ, на форуме BIG DATA 2014 говорил о том, как важно уметь «прикрутить» Hadoop к реальным корпоративным ИТ-средам (см. «BIG DATA 2014: интеграторы миров», Computerworld Россия, 16 апреля 2014). В 2017 году на очередном форуме BIG DATA он, уже в качестве руководителя направления по разработке линейки собственных продуктов компании IBS для работы с данными, представил российскую версию дистрибутива Hadoop. В Computerworld Россия расспросили Золотарева о том, что произошло на российском и мировом рынке Hadoop за эти годы, для чего рынку еще один дистрибутив и чем российская разработка отличается от зарубежных.

- Насколько поменялась ситуация на рынке Hadoop за три последних года?

Ситуация изменилась кардинально. Три-четыре года назад на Hadoop делались в основном пилотные проекты — крупные телеком-компании и банки только приглядывались к этой платформе. Сейчас крупнейшие игроки на рынке коммерческих приложений, такие как SAP, SAS, IBM, Tableau, стали использовать Hadoop в качестве стандартной платформы хранения данных наряду с традиционными СУБД. И это, безусловно, с одной стороны облегчило адаптацию Hadoop в корпоративную инфраструктуру, потому что за эту задачу взялись крупнейшие вендоры. С другой стороны, интерес гигантов дал зеленый свет для инвесторов, и в разработки вокруг Hadoop хлынули огромные инвестиции. Hadoop превратился в огромную экосистему, в разработку которой вложены сотни миллионов долларов и миллионы человеко-часов.

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

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

Отчасти поэтому, на мой взгляд, уходят из употребления такие термины, как «озера данных», и даже сам термин «Большие Данные». Все чаще в ходу понятие Data Platform, или Enterprise Data Platform — платформа работы с данными данных.

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

- Почему вы решили создать свою версию дистрибутива Hadoop?

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

Следующий важный момент – доступность сложной экспертизы по решению. И касается это не только России, но и Европы в целом. Для основных разработчиков дистрибутивов Hadoop главный рынок — это рынок США. А еще точнее — рынок Калифорнии, потом остальной американский рынок, потом Великобритании. Европа, и тем более Россия для них не так важны. Я могу это сказать по своему опыту, поскольку сам работал в крупном западном вендоре. Ресурсы на Европу и Россию выделяются крайне ограниченно, специалистов очень мало, поддержка доступна только удаленно, и к тому же такого качества, что не всегда позволяет устранить проблемы, возникающие в ходе комплексных проектов.

В какой-то момент мы поняли, что недостатки имеющихся на рынке продуктов, в сочетании с высокими ценами на их доработку под заказчика и поддержку, создали нишу для отечественного дистрибутива Hadoop, и если его сделать, то он будет востребован рынком. В 2015 году мы присоединились к Open Data Platform Initiative, международному сообществу разработчиков программных продуктов с открытым кодом в области Больших Данных. В прошлом году созданный нами дистрибутив ArenaData Hadoop был сертифицирован по спецификации ODPi, сравнявшись в этом отношении с разработками крупнейших западных компаний.

- Почему ваша команда вошла в состав IBS?

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

- В чем отличия вашего дистрибутива от иностранных аналогов?

«Технически» наш продукт от западных аналогов не отличается, да и не должен, потому что есть единая, утвержденная ODPi спецификация, как должен собираться дистибутив Hadoop, и мы ей следуем. ArenaData Hadoop — полноценный корпоративный дистрибутив, в нем полный набор средств, позволяющих автоматизировать процесс установки и планирования кластера Hadoop, дальнейшие процессы, связанные с его мониторингом, администрированием, модернизацией и т. д. Для российских пользователей принципиальное преимущество использования нашего дистрибутива – это прежде всего доступная локально экспертиза по разработке архитектуры решения, русскоязычная документация, поддержка на русском языке, более доступные цены на специалистов и поддержку.

Мы готовы предоставить ArenaData Hadoop не только как программное обеспечение, но и как программно-аппаратный комплекс на базе разработанной в IBS платформы «Скала-Р» с единой поддержкой всего комплекса. Последнее важно: я уже говорил, что большая наша проблема сейчас — отсутствие экспертизы, подкрепленной реальным опытом.

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

Важная техническая особенность ArenaData — мы собрали все необходимые репозитории не только для Hadoop, но и для всего программного окружения в пакет, который можно развернуть без подключения к Интернету. Работая у крупнейших российских заказчиков, мы столкнулись с тем, что практически у всех создан закрытый контур, нет возможности выхода в Интернет из корпоративной сети, а все существующие на тот момент дистрибутивы предполагали, что установка идет в режиме онлайн и все вспомогательные утилиты, библиотеки и т. п. скачиваются с самых разных сетевых ресурсов.

- Как потом продукт обновлять, тоже офлайн?

Да, тоже через съемные носители. Мы это предусматриваем при создании новых релизов продукта.

- Насколько вырос спрос на Hadoop в России?

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

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

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

Новая система Urika-GX стала первой платформой для гибкого анализа с помещением суперкомпьютеров в открытую корпоративную среду.

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

«В прошлом некоторые вида анализа проводились ежедневно или даже еженедельно, – заметил старший вице-президент компании Cray по продуктам Райан Уэйт. – Сегодня они выполняются с интервалом в шесть часов или даже каждый час. Это позволяет постоянно следить за тем, что делают клиенты».

Urika-GX обеспечивает параллельную нагрузку для Hadoop, Spark и графических технологий. Ресурсы перераспределяются динамически, а открытая структура позволяет выполнять необходимые настройки.

Благодаря предустановленному программному обеспечению систему можно развернуть и ввести в эксплуатацию всего за несколько дней.

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

В целом, новая система при выполнении сложных запросов работает в три раза быстрее, чем Urika предыдущего поколения.

Urika-GX монтируется в стандартной 19-дюймовой стойке и оснащается стандартными процессорами Intel Xeon суммарным числом ядер до 1728. Объем оперативной памяти ограничен 22 Тбайт. В одной стойке могут размещаться твердотельные накопители общей емкостью 35 Тбайт и жесткие диски объемом 192 Тбайт. Обмен данными осуществляется при помощи высокоскоростной шины Cray Aries.

«Границы рынков Больших Данных и высокопроизводительных вычислений становятся сегодня все более размытыми, – указал старший аналитик Enterprise Strategy Group Ник Руда. – Тенденцией, которую Cray может использовать в своих интересах, является переход к программно-аппаратным комплексам или инженерным системам, специально предназначенным для работы с Большими Данными. В настоящее время эта модель еще не является самой распространенной, но популярность ее растет. В дальнейшем мы прогнозируем увеличение ее доли и выход на ведущие позиции, обусловленный преимуществами в производительности, окупаемости и наличии поддержки. Предложения Cray помимо всего прочего отличает упор на высокоскоростные сети. Среди других поставщиков, придерживающихся аналогичного подхода, можно выделить Oracle и Teradata. Главной же задачей для Cray сейчас является повышение осведомленности потенциальных клиентов о новых предложениях».

По мнению Андрея Пивоварова, руководителя группы перспективных технологий предпроектного консалтинга Oracle СНГ, в России уже имеется немало заказчиков, ясно представляющих себе возможности технологий Больших Данных и изучающих сценарии их монетизации. Причем речь идет не только о Hadoop и хранении больших объемов данных, но и о сборе в реальном времени огромных потоков данных и их обработке.

- На каких направлениях, связанных с технологиями Больших Данных, сегодня концентрируются в Oracle?

Корпорация направляет свои усилия на создание оптимизированных программно-аппаратных комплексов, интеграцию Больших Данных, развитие собственной базы данных NoSQL, ускорение доступа к Большим Данным, их безопасность, визуализацию Больших Данных, а также на методологию построения систем Больших Данных. Именно в этих областях у заказчиков сегодня возникают наибольшие проблемы. На них указывает и эволюция Hadoop – одного из ключевых элементов технологий Больших Данных. Изначально эта технология существовала как программная система с открытым кодом, и развивало ее сообщество энтузиастов-разработчиков для задач обработки логов веб-сайтов. Поэтому, например, в ней изначально не было необходимых функций безопасности, таких как разграничение доступа пользователей к данным, ведь ее создателей больше заботило другое – загрузить большие массивы данных и эффективно их обработать.

Немало возникает и вопросов, связанных с архитектурой СУБД, в организациях, где есть Большие Данные. В Oracle работает группа архитекторов, которые собирают примеры использования и готовят документы с рекомендациями, касающимися, в частности, построения гибридных систем, включающих обычные СУБД, Hadoop, NoSQL, средства бизнес-аналитики, Data Discovery и пр. Своими наработками они делятся с заказчиками.

- Кластеры Hadoop нередко создаются на основе недорогих серверов. Почему в Oracle стали предлагать фирменное программно-аппаратное решение?

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

- Нередко обмен данными между имеющимися в организации системами баз данных и Hadoop превращается в отдельную проблему. Что можно здесь посоветовать?

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

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

- Есть ли смысл визуализировать Большие Данные, не прибегая к их серьезной предварительной обработке?

Да, есть. Один из автопроизводителей – наших заказчиков, используя решения Data Discovery, анализирует жалобы клиентов: изучает неструктурированную информацию, содержащуюся в жалобах, находит закономерности и глубже исследует проблемы, которые за ними стоят. Например, если обнаруживается, что в жалобах часто встречаются слова «скрип», «поворот руля» и при этом известно, что авторы жалоб ездят на машинах определенных партий какой-то модели, то есть смысл тщательно исследовать эти партии на предмет дефектов.

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

- Среди Больших Данных встречаются не только большие массивы, но и потоки данных. Какие есть возможности для их сбора и обработки?

Один из наших заказчиков проводит испытания авиадвигателей и во время прогона собирает данные от датчиков, записывает их с помощью нашей распределенной СУБД класса NoSQL, а затем анализирует. Эта СУБД вобрала огромный опыт фиксации в реальном времени большого количества мелких транзакций, таких как показания систем АСУ ТП.

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

- На какие технологии Больших Данных наблюдается спрос в России?

Использование технологий Больших Данных в России входит в стадию зрелости. Чаще всего этими технологиями Hadoop интересуются крупные предприятия – в первую очередь банки, телекоммуникационные компании и розничные сети, причем разговор с ними идет о вполне конкретных бизнес-задачах и технологиях. Интерес к Hadoop вполне объясним: эта технология позволяет собрать воедино и хранить не только те данные, что обычно загружались в хранилища, но также старые структурированные данные, неструктурированные данные из открытых источников и пр.

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

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

В стремлении представить Большие Данные как доступную и понятную аналитику организациям все чаще приходится задумываться о переносе соответствующих функций в облако. Отдавая предпочтение Большим Данным, предлагаемым в качестве сервиса, когда поставщик берет на себя требующее серьезных затрат времени и ресурсов управление технологиями Больших Данных (Hadoop, Spark, Hive и пр.), предприятия получают возможность избавиться от черновой работы и переключить внимание на преимущества Больших Данных.

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

Доминирующей и коммерчески применяемой сегодня технологией Больших Данных является Apache Hadoop. Она используется вместе с другими компонентами в составе расширяющейся экосистемы Hadoop: средствами обработки данных в оперативной памяти Apache Spark, инфраструктурой хранилищ данных Apache Hive и системой хранения Apache HBase NoSQL.

Рэйми Стата, генеральный директор компании Altiscale

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

• Высокопроизводительное, готовое к поддержке аналитических средств хранилище данных на базе Hadoop. Как ускорить обработку Больших Данных и обеспечить поддержку аналитики? Лучший способ построить дружественную к аналитическим функциям среду Больших Данных — создать аналитическое хранилище, куда будут загружаться часто используемые наборы данных из озера данных Hadoop, и структуризировать многомерные модели. Имея в своем распоряжении готовый к применению аналитических средств набор данных поверх Hadoop, организации смогут быстро получать ответы на свои запросы. Такие модели понятны для бизнес-пользователей и упрощают исследование изменения контекста бизнеса с течением времени.

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

• Семантический уровень, упрощающий «бизнес-язык» анализа данных. Как обеспечить доступ к Большим Данным самому широкому кругу бизнес-пользователей? Чтобы скрыть сложность необработанных данных и представить их бизнес-пользователям в понятных бизнес-терминах, нужен семантический уровень. На таком уровне обеспечивается логическое представление данных, к которому применимы бизнес-правила.

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

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

• Среда Больших Данных с множественной арендой. Как обращаться к Большим Данным без привязки к конкретному местоположению пользователя? В условиях повсеместного спроса на аналитику организациям необходим гибридный централизованно-децентрализованный подход к данным. Это позволит различным командам использовать локальные наборы данных и семантические определения, сохраняя доступ к ресурсам корпоративных данных, создаваемых ИТ-службой.

Такой гибридный подход реализуется посредством множественной аренды данных. При этом на ИТ-службу возлагается сбор и очищение данных из озер Hadoop, а также подготовка к созданию централизованного семантического уровня и проведению анализа сохраняемых данных.

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

• Удобные способы использования аналитики. Как сделать анализ Больших Данных удобным для пользователя? На последнем этапе процесса доставки Больших Данных конечным пользователям необходимо рассмотреть форму их представления. Интерфейсы данных должны отвечать индивидуальным потребностям всех пользователей. Это предусматривает создание интерактивных инструментальных панелей для бизнес-пользователей, интуитивно понятных визуальных инструментов анализа и точных, заранее спланированных отчетов для потребителей информации.

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

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

Hadoop, Spark и Kafka уже оказали огромное влияние на мир Больших Данных, и вот теперь на очереди новый проект Apache, обещающий в корне изменить сложившуюся ситуацию.

Для Apache Software Foundation проект Arrow, который призван вывести на новый уровень производительность неоднородных аналитических систем, обрабатывающих данные в оперативной памяти, приобрел первоочередное значение.

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

В реализации новой инициативы примут участие разработчики, которые внесли свою лепту и в другие проекты Больших Данных Apache: Calcite, Cassandra, Drill, Hadoop, HBase, Impala, Kudu, Parquet, Phoenix, Spark и Storm.

«Сообщество сторонников программного обеспечения с открытым кодом решило объединить свои усилия в работе над Apache Arrow, – сообщил вице-президент Apache Software Foundation Жак Надо, курирующий новый проект и проект Apache Drill. – Мы полагаем, что в ближайшие несколько лет большая часть данных в мире будет обрабатываться с помощью Arrow».

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

«Колоночное представление данных в памяти позволяет использовать при решении задач множество систем, приложений и языков программирования и избежать характерных издержек», – пояснил вице-президент Apache Incubator и член комитета управления проектом Apache Arrow Тед Даннинг.

Вот почему у Arrow сразу же появилось очень много поклонников, к числу которых относятся не только наиболее известные партнеры Apache, включая разработчиков проектов Calcite, Cassandra, Drill, Hadoop, HBase, Impala, Kudu, Parquet, Phoenix, Spark, Storm, Pandas и Ibis, но и такие компании, как Cloudera, Databricks, Datastax, Dremio, Hortonworks, MapR, Salesforce и Twitter. В качестве общей основы для механизмов исполнения команд SQL, систем анализа данных, хранения и обработки потоков и очередей программное обеспечение Arrow позволит добиться более высокой производительности и интероперабельности.

«Колоночное представление данных в памяти помогает системам и приложениям наиболее полно задействовать ресурсы оборудования в процессе обработки, – пояснил автор идеи Apache Kudu и член комитета управления проектом Apache Arrow Тод Липкон. – Современные процессоры ориентированы на параллельную обработку данных с помощью векторных операций и инструкций SIMD. Arrow упрощает организацию такой обработки».

Помимо традиционной реляционной структуры, Arrow поддерживает сложную организацию данных и динамические схемы. К примеру, можно управлять данными JSON, получившими широкое распространение в Интернете вещей, современных приложениях и файлах системных журналов. Уже доступна поддержка различных языков программирования, включая Java, C++ и Python. По словам Надо, к концу года планируется реализовать R и JavaScript. Примерно в те же сроки Arrow появится в арсенале Drill, Ibis, Impala, Kudu, Parquet, Spark и ряда других проектов: поддержка множества различных языков программирования способствует повышению интероперабельности.

«В обыденной жизни чаще всего используются сценарии, предусматривающие сложное сочетание структурированных и неструктурированных данных, – указал член комитетов управления проектами Apache Drill и Apache Arrow Парт Чандра. – Колоночное представление и обработка данных в памяти, уже доказавшие свою эффективность в Apache Drill, позволят Arrow объединить высокую производительность колоночной обработки с гибкостью JSON».

Программное обеспечение Apache Arrow будет распространяться по лицензии Apache License v2.0 и контролироваться наиболее активными участниками проекта. По словам Надо, первая официальная версия Arrow появится в ближайшие несколько месяцев.