Google Dataflow против Apache Спарк

Question

Я геодезия Google DataFlow и Apache Спарк, чтобы решить, какой из них является более подходящим решением для наших bigdata анализа потребностей бизнеса.

Я нашел Spark SQL и MLlib в искровой платформе для выполнения структурированных запросов данных и машинного обучения.

Интересно, есть ли соответствующее решение на платформе Google Dataflow?

Answer 1

Это поможет, если вы можете немного расширить свой конкретный вариант использования. Что вы пытаетесь выполнить в отношении «анализа Bigdata»? Короткий ответ ... это зависит :-)

Вот несколько ключевых архитектурных моментов, которые следует учитывать в отношении Google Cloud Dataflow v. Spark и Hadoop MR.

• Resource Mgmt: Cloud Dataflow - это среда исполнения по требованию. В частности - когда вы выполняете задание в Dataflow, ресурсы выделяются по запросу только для этого задания. Не существует совместного использования/разглашения ресурсов между рабочими местами. По сравнению с кластером Spark или MapReduce вы, как правило, развертываете кластер из X узлов, а затем отправляете задания и затем настраиваете ресурсы узлов в разных заданиях. Конечно, вы можете наращивать и срывать эти кластеры, но модель Dataflow ориентирована на бесплатное использование op op в отношении управления ресурсами. Если вы хотите оптимизировать использование ресурсов для требований к работе, Dataflow является надежной моделью для управления затратами и почти забыть о настройке ресурсов. Если вы предпочитаете кластер с несколькими арендаторами, я бы посоветовал вам взглянуть на Google Cloud Dataproc, поскольку он обеспечивает такие аспекты управления кластерами, как Dataflow, но и сосредоточен на рабочих нагрузках класса Hadoop, таких как MR, Spark, Pig, ...

• Взаимодействие: В настоящее время Cloud Dataflow не обеспечивает интерактивный режим. Когда вы отправляете задание, рабочие ресурсы привязаны к графику, который был отправлен, и большая часть данных загружается в ресурсы по мере необходимости. Spark может быть лучшей моделью, если вы хотите загружать данные в кластер через память RDD, а затем динамически выполнять запросы. Проблема в том, что по мере увеличения размеров ваших данных и сложности запросов вам придется обрабатывать devOps. Теперь, если большинство ваших запросов можно выразить в синтаксисе SQL, вы можете посмотреть на BigQuery. BigQuery предоставляет «по требованию» аспекты Dataflow и позволяет вам интерактивно выполнять запросы на огромные объемы данных, например, петабайт. Самое большое преимущество, по моему мнению, в BigQuery, заключается в том, что у вас нет мысли/беспокойства о распределении оборудования для обработки ваших размеров данных. Если ваши размеры данных растут, вам не нужно думать о конфигурации аппаратного обеспечения (конфигурации памяти и размера диска).

• Модель программирования: модель программирования Dataflow функционально предвзята по сравнению с классической моделью MapReduce.Существует много сходств между Spark и Dataflow с точки зрения API-примитивов. Что следует учитывать: 1) основным языком программирования Dataflow является Java. В работе есть SDK Python. SDK Dataflow Java SDK в открытом доступе и был перенесен на Scala. Сегодня Spark имеет больше возможностей выбора SDK с помощью GraphX, Streaming, Spark SQL и ML. 2) Dataflow - это унифицированная модель программирования для пакетной и потоковой разработки DAG. Цель заключалась в том, чтобы удалить сложность и стоимость переключения при перемещении между пакетными и потоковыми моделями. Тот же график может легко запускаться в любом режиме. 3) Сегодня Cloud Dataflow не поддерживает выполнение графиков с конверсией/итерацией. Если вам нужна сила чего-то типа MLib, то Spark - это путь. Имейте в виду, что сегодня это состояние.

• Потоковая передача & Окно: поток данных (построенный на основе единой модели программирования) был задуман как высоконадежная, долговечная и масштабируемая среда исполнения для потоковой передачи. Одним из ключевых различий между Dataflow и Spark является то, что Dataflow позволяет вам легко обрабатывать данные с точки зрения его истинного времени события, а не только обрабатывать его в момент его поступления в график. Вы можете открывать данные в фиксированные, скользящие, сеансовые или пользовательские окна на основе времени события или времени прибытия. Dataflow также предоставляет триггеры (применяется к Windows), которые позволяют вам контролировать, как вы хотите обрабатывать данные, поступающие с поздним прибытием. Net-net вы набираете уровень контроля правильности для удовлетворения потребностей вашего анализа. Например, скажем, у вас есть мобильная игра, которая взаимодействует с 100 краевыми узлами. Эти узлы создают события 10000, связанные с игрой. Предположим, что группа узлов не может взаимодействовать с вашей системой анализа потокового потока. В случае Dataflow - как только эти данные поступят - вы можете контролировать, как вы хотите обрабатывать данные в зависимости от ваших потребностей в правильности запроса. Dataflow также предоставляет возможность обновлять ваши потоковые задания во время полета. Например, предположим, вы обнаружите логическую ошибку в преобразовании. Вы можете обновить свою работу в полете, не потеряв существующее состояние Windowed. Net-net вы можете поддерживать работу.

Net-нетто: - если вы действительно в основном делаете работу ETL стиля (фильтрацию, обработку, присоединение, ...) или пакетный стиле MapReduce Dataflow является большим путем, если вы хотите минимальную DevOps.
- если вам нужно реализовать графики стиля ML, пойдите по пути Spark и дайте Dataproc попытку - если вы делаете ML, и вам сначала нужно сделать ETL, чтобы очистить ваши данные для обучения, реализовать гибрид с Dataflow и Dataproc - если вам требуется интерактивность, Spark - это солидный выбор, но так же BigQuery, если вы/можете выражать свои запросы в SQL - если вам нужно обработать ваши ETL и/или MR задания по потокам, Dataflow - это солидный выбор.

---

Итак, какие у вас сценарии?

Answer 2

Я попытался как:

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

Спарк рекомендуется, но вам придется самому управлять своим кластером. Однако есть хорошая альтернатива: Google Dataproc

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

Answer 3

google теперь предлагает обе модели программирования - mapreduce и spark. Облако DataFlow и Cloud DataProc соответственно

Answer 4

У меня есть код с использованием искры, DataFlow. Позвольте мне рассказать.

Spark/DataProc: Я использовал искру (Pyspark) много для ETL. Вы можете использовать SQL и любой язык программирования по вашему выбору. Доступно множество функций (включая функции окна). Создайте свой файл данных и напишите свое преобразование, и оно может быть очень быстрым. После кэширования данных любая операция в Dataframe будет быстрой.

Вы можете просто построить внешнюю таблицу улья на GCS. Затем вы можете использовать Spark для ETL и загрузить данные в Big Query. Это для пакетной обработки.

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

Теперь, если у вас есть кластер allready, тогда вы подумаете, переместиться ли в облако Google или нет. Я нашел предложение Data proc (Google Cloud Hadoop/Spark) лучше, так как вам не нужно беспокоиться о многих управлениях кластеров.

DataFlow: он известен как луч Apache. Здесь вы можете написать свой код на Java/Python или на любом другом языке. Вы можете выполнить код в любой структуре (Spark/MR/Flink). Это унифицированная модель. Здесь вы можете выполнять пакетную обработку и обработку данных Stream.