- PVSM.RU - https://www.pvsm.ru -

Константин Будник, EPAM: “Apache Hadoop перешел в фазу commodity — там почти не появляется ничего нового.”

В начале ноября в Киеве уже в шестой раз пройдёт одна из ключевых в Восточной Европе Java-конференций JavaDay 2017 [1]. Хотя до события еще достаточно времени, мы предметно пообщались с одним из спикером конференции — Константином Будником, Chief BigData Technologist и Open Source Fellow EPAM Systems — о силе open-source, Big Data и будущем Hadoop.

Константин Будник, EPAM: “Apache Hadoop перешел в фазу commodity — там почти не появляется ничего нового.” - 1

Вы почти 15 лет работали в Sun Microsystems, потом долгое время работали над Hadoop. Как развивалась ваша карьера?

Я работал в Sun начиная с 1994 года, с момента открытия офиса в Санкт-Петербурге — был сотрудником номер 6. Там я проработал 15 лет и занимался всем — от компиляторов до распределенных и кластерных системам. Я работал над операционной системой, над разными частями Java stack — в частности, в команде JVM, участвовал в разработке виртуальной машины, создал несколько фреймворков для разработчиков JVM.

Если рассматривать open-source, то я работал с открытыми технологиями примерно с 1994 года. В частности в середине 2000-х я помогал добавить Java в Linux Software Foundation, который создали незадолго до этого. Java стала частью LSB – Linux Standard Base. Тогда же немного поработал с Яном Мердоком — создателем Linux-дистрибутива Debian.

Начиная с 2000-х я начал заниматься распределенными системами, и за время работы в Sun я получил порядка 15 американских патентов в области распределенных вычислений и технологий.

В 2009 году я перешел в Yahoo и начал работать над Apache Hadoop — писал код, который шел в проект Apache. За первые 3 года работы в проекте Hadoop, я написал больше кода, чем, на тот момент, было у компании IBM. Конкретнее, я работал над HDFS – дистрибутивной файловой системой, для хранения данных в Hadoop, и системой распределенного fault-injection. После этого прошло некоторое время, и вот уже год я сотрудничаю с EPAM.

Над чем вы там работаете?

В EPAM есть департамент Big Data Practice. На сегодня он насчитывает около 300 экспертов в области обработки «больших данных». Часть из них занимается data science, еще часть — построением архитектуры для обработки больших объемов данных. Я Chief Technologist этого подразделения, и помимо этого, веду направление open-source software development для всей компании. ЕРАМ активно привлекает инженеров для поддержки open-source проектов на базе открытых систем и платформ, с помощью которых решает задачи по разработке продуктов.
 
Примечательно, что доля открытого ПО в Big Data составляет около 94-95%. «Закрытого» ПО коммерческого происхождения, которое используется для решения задач обработки «больших данных», очень мало.

Почему так?

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

Помимо этого, попадая в зависимость от одного производителя ПО, компания делает его «внутренним монополистом». Вендор, не советуясь с клиентом, поднимает цену лицензий или произвольно меняет набор технологических возможностей программного продукта. Чтобы избавиться от такого vendor lock-in нужны новые инвестиции: в смену оборудования, ПО, ротацию сотрудников.

Использование open-source решений гарантирует отсутствие таких проблем. Если вы работаете с Linux и Red Hat и эти решения вас больше не устраивают, вы можете перейти на открытые и бесплатные CentOS, Fedora, Debian, или купить поддержку Canonical для Ubuntu. С точки зрения бизнеса, особых изменений не произойдет. Когда речь идет об обработке критических для бизнеса объемов данных, уход от vendor lock-in превращается в насущную необходимость.

Вы уже двадцать лет в open-source сообществе. За это время оно изменило мир благодаря Linux и Android. Помимо этого, технологии open-source стали базой для разработки продуктов крупных компаний. В чем сила открытого сообщества, что его двигает вперед? Как крупным компаниям правильно строить взаимодействие с такими сообществами?

Идея довольно проста: людям интересно работать над тем, над чем им интересно работать. Это гениальный в своей простоте принцип. Open-source позволяет людям, даже если на основной работе они занимаются чем-то скучным, выразить себя. Человек приходит в такое сообщество и находит единомышленников, получает возможность сделать что-то уникальное — например, изменить направление разработки всего проекта в ту сторону, которую он считает нужной. Это очень мощный стимул для людей креативных и технологических.

Проследите за Линусом Торвальдсом: человек действительно поменял мир, потому что он умен, настойчив, продуктивен, увлекет людей своим примером и компетенциями. Этим open-source выгодно отличается от некоторых коммерческих разработок: здесь ценится что и как ты делаешь, а не как много и красиво ты говоришь и обещаешь. Такой принцип называется meritocracy и он — отличная альтернатива традиционной структуре управления. Его активно использует GitHub и ряд других компаний.

