Поделиться через


Перенос хранилища данных в Databricks lakehouse

В этой статье описываются некоторые рекомендации и предостережения, которые следует учитывать при замене корпоративного хранилища данных на Databricks lakehouse. Большинство рабочих нагрузок, запросов и панелей мониторинга, определенных в корпоративных хранилищах данных, могут выполняться с минимальным рефакторингом кода после завершения начальной конфигурации миграции и управления данными. Перенос рабочих нагрузок хранения данных в Azure Databricks — это не устранение хранения данных, а объединение экосистемы данных. Дополнительные сведения о хранилище данных в Databricks см. в статье "Что такое хранение данных в Azure Databricks?".

Многие рабочие нагрузки Apache Spark извлекают, преобразуют и загружают данные из исходных систем в хранилища данных, чтобы обеспечить нисходящей аналитики. Замена корпоративного хранилища данных на lakehouse позволяет аналитикам, специалистам по обработке и анализу данных работать с теми же таблицами на той же платформе, уменьшая общую сложность, требования к обслуживанию и общую стоимость владения. См. раздел "Что такое озера данных?". Дополнительные сведения о хранилище данных в Databricks см. в статье "Что такое хранение данных в Azure Databricks?".

Загрузка данных в lakehouse

Azure Databricks предоставляет ряд средств и возможностей для упрощения переноса данных в lakehouse и настройки заданий ETL для загрузки данных из различных источников данных. В следующих статьях представлены следующие средства и параметры:

Как платформа аналитики данных Databricks отличается от корпоративного хранилища данных?

Платформа аналитики данных Databricks построена на основе Apache Spark, каталога Unity и Delta Lake, обеспечивая встроенную поддержку рабочих нагрузок больших данных для аналитики, машинного обучения и проектирования данных. Все корпоративные системы данных имеют немного разные гарантии транзакций, индексирование и оптимизацию, а также синтаксис SQL. Некоторые из самых больших различий, которые вы можете обнаружить, включают следующие:

  • Все транзакции — это табличный уровень. Нет транзакций на уровне базы данных, блокировок или гарантий.
  • BEGIN Нет и END конструкции, что означает, что каждая инструкция или запрос выполняется как отдельная транзакция.
  • В трех уровнях имен используется catalog.schema.table шаблон. Термины database и schema синонимы из-за устаревшего синтаксиса Apache Spark.
  • Ограничения первичного ключа и внешнего ключа являются информационными. Ограничения могут применяться только на уровне таблицы. См . ограничения в Azure Databricks.
  • Собственные типы данных, поддерживаемые в Azure Databricks и Delta Lake, могут немного отличаться от исходных систем. Перед выбором целевых типов необходимо четко указать необходимую точность для числовых типов.

В следующих статьях содержатся дополнительные сведения о важных соображениях.