Продаем «Дом озера данных»
Введение
Появившееся недавно повальное увлечение пользователей озерами данных кажется мне большим шумом из ничего. Идея заключается в том, чтобы у пользователя была единая платформа для поддержки всех данных и всех рабочих процессов (хранилище данных, бизнес-аналитика, AI/ML, потоковая передача). Ну что ж, Snowflake уже долгое время может поддерживать эти сценарии и даже вышла за их пределы. Я считаю, что по большей части (или даже всегда) ажиотаж создают конкуренты, которые пытаются догнать Snowflake.
Хотя я не являюсь сторонником сохранения термина «озеро данных», будет все же интересно узнать, что он из себя представляет и откуда взялся. В ходе своего исследования я узнал, что этот термин впервые употребил, как полагают, Jellyvision Lab клиент компании Snowflake, еще в июле 2017 года! Вы понимаете, что впервые его использовали в отношении Snowflake. Более того, его впервые использовали в отношении Snowflake примерно за два года, прежде чем другие подхватили этот термин и начали его активно использовать!
В этом посте я кратко расскажу вам об основных особенностях озера данных, покажу, что у Snowflake эти функции есть уже довольно давно, расскажу, как появился термин (спойлер: словосочетание впервые использовалась для описания возможностей Snowflake) и обсудим, что будет дальше.
Так что же такое «озеро данных»?
Хотя в последнее время кажется, что все стараются употреблять модный термин «дом озера данных», первый толчок, похоже, дал Databricks. В начале прошлого года (в конце января 2020 года) Databricks опубликовала пост в блоге "Что такое дом озера данных?" В нём они пытались доказать, что Databricks – лучшая платформа, которая отвечает требованиям хранилища данных. Но правда ли это? И почему они вообще не упомянули Snowflake в своей статье? Чтобы ответить на эти вопросы, сначала нужно понять, что должно представлять озеро данных.
Вот мое краткое изложение/определение «дома озера данных»:
Дом озера данных – это архитектурный подход для управления всеми вашими данными (структурированными, полуструктурированными или неструктурированными) и поддержки всех ваших рабочих нагрузок с данными (хранилище данных, бизнес-аналитика, AI/ML и потоковая передача).
Но погодите, разве у Snowflake раньше не было этих функций? Ответ: да, были. Давайте вкратце рассмотрим каждое из этих требований и поймем, почему Snowflake является оригинальным домом озера данных.
Управление всеми вашими данными
Причиной создания этих озер данных было устранение недостатков традиционных хранилищ данных. Но озера данных на основе файлов привели к еще одному разрозненному хранилищу, и к тому же, ими трудно управлять. Именно эту проблему пытались решить основатели Snowflake: объединить хранилище данных и озеро данных в единую платформу. Именно это они и сделали. С самого начала в Snowflake была встроенная поддержка как структурированных, так и полуструктурированных данных, и это устраняло необходимость в озере данных на основе файлов.
А как насчет неструктурированных данных, таких как изображения, отсканированные документы и т. д.? Многие реляционные базы данных предлагают возможность хранить неструктурированные данные в течение некоторого времени (в виде двоичных или больших двоичных данных), но в большинстве случаев это нерентабельно или даже невозможно хранить все в таком виде. Также довольно непрактично обрабатывать эти данные из реляционной базы данных. Поэтому, традиционный ответ таков: оставить неструктурированные данные в файловой системе и обрабатывать их оттуда с помощью систем и служб вне базы данных.
У Snowflake уже есть невероятная поддержка для работы с неструктурированными данными, и во время саммита Data Cloud в ноябре 2020 года Snowflake объявила о новых функциях, которые сделают эту интеграцию еще эффективнее (подробности см. в Сессии «Что будет дальше с облаком данных» с Кристианом Кляйнерманом, начиная с 36:02 и резюме Data Cloud Summit). Но сегодня с помощью встроенной интеграции облачного хранилища и функции внешних функций вы можете обрабатывать любой неструктурированный файл с помощью любого процесса или службы, и использовать или сохранять результаты в Snowflake.
Управление всеми вашими рабочими нагрузками
С самого начала целью Snowflake было создание единой платформы, которая могла бы поддерживать все рабочие нагрузки в компании. Вот три основные рабочие нагрузки по данным в организации, выделенные хранилищем: DW/BI (хранилище данных), AI/ML и Потоковая передача. Хотя о каждой из них можно рассказать довольно много, вот краткий обзор того, как Snowflake поддерживает каждую из них.
Хранилище данных (DW) и связанные с ним рабочие нагрузки бизнес-аналитики (BI) были и остаются основой аналитики. С самого начала Snowflake поддерживал все ключевые функции DW, включая управление с помощью детального контроля доступа на основе ролей (RBAC), надежную реализацию ANSI SQL, которая поддерживает все типы операций (DQL, DML, DDL), транзакции с несколькими операторами, Соответствие ACID, богатые возможности программирования и многое, многое другое. Но в отличие от всех других DW, Snowflake сделала это уникальным образом, создав с нуля новую платформу для общедоступного облака. Это означает, что Snowflake реально может воспользоваться масштабом, предлагаемым общедоступным облаком. Дополнительные сведения о возможностях DW/BI в Snowflake см. странице Snowflake – хранилище для ваших данных.
Вторая ключевая рабочая нагрузка, которую следует учитывать – это AI/ML. Snowflake уже некоторое время поддерживает такую функцию. Исследования показывают, что специалисты по обработке данных тратят около 80% своего времени на поиск и подготовку данных. Snowflake может устранить необходимость в большей части этих бесполезных усилий, консолидируя все ваши данные (в их собственном формате) и предоставляя специалистам по данным практически неограниченную производительность и масштабирование, а также возможность проектировать функции и преобразовывать их с использованием SQL, Java или Scala. Все основные инструменты, библиотеки и языки сценариев AI/ML очень хорошо работают со Snowflake благодаря различным драйверам. Сюда входят коннекторы JDBC/ODBC, Python, R и Spark. Более того, Snowflake имеет богатую партнерскую экосистему в области AI/ML. Сюда входят DataRobot, Dataiku, H20.ai, Amazon Sagemaker, Azure ML и многие другие. А если и этого будет недостаточно, Snowflake анонсировала новые функции, такие как функции Java/Scala и Python, которые позволят рабочим нагрузкам AI/ML запускаться непосредственно внутри Snowflake. Дополнительные сведения о возможностях AI/ML Snowflake см. На странице Snowflake для науки о данных.
Третья важная рабочая нагрузка, которую следует учитывать – это потоковая передача. И, вероятно, самый важный вопрос, который следует задавать всякий раз, когда кто-то упоминает о потоковой передаче данных, будет таким: «какую конкретно задержку вы имеете в виду?» В потоковой передаче может быть что угодно – от миллисекундной задержки до нескольких минут и даже тридцати с лишним минут. Я обнаружил, что для большинства клиентов приемлемая задержка потоковой передачи находится в пределах 5–10 минут. И Snowflake уже долгое время может поддерживать эту задержку с помощью своих Continuous Data Pipelines (включая Snowpipe, Snowflake Connector для Kafka, Tasks и Streams) или других инструментов партнерской репликации (таких как HVR, Replicate, Fivetran, и другие.). Фактически, сегодня задержки Snowflake составляют половину этого диапазона. Безусловно, сейчас есть организации, которые предъявляют требования к потоковой передаче с задержками от нескольких секунд до миллисекунд, но часто эти решения создаются с использованием специальных инструментов и решений для потоковой передачи.
Snowflake всегда была в центре внимания.
13 июля 2017 года Джереми Энгл, в то время руководитель группы разработки данных в Jellyvision, представил группе пользователей AWS «Стратегии поддержки аналитики в реальном времени, OLAP и интерактивного исследования данных» (его слайды можно найти здесь). Он обсудил их потребности в приеме полуструктурированных данных в режиме почти реального времени, а также проблемы, с которыми они столкнулись при работе и извлечении выгоды из своего озера данных. Он искал что-то, что давало бы преимущества как традиционного хранилища данных, так и озера данных:
И в тот июльский день 2017 года он ответил: «Snowflake». Но это еще не все, он также придумал новый термин для описания того, что платформа Snowflake уже предоставляла в то время. Он придумал термин «озеро данных». Вот слайд, подтверждающий это:
Таким образом, термин «дом озера данных» впервые использовали 13 июля 2017 года для описания платформы Snowflake и ее способности поддерживать обе рабочие нагрузки с данными.
Есть кое-что гораздо большее
Платформа Snowflake предоставляется как услуга с практически нулевым обслуживанием и охватывает всех трех основных поставщиков общедоступных облаков. Они предлагают единую платформу, которая поддерживает все ваши данные и все бизнес-нагрузки, у нее централизованная система безопасности и управление. Но есть еще кое-что. Она поддерживает облако данных – глобальную сеть, объединяющую мировые данные. Клиенты из разных регионов могут безопасно обмениваться своими данными и кодом. Данными могут обмениваться даже поставщики облачных услуг без необходимости создавать и поддерживать дорогостоящие задания ETL для передачи данных и поддержания их в актуальном состоянии. Это достигается с помощью Data Marketplace, частных обменов данными или прямых обменов данными.
