В последнее время я много слышал о “смерти Big Data”, и я должен сказать, что никогда не был поклонником самого термина “Big Data”. Он всегда сосредотачивал внимание людей исключительно на объемы данных, игнорируя другие важные аспекты Big Data, такие как разнообразие и скорость. К сожалению, озера данных также оказались втянутыми в контроверзу, связанную с этой темой.

В этой серии постов я хочу развеять все сомнения, которые у вас могут быть относительно ценности озер данных и архитектуры “Big Data”. Я сделаю это, исследуя, как мы можем реализовать архитектуру озера данных с использованием Delta Lake, Azure Databricks и Azure Data Lake Store (ADLS) Gen2.

Прежде чем мы углубимся в детали, давайте рассмотрим так называемую “смерть Big Data”. Хотя правда, что не все организации имеют дело с большими объемами данных, я могу уверенно сказать, что большинство организаций сталкиваются с другими двумя “V” Big Data: разнообразием и скоростью.

Когда мы говорим о разнообразии, мы имеем в виду данные в различных структурах. Это может включать структурированные данные, такие как традиционные реляционные базы данных, а также полуструктурированные данные, такие как файлы JSON или XML, созданные машинами. Даже неструктурированные данные, такие как PDF-документы или электронные письма, относятся к этой категории. Таким образом, ясно, что у большинства организаций есть разнообразие данных.

Скорость, с другой стороны, относится к скорости, с которой необходимо получать и обрабатывать данные. Многие организации имеют требования к обработке данных в режиме реального времени или практически в режиме реального времени. Это означает, что данные должны обрабатываться с более высокой скоростью. Таким образом, ясно, что Big Data далеко не мертва.

Теперь давайте поговорим об озерах данных. До выпуска Delta Lake озера данных столкнулись с несколькими проблемами. Неудачные производственные задания могли оставить данные в поврежденном состоянии, отсутствие контроля качества могло привести к несогласованным и непригодным для использования данным, а отсутствие транзакций затрудняло смешивание добавлений и чтения данных. Эти проблемы часто превращали озера данных в болота данных, делая их бесполезными.

Кроме того, некоторые люди ошибочно использовали технологии, такие как Hadoop, как синонимы Big Data. Были сделаны заявления о том, что Hadoop и другие технологии Big Data заменят традиционное хранилище данных, вызывая много споров. Также существует точка зрения, согласно которой озера данных – это не более чем глорифицированные постоянные стадии. Хотя это может быть правдой в некоторых случаях, озера данных имеют гораздо больший потенциал.

Позвольте мне быть ясным, Big Data никогда не была задумана как замена хранилища данных, а скорее как его дополнение. Два этих концепта могут и должны сосуществовать гармонично. К счастью, технологии никогда не прекращают развиваться, и озера данных получили значительный толчок, объединив три фантастические технологии: Delta Lake, Databricks и ADLS Gen2.

Delta Lake предоставляет несколько ключевых функций, которые улучшают озера данных, включая ACID-транзакции, возможность версионирования данных, объединение потоковой и пакетной обработки, контроль и эволюция схемы данных и контроль доступа на основе ролей. Эти функции позволяют создавать надежные озера данных в масштабе.

В следующем посте мы более подробно рассмотрим создание качественных озер данных с использованием Delta Lake, Databricks и ADLS Gen2. Мы рассмотрим такие темы, как один или несколько учетных записей хранения, одна или несколько файловых систем, зоны озера данных, их структуры и способы обеспечения безопасности.