Подведение итогов в конце года — это так скучно, и однако же все этим занимаются. Прогнозы делать тоже скучно — да еще и тяжело. Разумеется, в этот раз все не так, ведь речь идет о больших данных.
Каким образом специалисты по большим данным составляют свои итоговые отчеты и прогнозы в конце года? Первое, что приходит на ум, — они используют большие данные, однако такой подход чреват определенными проблемами: сами по себе данные не несут в себе никакой обобщенной информации — приходится выяснять обстоятельства, стоящие за этими данными, рассматривать их под нужным углом и искать в них смысл. Вдобавок такой подход не учитывает тонкие нюансы, отраслевые знания и большие идеи.
Перефразируя высказывание Карла Сагана, «мы хотим отыскать истину, где бы она ни была. Но для поиска истины нам потребуется и воображение, и скептицизм данные одновременно. Мы не побоимся строить догадки, однако мы будем осторожны, чтобы не перепутать догадки с фактами». В духе этого высказывания давайте подходить к реальности с такой же долей критичности и объективности и в 2017 г.
Тому Hadoop, который мы знаем, пришел конец, и я не переживаю
В 2016 г. Hadoop исполнилось десять лет. Он прошел долгий путь от проекта-хобби, названного в честь игрушечного слона, до (метафорического) сметающего все на своем пути чудовища, чье имя плотно закрепилось в списке модных словечек любого уважающего себя генерального директора. Недавний опрос, посвященный зрелости технологий больших данных, показал, что 73% опрошенных внедрили Hadoop в свои производственные процессы (против 65% в прошлом году). И все же мы ответственно заявляем, что тому Hadoop, который мы знали, пришел конец. И это даже не бог весть какая новость.
На протяжении своей жизни Hadoop постоянно развивался, расширялся и заново изобретался. Вокруг изначально голого каркаса продукта образовалась громадная экосистема, и сегодня Hadoop — это скорее платформа, а не «просто» фреймворк для вычислений и хранения данных. Решающую роль в его развитии сыграло появление системы планирования заданий YARN, благодаря которой Hadoop стал операционной системой для больших данных и смог подняться над своими пакетно-ориентированными истоками, основанными на модели MapReduce.
В 2016 г. все данные и сводки с полей указывали в одном и том же направлении: пакетный Hadoop на базе MapReduce умер — да здравствует Spark Hadoop в режиме реального времени. Сегодня 25% организаций используют Spark в рабочих проектах и еще 33% используют его в разработке, причем в этом процессе задействованы все крупные Hadoop-вендоры. Применив несложную арифметику, можно рассчитать, что к концу 2017 г. до 50% организаций будут использовать Spark на производстве.
Но в будущем речь не идет о том, что «или Spark, или пропал»: во-первых, Spark не единственное потоковое ПО на рынке, во-вторых, Hadoop — это не единственная платформа для больших данных. Альтернативы есть, и пользователи могут перейти на них либо плавно, либо семимильными шагами, и вообще обойти стороной Spark и Hadoop, как они это делают в настоящее время, уходя от MapReduce или полностью пропуская этот этап.
Ландшафт больших данных пестрит множеством различных направлений. Но что-то все больше складывается впечатление, что все стремятся добавить у себя возможности, которые предлагают другие компании. Это взаимопроникновение или обычное копирование?
Попытка всем угодить, чтобы сэкономить
Spark может обрабатывать данные как в потоковом, так и в пакетном режиме. А еще он поддерживает SQL и вычисление графов. И, разумеется, в самом Hadoop также можно работать с SQL и/или с NoSQL множеством других способов, применяя широкий набор инструментов. В этом-то и состоит смысл экосистемы, разве нет? А с другой стороны, опять-таки, сегодня так поступают все, кому не лень.
Такие базы данных NoSQL, как Cassandra/DataStax Enterprise, теперь тоже поддерживают графы, в дополнение к представлению данных в виде пары «ключ-значение» и в форме таблиц и документов. А что же насчет образцового хранилища документов на базе NoSQL — MongoDB? Теперь помимо документов там также можно работать в SQL. А SQL Server от Microsoft? Это вам больше не обычный SQL-сервер: теперь он работает под Linux, поддерживает язык R, обработку данных в памяти и хранение в колонках. Даже MariaDB, бюджетный вариант SQL-сервера, теперь поддерживает организацию данных в колонках.
А культовая графовая БД Neo4J? Она теперь поддерживает требования ACID. Сервис Google BigQuery теперь понимает стандартный SQL, как, впрочем, и Amazon Redshift, который уже довольно давно имеет этот функционал и работает на Postgres. Конечно, аналитические колоночные БД уже давно поддерживают SQL. А традиционные реляционные БД вроде Oracle и IBM также с некоторых пор стали добавлять разные возможности, такие как обработка данных в памяти и хранение в колонках. Этим занялись все подряд: БД с хранением данных в форме «ключ-значение», БД с хранением документов, графовые БД и даже крупные SQL-БД.
Границы стираются по мере того, как растущее количество платформ пытается объять необъятное и угодить как можно большей аудитории. Возможность делать все сразу на одной и той же платформе выгодна вендорам, которые хотят удержать у себя побольше клиентов, и привлекательна для пользователей, которым не приходится для выполнения рабочих задач смешивать и сочетать разрозненные платформы. Но это отнюдь не ровная дорога — на ней могут встречаться и препятствия. Среди самых существенных из них — замыкание на одного вендора, «сырые» функции и недовольные пользователи.
Кто-то пытается сосредоточиться на основных функциях, а кому-то подавай заоблачные цели. И все же в области больших данных всем найдется место.
Пирамида потребностей больших данных
Так много функций и так мало времени. Взрывной рост функционала вписывается в цикл, определяемый спросом: по мере того, как развивается инфраструктура, активно генерируются данные, ранние адепты технологий ощущают конкретную выгоду от их использования и растет количество вариантов их применения, что в свою очередь ведет к повышенному спросу на дополнительные возможности вроде обработки графов или хранения в колонках, которые раньше считались уделом очень крупных и/или зажиточных организаций.
Несмотря на культивируемые в СМИ бравые истории успеха, большинству организаций со всем этим сейчас разбираться не с руки. И это понятно, ведь скорость перемен превышает способность осмысливать их и поспевать за ними. Что касается разработчиков на обоих фронтах (в штате вендоров и разработчиков приложений), у них и трудности побольше, и ставки повыше.
Разумеется, все это нельзя назвать новостью. IDC назвала эту ситуацию «третьей платформой», но, если абстрагироваться от названий, станет ясно, что где-то мы это уже видели: многие пытались запрыгнуть в этот поезд, и немногие на нем доехали — рост доткомовского пузыря и его последующий разрыв, возникшее поначалу сопротивление уступило место безоговорочной приверженности, более или менее успешная унификация разрозненных фреймворков в корпоративных средах серверов приложений, нехватка кадров и суперталантливые разработчики, концепция длинного хвоста применительно к организациям и их сотрудникам.
Что изменилось сейчас? Темпы перемен, в целом стимулируемые и подгоняемые самими данными, приводят к своеобразному самосбывающемуся пророчеству: информационно-ориентированный продукт -> больше данных -> более качественная аналитика -> больше прибыли -> больше инвестиций -> улучшенный продукт -> больше данных. В то время, как некоторые до сих пор с трудом справляются с фундаментальными задачами сбора и хранения данных, вопросами управления, безопасности, корпоративной культуры и кадровой квалификации, другие больше озабочены вершиной пирамиды потребностей больших данных — семантикой и метаданными либо новыми формами распределения данных.
Замкнутая цепь ИИ: большие инвестиции порождают более успешные результаты, а те в свою очередь порождают еще больше инвестиций.
Уловки машинного обучения и искусственный интеллект для народа
Что может находиться в этой пирамиде выше, чем искусственный интеллект? На первый взгляд, зависимость между с виду приземленными заботами вроде интеграции данных наряду с обеспечением их качества и искусственным интеллектом не очевидна. Однако если присмотреться повнимательнее, эта связь становится явной, так как от больших данных к ИИ прослеживается четкая последовательность. Пусть даже
Народ в своей массе все еще пытается адаптироваться к факту существования машинного обучения (ML), и вокруг всего, что является его неотъемлемой частью, возникает такой же ажиотаж, как и вокруг ML в целом. Но не стоит забывать, что объект ажиотажа не всегда бесполезен, и ML в общем и целом показало хорошие результаты. Примеров хоть отбавляй — от простых рекомендаций до помощи с интеграцией данных, от обнаружения попыток мошенничества до автоматического исправления запросов. Однако ажиотаж подразумевает наделение терминов дополнительным смыслом, для которого они не предназначены и не подходят.
В недавнем обсуждении с представителями компаний, которых попросили высказаться, считают ли они свои предприятия (сейчас или в будущем) основой для разработки приложений с элементами ИИ, они дали разные ответы. Некоторые сразу четко обозначили свои скромные устремления и познания в этой области, другие не стали отбрасывать эту идею полностью, но ясно дали понять, что на данном этапе еще не готовы, а третьи ухватились за эту возможность, чтобы ответить что-то в духе «конечно, мы занимаемся ИИ — у нас ведь работают эти
А что насчет очередной сенсации — глубинного обучения? Оно стало еще одной нашумевшей в 2016 г. информационно-ориентированной технологией на тему ИИ, но, опять-таки, по уважительным причинам. Есть ли у нее фундаментальные отличия по сравнению с ML, если да, то какие, могут и должны ли организации уже сегодня использовать глубинное обучение, и если да, то каким образом и чего они с его помощью могут достичь? Все это актуальные вопросы, на которые в данный момент далеко не многие люди могут дать адекватные ответы.
Супер, давайте все перенесем свои данные в облако... или стоит повременить?
Данные и метаданные, находящиеся в облаке и относящиеся к нему
Настроения по отношению к хранению больших данных в облаке кардинально изменились, причем до такой степени, что ставить под сомнение целесообразность использования облака — значит идти вразрез со здравым смыслом. Увы, облако далеко не всегда является правильным ответом на вопрос «что мне делать со своими большими данными?». Это не панацея от всех проблем с большими данными, и оно даже само по себе может создать дополнительные трудности.
И снова сводки с полей и данные совпадают: 53% респондентов отчета о зрелости технологии больших данных сегодня хранят тот или иной объем больших данных в облаке, и 72% планируют делать это в ближайшем будущем. Но ключевые слова здесь «тот или иной объем». Не всегда имеет смысл переносить все в облако, по крайней мере, не всегда для этого стоит применять модель lift-and-shift (модель миграции в облако, при которой переносятся точные копии, реплики существующего ПО без учета местных особенностей облака).
Для приложений, которым необходимо осуществлять сбор и обработку потоковых данных, облако подходит наилучшим образом. Но по мере того, как данные теряют свою актуальность, если их все еще нужно держать под рукой, имеет смысл перенести их в корпоративное озеро данных, так как в конечном итоге все упирается в дилемму — арендовать или покупать, нести операционные или капитальные расходы. На то, чтобы держать данные в облаке, также есть здравые причины: если вычисления происходят прямо там (а все чаще именно так и бывает), то каждый раз разворачивать дополнительные кластеры и перемещать туда-сюда данные может быть накладно. По мере того, как все больше пользователей Hadoop переносят свои кластеры в облако, появляются новые подводные камни.
Идея принципа MapReduce заключалась в том, чтобы совместить в одной системе хранение и вычисление с целью ускорить обработку данных. Раздельная реализация вычислений и мест хранения данных в различных облачных узлах вообще-то противоречит исходной цели. К тому же развертывание собственного Hadoop-кластера никак нельзя назвать легкотнёй, да и поддержка постоянного облачного HDFS-хранилища стоит денег. А как же фрагментация? Файловая система HDFS должна была стандартизировать хранение данных, теперь же миграция в облако навязывает переход к проприетарным сервисам хранения вроде S3.
У облачных Hadoop-реализаций, таких как Amazon EMR и Microsoft HDInsight, есть своя ниша, однако вендоры вроде Hortonworks заключают договоры о сотрудничестве со своими конкурентами-облачными провайдерами с целью размещения у них управляемых версий своих дистрибутивов. Так что уровень абстракции повышается: теперь организациям, чтобы разобраться, как вести свой бизнес, нужно интересоваться не только данными в облаке, но и данными о данных в облаке.
