Краткое введение в Databricks, включая варианты развертывания и различные способы интеграции данных в Delta Lake
Введение
До появления Databricks Apache Spark быстро заменил модель программирования MapReduce от Hadoop, став технологией номер один, когда дело касается распределенных вычислений и обработки огромных объемов данных в реальном времени. Он оптимизирован для скорости и эффективности вычислений за счет хранения большей части данных в памяти, а не на диске, по сравнению с подходом MapReduce, который скорее предназначен для длительных пакетных заданий. В настоящее время Databricks - это уже не просто Apache Spark, это полностью управляемая платформа сквозного анализа данных в облаке с функциями совместной работы, аналитики, безопасности и машинного обучения, озера данных и возможностей интеграции данных. Это означает, что помимо обработки данных, он также включает в себя все, что необходимо для интеграции данных. С учетом сказанного, нет никакой существенной необходимости в каких-либо других сервисах или инструментах для приема данных и проектирования надлежащих конвейеров интеграции данных. Хотя в наши дни большинство архитектурных проектов предлагают иное, особенно когда речь идет о приеме локальных данных в облако или данных, поступающих из приложений SaaS и веб-API. Прежде чем мы рассмотрим причины этого и рассмотрим различные способы приема данных и интеграции их в целевую схему, давайте сначала рассмотрим доступные варианты развертывания Databricks и то, почему запуск в Azure имеет свои преимущества.
Развертывание Databricks
На момент написания этой статьи Databricks доступны в Microsoft Azure, Amazon AWS, а совсем недавно и в Google Cloud, который, кстати, является первой средой выполнения Databricks, полностью основанной на контейнерах, среди поставщиков облачных услуг. Однако, хотя он хорошо интегрируется с некоторыми сервисами AWS и Google Cloud, такими как Redshift и BigQuery соответственно, интеграция с Azure намного глубже. Он полностью интегрируется практически со всеми службами, и не только с этим, используя потоки данных фабрики данных Azure (ADFDF), можно даже проектировать масштабируемые конвейеры преобразования данных с помощью перетаскивания поверх кластера Databricks, размещенного в Azure. Вот почему Databricks в Azure на самом деле считается собственной службой и, следовательно, обеспечивает более удобную и оптимизированную работу.
Прием данных Azure Databricks
При работе с Databricks данные обычно хранятся с использованием уровня хранилища с открытым исходным кодом Delta Lake, который располагается поверх фактического хранилища озера данных, такого как Azure Data Lake Storage, AWS S3. , GCS или HDFS. Это переносит транзакции ACID в Apache Spark и сохраняет данные в сильно сжатом и эффективном столбчатом виде с помощью Apache Parquet. Этот формат файла также является основой парадигмы Data Lakehouse компании Databricks, включая ее бронзовую, серебряную и золотую архитектуру с идеей объединения лучших элементов как озер данных, так и хранилищ данных.
Хорошо, но какие теперь возможности для приема данных? Что ж, в основном есть три разных способа получить данные в Databricks:
1. API Apache Spark
Прежде всего, это собственные API-интерфейсы Apache Spark, которые позволяют подключаться как к облачным, так и к локальным источникам данных при условии, что была настроена защищенная виртуальная сеть. После этого использование собственного Spark позволяет напрямую подключать и объединять данные, поступающие из баз данных, систем обмена сообщениями и файлов, независимо от их происхождения. . Что касается локальных источников, это позволит подключать и объединять данные, поступающие из локальных баз данных, тем Kafka и даже локально размещенной сетевой файловой системы (NFS), подключенной к Databricks. Прямая связь между открытыми API-интерфейсами Apache Spark и другими службами Azure требует установки дополнительных библиотек, данные также могут быть получены из баз данных SQL Azure, файловых систем Azure и потоковой передачи событий, поступающих из Центров событий / Интернета вещей Azure. Таким образом, Spark подключается практически ко всему, благодаря большому сообществу, включая сам Databricks.
2. API Databricks
Помимо собственных API-интерфейсов Spark, Databricks разработала дополнительные соединители и способы приема данных в Delta Lakes, что еще больше упростило процесс приема данных. Они специально разработаны, чтобы упростить полное управление состоянием источников данных файлов в том смысле, какие файлы уже были загружены и обработаны. Обычно это достигается путем перемещения загруженных файлов в другую папку или отслеживания состояния в отдельной базе данных. Однако сложность таких конвейеров часто вызывает проблемы, приводящие к неправильным данным или даже к потере данных, если файлы вообще не обрабатывались. Чтобы упростить задачу, Databricks представила пакетную команду КОПИРОВАТЬ В, которая позволяет постепенно загружать новые файлы по расписанию. Они также представили функцию Автозагрузчика, которая выполняет те же действия в виде непрерывного процесса, захватывая файлы по мере их поступления в заданную папку. Это не только снижает сложность конвейеров, но и снижает задержку входящих потоков данных. Оба способа автоматически отслеживают и управляют состояниями за кулисами, что означает, что файлы в исходном местоположении, которые уже были загружены, пропускаются.
3. Партнеры по интеграции данных
Несмотря на бесконечную гибкость приема данных, предлагаемую вышеупомянутыми методами, предприятия часто полагаются на инструменты интеграции данных от поставщиков, с которыми Databricks сотрудничает. Их среды с низким кодом / без кода и простые в реализации среды имеют множество встроенных соединителей с широким спектром различных источников, особенно с предложениями SaaS и веб-API. Они позволяют копировать и синхронизировать данные из сотен источников данных, используя различные возможности автоматической загрузки и автоматического обновления, без написания даже одной строчки кода. Упрощение этого процесса приема данных позволяет преодолеть сложность и затраты на обслуживание, обычно связанные со сбором данных из множества разрозненных источников. На момент написания этой статьи Fivetran, Qlik, Infoworks, StreamSets и Syncsort доступны на Databricks для приема данных, помимо уже давно существующей встроенной интеграции с фабрикой данных Azure. Например, действие копирования фабрики данных Azure поддерживает копирование данных из любого из поддерживаемых источников данных непосредственно в формат Delta Lake. Потоки данных фабрики данных Azure позволяют проектировать, управлять, поддерживать и отслеживать конвейеры Databricks с помощью пользовательского интерфейса браузера с перетаскиванием, как упоминалось выше.
Интеграция данных Azure Databricks
Хотя интеграция данных обычно включает в себя прием данных, она включает в себя некоторые дополнительные процессы, обеспечивающие совместимость принятых данных с репозиторием и существующими данными. На практике вышеупомянутые варианты приема данных часто используются вместе. Например, фабрика данных Azure используется для предоставления данных в целевой зоне и оркестровки процессов, API-интерфейсы Databricks применяют бессильные операции к новым входящим данным и открытому Apache Spark API для потоков Kafka используется для получения потоковых данных, поступающих из Центров событий / Интернета вещей Azure. Также существует специальный соединитель для конечных точек обмена сообщениями Azure, который в данном случае был бы более подходящим. В озере данных можно дополнительно настроить политики архивирования для автоматического перемещения старых файлов в другую папку. В целом этот подход значительно сокращает объем кода и упрощает процесс интеграции данных.
Следующая задача интеграции данных - это сегодняшний неоднородный ландшафт различных источников данных и объединение пакетных и потоковых данных. Благодаря API структурированной потоковой передачи доступный начиная с Spark 2.x, это значительно упрощено. Это позволяет выражать вычисления для потоковых данных так же, как вы выражаете пакетные вычисления для статических данных, достигая максимального повторного использования кода. Среди прочего, могут применяться потоковые агрегаты, временные окна событий или соединения потока с пакетом. Поскольку он дополнительно основан на Spark SQL и Dataset / DataFrame API, данные могут быть легко преобразованы с использованием любого из предоставленных языков (SQL, Python Scala, Java, R). Таким образом, механизм Spark SQL обеспечивает постепенное и непрерывное выполнение процесса и обновляет конечный результат по мере поступления потоковых данных. Все это работает в едином конвейере, который последовательно обрабатывает и хранит данные в соответствии с идеей архитектуры Kappa.
Однако использование такого подхода к интеграции данных, имеющего только одну единую базу кода для пакетных и потоковых данных, также имеет свои собственные проблемы, прежде всего надежный процесс обратного заполнения. Иногда это действительно сложно реализовать, особенно путем воспроизведения большого количества входящих потоковых данных за несколько дней или даже недель. В традиционных архитектурах Lambda эта проблема решается путем запуска конвейера потоковой передачи в реальном времени, в то время как дополнительный конвейер пакетной обработки планируется с отложенным интервалом для повторной обработки всех данных для получения наиболее точных результатов. Подразумеваемым компромиссом здесь является согласование бизнес-логики потоковой и пакетной кодовых баз. Конечно, процесс обратного заполнения также может быть реализован с использованием пакетного режима Spark Structured Streaming, но это, вероятно, приведет к перегрузке последующих систем и процессов, поскольку они просто не предназначены для таких тяжелых рабочих нагрузок. Это означает, что следует по возможности избегать запуска таких ресурсоемких одноразовых процессов обратной заливки, вместо этого следует рассматривать возможность поэтапного чтения из источников.
Вывод
В любом случае, Databricks чрезвычайно упрощает и оптимизирует настройку и обслуживание кластеров Apache Spark, добавляя функции безопасности данных и автоматического управления кластером. С эксплуатационной точки зрения это устраняет сложность и затраты на развертывание и обслуживание кластеров для распределенных вычислений самостоятельно. Сравнивая блоки данных с автономными средами Apache Spark или Hadoop, это обычно позволяет добиться более быстрого окупаемости, а облачные функции, такие как автоматическое масштабирование, помогают сократить использование вычислений и снизить общие затраты. Все это позволяет компаниям быть более эффективными и уделять больше внимания своему бизнесу, в том числе своим данным. Еще одним многообещающим объявлением стала полностью автономная среда выполнения Databricks, размещенная в облаке Google с использованием Kubernetes, и это звучит очень многообещающе, что очень скоро появится полная локальная версия Databricks - давайте посмотрим.
