Перенос хранилища данных в Databricks lakehouse
В этой статье описываются некоторые рекомендации и предостережения, которые следует учитывать при замене корпоративного хранилища данных на Databricks lakehouse. Большинство рабочих нагрузок, запросов и панелей мониторинга, определенных в корпоративных хранилищах данных, могут выполняться с минимальным рефакторингом кода после завершения начальной конфигурации миграции и управления данными. Перенос рабочих нагрузок хранения данных в Azure Databricks — это не устранение хранения данных, а объединение экосистемы данных. Дополнительные сведения о хранилище данных в Databricks см. в статье "Что такое хранение данных в Azure Databricks?".
Многие рабочие нагрузки Apache Spark извлекают, преобразуют и загружают данные из исходных систем в хранилища данных, чтобы обеспечить нисходящей аналитики. Замена корпоративного хранилища данных на lakehouse позволяет аналитикам, специалистам по обработке и анализу данных работать с теми же таблицами на той же платформе, уменьшая общую сложность, требования к обслуживанию и общую стоимость владения. См. раздел "Что такое озера данных?". Дополнительные сведения о хранилище данных в Databricks см. в статье "Что такое хранение данных в Azure Databricks?".
Загрузка данных в lakehouse
Azure Databricks предоставляет ряд средств и возможностей для упрощения переноса данных в lakehouse и настройки заданий ETL для загрузки данных из различных источников данных. В следующих статьях представлены следующие средства и параметры:
- Перенос озера данных Parquet в Delta Lake
- Что такое Федерация Lakehouse
- Что такое Подключение партнера Databricks?
- Прием данных в databricks lakehouse
- Что такое разностные динамические таблицы?
Как платформа аналитики данных Databricks отличается от корпоративного хранилища данных?
Платформа аналитики данных Databricks построена на основе Apache Spark, каталога Unity и Delta Lake, обеспечивая встроенную поддержку рабочих нагрузок больших данных для аналитики, машинного обучения и проектирования данных. Все корпоративные системы данных имеют немного разные гарантии транзакций, индексирование и оптимизацию, а также синтаксис SQL. Некоторые из самых больших различий, которые вы можете обнаружить, включают следующие:
- Все транзакции — это табличный уровень. Нет транзакций на уровне базы данных, блокировок или гарантий.
BEGIN
Нет иEND
конструкции, что означает, что каждая инструкция или запрос выполняется как отдельная транзакция.- В трех уровнях имен используется
catalog.schema.table
шаблон. Терминыdatabase
иschema
синонимы из-за устаревшего синтаксиса Apache Spark. - Ограничения первичного ключа и внешнего ключа являются информационными. Ограничения могут применяться только на уровне таблицы. См . ограничения в Azure Databricks.
- Собственные типы данных, поддерживаемые в Azure Databricks и Delta Lake, могут немного отличаться от исходных систем. Перед выбором целевых типов необходимо четко указать необходимую точность для числовых типов.
В следующих статьях содержатся дополнительные сведения о важных соображениях.