Google Dataflow против Apache Spark
Я изучаю Google Dataflow и Apache Spark, чтобы решить, какое из них более подходит для наших бизнес-задач по анализу больших данных.
Я нашел там Spark SQL а также MLlib в платформе spark, чтобы сделать структурированный запрос данных и машинное обучение.
Интересно, есть ли соответствующее решение в платформе Google Dataflow?
4 ответа
Было бы полезно, если бы вы немного расширили ваши конкретные варианты использования. Что вы пытаетесь достичь в связи с "анализом Bigdata"? Короткий ответ... это зависит:-)
Вот несколько ключевых архитектурных моментов, которые следует учитывать применительно к Google Cloud Dataflow v. Spark и Hadoop MR.
Ресурс Mgmt: Cloud Dataflow - это среда исполнения по требованию. В частности - когда вы выполняете задание в потоке данных, ресурсы распределяются по требованию только для этого задания. Нет совместного использования ресурсов между рабочими местами. По сравнению с кластером Spark или MapReduce вы обычно развертываете кластер из узлов X, а затем отправляете задания и затем настраиваете ресурсы узла между заданиями. Конечно, вы можете создавать и разбирать эти кластеры, но модель потока данных ориентирована на разработку без помощи рук в отношении управления ресурсами. Если вы хотите оптимизировать использование ресурсов в соответствии с требованиями работы, Поток данных - это надежная модель для контроля затрат и почти забывает о настройке ресурсов. Если вы предпочитаете кластер с несколькими арендаторами, я бы посоветовал вам взглянуть на Google Cloud Dataproc, поскольку он обеспечивает аспекты управления кластером по требованию, такие как Dataflow, но сосредоточен на рабочих нагрузках класса Hadoop, таких как MR, Spark, Pig, ...
Интерактивность: В настоящее время Cloud Dataflow не предоставляет интерактивный режим. Это означает, что после отправки задания рабочие ресурсы привязываются к представленному графику, и большая часть данных загружается в ресурсы по мере необходимости. Spark может быть лучшей моделью, если вы хотите загрузить данные в кластер через RDD в памяти, а затем динамически выполнять запросы. Проблема заключается в том, что по мере увеличения размеров данных и сложности запросов вам придется обрабатывать devOps. Теперь, если большинство ваших запросов могут быть выражены в синтаксисе SQL, вы можете посмотреть на BigQuery. BigQuery обеспечивает аспекты потока данных "по требованию" и позволяет интерактивно выполнять запросы к огромным объемам данных, например петабайтам. Самым большим преимуществом BigQuery, на мой взгляд, является то, что вам не нужно думать / беспокоиться о распределении оборудования, чтобы справиться с размерами ваших данных. Это означает, что по мере увеличения размеров ваших данных вам не нужно думать о конфигурации оборудования (памяти и размера диска).
Модель программирования: модель программирования Dataflow функционально смещена по сравнению с классической моделью MapReduce. Есть много общего между Spark и Dataflow с точки зрения API-примитивов. На что следует обратить внимание: 1) Основной язык программирования Dataflow - Java. В работах есть Python SDK. Java SDK потока данных с открытым исходным кодом и был портирован в Scala. Сегодня Spark имеет более широкий выбор поверхностей SDK с GraphX, Streaming, Spark SQL и ML. 2) Поток данных - это унифицированная модель программирования для групповой и потоковой разработки DAG. Цель состояла в том, чтобы устранить сложность и переключение затрат при переходе между пакетной и потоковой моделями. Один и тот же график может без проблем работать в любом режиме. 3) Сегодня Cloud Dataflow не поддерживает сходящееся / итеративное выполнение графа. Если вам нужна мощь чего-то вроде MLib, тогда Spark - это то, что вам нужно. Имейте в виду, что это состояние дел сегодня.
Потоковая передача и управление окнами. Поток данных (построенный на основе унифицированной модели программирования) был спроектирован как высоконадежная, долговечная и масштабируемая среда выполнения для потоковой передачи. Одно из ключевых отличий между Dataflow и Spark заключается в том, что Dataflow позволяет легко обрабатывать данные с точки зрения их истинного времени события по сравнению с единственной обработкой их во время прибытия в график. Вы можете размещать данные в фиксированных, скользящих, сеансовых или пользовательских окнах, основываясь на времени события или времени прибытия. Dataflow также предоставляет триггеры (применяемые к Windows), которые позволяют вам контролировать, как вы хотите обрабатывать опоздавшие данные.NET-net вы указываете уровень контроля правильности, чтобы удовлетворить потребности вашего анализа. Например, допустим, у вас есть мобильная игра, которая взаимодействует со 100 краевыми узлами. Эти узлы создают события 10000 секунд, связанные с игровым процессом. Допустим, группа узлов не может связаться с вашей системой потокового анализа. В случае потока данных - как только эти данные поступят - вы можете контролировать, как вы хотите обрабатывать данные в соответствии с вашими потребностями в правильности запросов. Поток данных также позволяет обновлять потоковые задания во время их полета. Например, допустим, вы обнаружили логическую ошибку в преобразовании. Вы можете обновить свою работу в полете, не теряя существующего состояния Windowed.NET-net, вы можете поддерживать свой бизнес.
Net-net: - если вы действительно в основном выполняете работу в стиле ETL (фильтрация, формирование, объединение и т. Д.) Или пакетный стиль, то MapReduce Dataflow - отличный путь, если вы хотите минимальные devOps.
- если вам нужно реализовать графики в стиле ML, пройдите путь Spark и попробуйте Dataproc - если вы делаете ML и вам сначала нужно сделать ETL для очистки ваших обучающих данных, внедрите гибрид с Dataflow и Dataproc - если вам нужна интерактивность Spark - хороший выбор, но BigQuery также подходит, если вы / можете выражать свои запросы в SQL
- если вам нужно обрабатывать задания ETL и / или MR по потокам, Dataflow - хороший выбор.
Итак... какие у тебя сценарии?
Я пробовал оба:
Поток данных еще очень молод, нет готового решения для работы с ним с помощью ML (даже если бы вы могли реализовывать алгоритмы в преобразованиях), вы могли бы вывести данные процессов в облачное хранилище и позже прочитать их с другим инструмент.
Рекомендуется Spark, но вам придется управлять своим кластером самостоятельно. Однако есть хорошая альтернатива: Google Dataproc
Вы можете разрабатывать инструменты анализа с помощью spark и развертывать их с помощью одной команды в своем кластере, dataproc будет управлять самим кластером без необходимости настройки конфигурации.
Я построил код, используя spark,DataFlow . Позвольте мне высказать свои мысли.
Spark / DataProc: я много использовал spark (Pyspark) для ETL. Вы можете использовать SQL и любой язык программирования по вашему выбору. Доступно множество функций (включая оконные функции). Создайте свой фрейм данных и напишите свое преобразование, и оно может быть очень быстрым. После того, как данные будут кэшированы, любая операция на Dataframe будет быстрой.
Вы можете просто построить внешнюю таблицу улья в GCS. Затем вы можете использовать Spark для ETL и загрузить данные в большой запрос. Это для пакетной обработки.
Для потоковой передачи вы можете использовать Spark Streaming и загружать данные в большой запрос.
Теперь, если у вас уже есть кластер, подумайте, стоит ли переходить в облако Google или нет. Я обнаружил, что предложение Data proc (Google Cloud Hadoop/Spark) лучше, так как вам не нужно беспокоиться об управлении кластерами.
DataFlow: это известно как Apache Beam. Здесь вы можете написать свой код на Java/Python или любом другом языке. Вы можете выполнить код в любой среде (Spark/MR/Flink). Это унифицированная модель. Здесь вы можете выполнять как пакетную обработку, так и потоковую обработку данных.
Google теперь предлагает обе модели программирования - mapreduce и spark. Облако DataFlow и Cloud DataProc они соответственно