Этот сайт использует файлы cookies. Оставаясь на сайте, Вы соглашаетесь с использованием файлов cookies и принимаете Соглашение об использовании сайта.

тенденции big data

Тенденции больших данных

340
340

Вы думаете, что научились работать с big data аналитикой? Не стоит быть таким самоуверенным. Чтобы по-настоящему повысить эффективность, вам лучше следить за развитием технологий и вовремя обновлять набор инструментов. Статья подготовлена на основе перевода ресурса InfoWorld.


7 big data инструментов, от которых стоит избавиться в 2017

Но не все так солнечно и ново. К примеру, некоторые технологии могут замедлять вашу работу. Запомните, big data настолько быстро развивающаяся сфера производственных технологий, что некоторое программное обеспечение действует как временное решение до тех пор, пока не появятся лучшие альтернативы.

Те обновления (или замены) могут быть решающими в успехе всего big data-решения. В противном случае, вы будете пытаться подружиться с ними последующие несколько лет.

Ниже приведены 7 элементов набора инструментов, о замене которых вам следовало бы начать думать:

1. MapReduce

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

2. Storm

Я не говорю о том, что Spark захватит мир потоковой передачи данных (хотя и такое возможно!), но такие технологии, как Apex и Flink, лучшая, с наименьшей задержкой времени альтернатива Spark, нежели Storm.

Storm не получает той поддержки, которой заслуживает с Hortonworks в качестве единственного реального бекера. А с Hortonworks, столкнувшимся с возрастающим рыночным давлением, Storm навряд ли получит достаточного внимания.

3. Pig

Вы можете делать все, что он может, при помощи Spark или других инструментов. Сперва Pig кажется хорошим «PL/SQL для big data», но вскоре вы выясните, что это довольно-таки странный инструмент.

4. Java

Нет, речь идет не о виртуальной машине JAVA, а о языке. Синтаксис оказывается довольно корявым для задач в big data. Кроме того, новые конструкции, такие как Lambda, были прикручены несколько неудобным способом. Мир big data в основном переехал в Scala и Python (последний, если вы можете позволить себе снизить производительность и нуждаетесь в библиотеке Python, или вы подхватили Python-зависимость). Конечно, вы можете использовать R для статистики, пока вы не решите переписать все на Python, потому что в R не хватает необходимых возможностей.

5. Tez

Это еще одно любимое детище Hortonworks. Это реализация DAG, но в отличие от Spark, Tez описывается одним из его разработчиков: «Это как-будто писать на «языке Ассемблера». На данный момент, с распространением Hortonworks, вы в конечном итоге начнете использовать Tez после Hive и других инструментов, но уже сейчас вы можете работать с движком Spark в других сборках.

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

6. Oozie

Это не диспетчер потоков работ и не планировщик, но все же он является и тем, и другим, и в то же время ничем. Используя StreamSets, DAG реализациями и остальными вы, скорее всего, уже можете сделать большую часть того, что может Oozie.

7. Flume

Среди StreamSets, Kafka и других решений у вас есть альтернатива — Flume. 20 мая 2015 года его релиз казался немного устаревшим, но следить за его обновлением вы можете на mail-archives.apache.org.

Откинув чувства и разум, двигаемся дальше.

Возможно к 2018...

Что осталось? Некоторые технологии устаревают, но до сих пор не появились готовые жизнеспособные альтернативы. Подумайте заранее о возможности замены этих инструментов:

1. Hive.

Может показаться чрезмерно язвительным, но Hive наименее производительная РБД на планете. Если бы мы наравне с промышленностью не посчитали бы РСУБД наиболее великой вещью с момента изобретения нарезного хлеба за последние 40 лет, то создали бы этого монстра?

2. HDFS.

Написание сервиса на системном уровне в JAVA не самая великая идея. Как минимум потому, что управление памятью в Java замедляет процесс передачи данных такого большого объема байтов. Способ того, как работает HDFS NameNode, не считается идеалом для всего и является уязвимым местом. Различные поставщики имеют обходные пути, чтобы сделать его лучше, но если честно, нам доступны более хорошие инструменты. Существуют и другие файловые системы. Например, довольно хорошо спроектированная MaprFS. Также есть Gluster и уйма других.

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

Оригинал статьи InfoWorld, Andrew C. Oliver. Над переводом текста работала Е. Осипенко, специалист по маркетингу INOSTUDIO.