Если посмотреть на принципиальную разницу между коммерческой разработкой и open-source, то первая всегда основывается на том, ЧТО клиент будет покупать. Бизнес должен быть прибыльным. И если ты не политик или CEO компании Tesla, то заработать деньги можно только предложив людям то, что им действительно нужно. При этом сам инженер чаще всего «не видит» клиента и не понимает его потребностей — этим занимаются отделы технического маркетинга, продаж и тп. При этом разработчик чаще всего занимается очень специфическим направлением продукта в течение довольно долгого времени.

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

Конечно же остается конкуренция на уровне бизнеса. Есть разные стратегии коммерциализации open-source проектов. На рынке Hadoop-платформ есть три основных основных коммерческих игрока: Hortonworks (группа разработчиков Hadoop-системы в Yahoo!), Cloudera и MapR (очень мал). Все остальные, кто пытался строить свои дистрибутивы (IBM, Intel), в итоге либо ушли на какую-то из первых двух, либо пользуются Apache Bigtop для построения своих собственных платформ из канонического кода Апачи-проектов (Google DataProc и Amazon EMR).

Но они по-разному продают эти платформы своим клиентам. Cloudera добавляет поверх open-source  какие-то коммерческие закрытые компоненты вроде системы для менеджмента кластеров. MapR, например, добавил свою файловую систему, до боли напоминающую NFS. Hortonworks, с другой стороны, абсолютно все отдает в открытую — все их новые разработки идут в Apache. Этим они привлекают клиентов, демонстрируя, что у них все открыто и клиент может сам взять код и продолжать делать свое решение независимо.

Есть такое хорошее выражение: «There is no boss in open-source». Единственное требование — чтобы сообщество принимало твои наработки. Есть определенные стандарты, которым нужно соответствовать: качество кода, следование определенным технологическим принципам. Как только разработчик начинает соответствовать этим требования, он можешь участвовать в любом кусочке проекта и никто его не остановит. При этом, никто не заставляет заниматься этим конкретным фрагментом всю оставшуюся жизнь. Это дает возможность профессионально расти, улучшать свои навыки и наращивать технологическую базу.

А вы как open-source fellow в EPAM можете сказать, сколько процентов разработчиков компании коммитят в какие-то open-source проекты?

Процент оценить довольно тяжело, у нас все-таки больше 20 тысяч разработчиков. Но за последние шесть месяцев мы запустили интересный проект, в рамках которого целенаправленно контрибьютим в Apache Ignite, Apache Flink, Apache Zeppelin. Для понимания — в последней версии Apache Flink, из 100 contributors 10 человек сотрудничает с EPAM. У компании есть порядка 20-30 продуктовых проектов в open-source — начиная от управления тестовыми отчетами, веб-проектов, до анализа генома человека и обработки Big Data в облачных технологиях. Мы наращиваем экспертизу в стратегически интересных направлениях обработки Big Data для разработки продуктов и платформ для наших клиентов. На проекты можно посмотреть и поучаствовать через github.com/epam [2].

Если вернуться к big data и Hadoop, вы говорили, что смотрите на то, какие технологии интересны клиентам. Что это значит и как дальше будет развиваться Hadoop? Все-таки это уже достаточно зрелая технология.

Я может скажу не совсем то, что ожидают от человека, который много лет занимался разработкой компонент Hadoop-экосистемы — Hadoop  стабилизировался. Технология стала «взрослой», отработанной. Ее начали признавать в больших компаниях, стали использовать для внутренних инфраструктурных решений. Но активный цикл разработки ПО не бесконечен. Какое-то время происходит всплеск разработки, улучшений, а потом все стабилизируется. Вот эта фаза, когда наступает стабильность, называется commodity phase: технология становится обычной и доступной для всех. Hadoop перешел именно в эту фазу.

Кстати, забавно, что даже спустя 11 лет после появления Hadoop остается для многих мантрой: «надо его поставить и тогда все можно будет решить». На самом деле, нужен трезвый расчет — многие задачи решаются без распределенных вычислений или массивных кластерных платформ хранения данных. Например, весь веб-сайт StackOverflow живет на 4 серверах с SSD-дисками: мастер-копия самого StackOverflow, мастер-копия всего остального и две реплики. И они обслуживают 200 миллионов запросов в день. Сколько бизнесов в мире сталкивается с подобными объемами?

