Я рассматриваю Google Dataflow и Apache Spark, чтобы решить, какой из них является более подходящим решением для наших бизнес-задач, связанных с анализом bigdata.
Я обнаружил, что в искровой платформе есть Spark SQL и MLlib для выполнения структурированного запроса данных и машинного обучения.
Интересно, есть ли соответствующее решение на платформе Google Dataflow?
Было бы полезно, если бы вы немного расширили ваши конкретные варианты использования. Что вы пытаетесь достичь в связи с "анализом 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, на мой взгляд, является то, что вам не нужно думать/беспокоиться о распределении аппаратных средств, чтобы справиться с размерами ваших данных. Это означает, что по мере роста размеров ваших данных вам не нужно думать о конфигурации оборудования (памяти и размера диска).
Модель программирования: модель программирования потока данных функционально смещена по сравнению с классической моделью MapReduce. Есть много общего между Spark и Dataflow с точки зрения API-примитивов. На что следует обратить внимание: 1) Основным языком программирования потока данных является Java. В работе находится Python SDK. Пакет данных SDK Java с открытым исходным кодом был перенесен в Scala. Сегодня Spark имеет более широкий выбор поверхностей SDK с GraphX, Streaming, Spark SQL и ML. 2) Поток данных - это унифицированная модель программирования для групповой и потоковой разработки DAG. Цель состояла в том, чтобы устранить сложность и переключение затрат при переходе между пакетными и потоковыми моделями. Один и тот же график может без проблем работать в любом режиме. 3) Сегодня Cloud Dataflow не поддерживает сходящееся/итеративное выполнение графа. Если вам нужна мощь чего-то вроде MLib, тогда Spark - это то, что вам нужно. Имейте в виду, что это состояние дел сегодня.
Потоковое & Оконное управление: поток данных (построенный на основе унифицированной модели программирования) был спроектирован как высоконадежная, долговечная и масштабируемая среда исполнения для потоковой передачи. Одно из ключевых отличий между Dataflow и Spark заключается в том, что Dataflow позволяет легко обрабатывать данные с точки зрения их истинного времени события, а не только обрабатывать их во время прибытия в график. Вы можете размещать данные в фиксированных, скользящих, сеансовых или пользовательских окнах в зависимости от времени события или времени прибытия. В потоке данных также предусмотрены триггеры (примененные к Windows), которые позволяют вам контролировать обработку данных, поступающих с опозданием. Net-net вы указываете уровень контроля правильности, чтобы удовлетворить потребности вашего анализа. Например, допустим, у вас есть мобильная игра, которая взаимодействует со 100 краевыми узлами. Эти узлы создают 10000 вторых событий, связанных с игровым процессом. Допустим, группа узлов не может связаться с вашей системой потокового анализа. В случае потока данных - как только эти данные поступят - вы можете контролировать, как вы хотите обрабатывать данные в соответствии с вашими потребностями в правильности запросов. Поток данных также позволяет обновлять потоковые задания во время их полета. Например, допустим, вы обнаружили логическую ошибку в преобразовании. Вы можете обновить свою работу в полете, не теряя существующего состояния Windowed. Net-net, вы можете поддерживать свою деятельность.
Net-нетто:
- если вы действительно в основном выполняете работу в стиле ETL (фильтрация, формирование, объединение и т.д.) или пакетный стиль, то MapReduce Dataflow - отличный путь, если вы хотите минимальные devOps.
- если вам нужно реализовать графики в стиле ML, пройдите путь Spark и попробуйте Dataproc
- если вы делаете ML, и вам сначала нужно сделать ETL, чтобы очистить данные тренировок, внедрите гибрид с Dataflow и Dataproc
- если вам нужна интерактивность, Spark - хороший выбор, как и BigQuery, если вы/можете выражать свои запросы в SQL
- если вам нужно обрабатывать задания ETL и/или MR по потокам, Dataflow - хороший выбор.
Итак... какие у тебя сценарии?
Я пробовал оба:
Dataflow все еще очень молод, это не "готовое" решение для выполнения ML с ним (даже если вы можете реализовать алгоритмы в преобразованиях), вы можете выводить данные процессов в облачное хранилище и читать их позже с другим инструментом.
Спарк рекомендуется, но вам придется самому управлять своим кластером. Однако есть хорошая альтернатива: Google Dataproc
Вы можете разрабатывать инструменты анализа с помощью искры и разворачивать их с помощью одной команды в своем кластере, dataproc будет управлять самим кластером без необходимости настройки конфигурации.
Я создал код с использованием искры, 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.
Google теперь предлагает обе модели программирования - mapreduce и spark. Cloud DataFlow и Cloud DataProc они соответственно