Мертв ли Hadoop? Часть 2

Читать первую часть

Никому не нужна Big Data

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

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

За последние 25 лет веб-разработка была большой движущей силой в росте числа программистов. Большинство людей, которые называют себя программистом, чаще всего создают веб-приложения. Я думаю, что многие наборы навыков, которыми они обладают, хорошо совпадают с теми, которые необходимы для проектирования данных, но в них часто отсутствуют распределенные вычисления, статистика и сторителлинг.

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

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

Этот набор данных может жить в оперативной памяти

Я слышал, как люди утверждали, что «набор данных может уместиться в памяти». Объем оперативной памяти, даже в облаке, за последнее время сильно вырос. Есть экземпляры EC2 с 2 ТБ ОЗУ. Обычно ОЗУ можно использовать со скоростью 12-25 ГБ/с, в зависимости от архитектуры вашей установки. Использование ОЗУ само по себе не обеспечит восстановление после сбоя, если на машине произойдет сбой питания. К тому же, стоимость за ГБ будет огромной по сравнению с использованием дисков.

Диски тоже становятся быстрее. Недавно была анонсирована SSD-карта PCIe 4.0 NVMe 4 x 2 ТБ, способная считывать и записывать со скоростью 15 ГБ/с. Цена диска PCIe 4.0 NVMe будет вполне конкурентоспособной с ОЗУ и обеспечит энергонезависимую память. Я не могу дождаться, чтобы увидеть кластер HDFS с хорошей сетью, использующей эти накопители, поскольку он продемонстрирует, как выглядит архив данных в памяти с энергонезависимым хранилищем с богатым существующим инструментарием экосистемы Hadoop.

Перегружен инженерными излишествами

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

С точки зрения рабочего процесса, мои дни в основном состоят из использования BASH, Python и SQL. Множество новых выпускников квалифицированы в вышеуказанном.

Петабайт данных Parquet может быть легко распределен по миллиону файлов на S3. Планирование, связанное с вышеупомянутым, не намного сложнее, чем рассмотрение того, как хранить 100 000 микропакетных файлов на S3. То, что решение масштабируется, не означает, что оно излишне.

Просто использовать PostgreSQL?

Я также слышал аргументы, что ориентированные на строки системы, такие как MySQL и PostgreSQL, могут соответствовать потребностям аналитических рабочих нагрузок, а также их традиционным транзакционным рабочим нагрузкам. Оба эти предложения могут выполнять аналитику, и если вы просматриваете менее 20 ГБ данных, то, вероятно, масштабирование не стоит затраченных усилий.

Мне приходилось работать с системой, которая ежедневно загружала в MySQL 10 миллиардов строк. В MySQL и PostgreSQL нет ничего, что могло бы справиться с такой нагрузкой. Расходы на инфраструктуру для хранения наборов данных, даже в течение нескольких дней, в ориентированном на строки хранилище затмили расходы на персонал. Переход на решение для колоночного хранения для этого клиента снизил затраты на инфраструктуру и ускорил время запросов на два порядка для каждого.

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

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

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

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

Как выглядит будущее?

Я буду продолжать анализировать и расширять свои навыки в области данных в обозримом будущем. За последние 12 месяцев я выполнял работу с использованием Redshift, BigQuery и Presto почти в равных количествах. Я стараюсь распределять свои ставки, так как еще не нашел рабочий хрустальный шар предсказателя.

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

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

Возможно, сейчас Cloudera и MapR переживают трудные времена, но я ничего такого не слышал, чтобы заставило меня поверить, что в AWS EMR, DataBricks и Qubole есть что-то, что могло бы составить конкуренцию. Даже Oracle выпускает Spark-управляемое предложение. Было бы хорошо, если бы индустрия увидела в Hadoop нечто большее, чем просто предложение Cloudera, и признала, что указанные фирмы, а также Facebook, Uber и Twitter внесли существенный вклад в мир Hadoop.

Hortonworks, которая в этом году объединилась с Cloudera, является поставщиками платформ для Azure HDInsight, управляемого Microsoft Hadoop. В компании есть люди, которые могут предоставить достойную платформу стороннему поставщику облачных услуг. Я надеюсь, что любые предложения, над которыми они работают, будут сосредоточены на такого рода поставках.

Я подозреваю, что ранние клиенты Cloudera были пользователями HBase, Oozie, Sqoop и Impala. Было бы хорошо видеть, что они не конкурируют за такое большое время разработки и за будущие версии их платформ, которые будут поставляться с Airflow, Presto и последней версией Spark из коробки.

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