Как только технология становится commodity, в ней перестают появляться качественные улучшения. Hadoop изначально состоял из файловой системы для хранения данных и вычислительной системы для обработки этих данных — MapReduce. Он мало используется сегодня в силу своей неэффективности. Вместо MapReduce появился TEZ, Spark. Файловая система выжила, но ничего революционно нового там так не появляется. Файловая система HDFS делалась для создания больших хранилищ данных в дата-центрах. Компании вроде Amazon, Facebook, Yahoo!, Google, мобильные операторы хранят очень много данных. Но не все используют HDFS. Например, Google Spanner хорошо зарекомендовавшая себя глобально-распределенная файловая система. И все больше и больше не-инфраструктурных компаний начали уходить из своих дата-центров в облака Amazon, Microsoft или Google. А те кто остается в своих дата-центрах зачастую используют Open Stack с файловой системой Ceph.

Базовый слой, который был изначально Apache Hadoop, потихоньку начинает растворяться. Новые компоненты, которые изначально работали поверх него, начинают переключаться на работу в облачных технологиях. Это все по-прежнему называется Hadoop, хотя там уже больше 30 компонентов, из которых только два — это оригинальный Apache Hadoop. Hadoop перестал быть центром Вселенной. Не стал им и Apache Spark — он просто повторил историю Hadoop на немного другом уровне.

Сейчас идет активная миграция от собственно Hadoop в облачную область — и сокращение сегмента, где Hadoop используется для хбранения данных. Если очень нужно, можно взять кластер Spark задеплоить на AWS и не волноваться, есть ли там HDFS. Большинство бизнесов и разработчиков фокусируются на обработке данных, бизнес-игроков мало интересует как они хранятся. Скорость обмена данными с клауд файловой системой ниже чем с HDFS. И даже сильно ниже, если Вы не боитесь использовать решения Microsoft и пошли в Azure. Зато не надо тратить деньги на собственных специалистов, системных администраторов, покупать железо, которое устаревает быстрее, чем ломается. Побеждает простое и эффективное решение.

Например, Amazon много работал над реализацией self-serving system. Такая система не требует специалистов для запуска и обслуживания — любой человек может зайти в ее консоль, «нажать кнопочку», поднять кластер для обработки данных, закачать их и обработать. Набор навыков тоже становится commodity. Компании не нужен свой системный администратор для обслуживания сотни компьютеров, если есть 5 сисадминов в Amazon, которые обслуживают 100 тысяч серверов. Для запуска ресурсов в облаке и, может быть, релизов ПО нужен Devops.

Вычислительная мощности тоже становятся данностью — и люди фокусируются на том, какую пользу можно извлечь из данных: лучше продавать товары в магазинах или оптимизировать маркетинговое предложение, предсказав поведение клиентов. Технологическая часть обработки данных активно двигается в направлении predictive analytics — моделирования поведения, к примеру, покупателей. Мы обрабатываем исторические данные и строим модель, которая подскажет нам, что может случится. Второе актуальное направление — prescriptive analytics, когда мы обрабатываем объемы данных и делаем вывод, что для того, чтобы сделать на 10% больше продаж, нам нужно определенным образом поменять нашу маркетинговую стратегию.

Невозможно на 100% точно предсказать или смоделировать будущее. Но при условии, что подобные подходы позволяют поднять доверительный интервал результата с 25% до 60% — это, пусть и небольшая, но победа.

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

Используя методы машинного обучения и анализируя исторические данные с оборудования, мы теоретически можем предсказать с доверительным интервалом в, например, 94%, что этот подшипник выйдет из строя в следующие 4 дня. Заказав и получив этот подшипник заранее, производственный процесс можно планово приостановить на 30 минут, в итоге сэкономив миллионы.

Все эти технологии становятся все более доступными для не-программистов и все более ориентированными на типичного пользователя. В связи с тем, что данных становится все больше, должна расти и скорость из обработки — иначе теряется смысл всей игры. Поэтому все чаще можно встретить in-memory computing платформы, которые полностью работают в компьютерной памяти. Среди них Apache Ignite, изначально разработанный в компании GridGain, и Apache Geode, пришедший из Pivotal.

Распределенная обработка данных в памяти получает все больше внимания больших технологических компаний. Удивительный факт: компьютерная память подешевела за последние 20 лет почти в 100 000 раз. В номинальных долларах, без учета инфляции в почти 60% за то же время. Как мне кажется, это одно из направлений, где будет происходить много увлекательного и интересного в следующие годы — о других направлениях и трендах мы поговорим на JavaDay 2017 [1].

Автор: NadiaMatukhno

Источник [3]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/java/260269

Ссылки в тексте:

[1] JavaDay 2017: http://javaday.org.ua/

[2] github.com/epam: https://github.com/epam

[3] Источник: https://habrahabr.ru/post/332856/