Озера данных сейчас в моде на крупных предприятиях. Озеро данных - это единое хранилище для необработанных копий исходных системных данных и преобразованных данных для использования в таких задачах, как отчетность, визуализация, расширенная аналитика и машинное обучение.
Хранилища объектов (например, S3) становятся предпочтительной платформой для озер данных по двум основным причинам:
- Они обеспечивают дешевое, надежное и практически неограниченное хранилище в облаке.
- Они позволяют разделить вычислительные ресурсы и хранилище, позволяя масштабировать любой из них независимо.
В этом сообщении в блоге я более подробно расскажу о некоторых преимуществах объектных хранилищ, благодаря которым они популярны как платформа для озер данных. Я также рассмотрю некоторые из часто недооцениваемых проблем, которые мешают использованию хранилищ объектов во многих случаях использования озера данных.
Преимущество хранилища объектов: надежное, дешевое и практически неограниченное хранилище
Магазины объектов, такие как S3, обеспечивают одиннадцать девяток надежности (99,999999999%) и четыре девятки доступности (99,99%), и им удается делать это практически в неограниченном масштабе по невероятно низкой цене около 23 долларов за ТБ в месяц. Сравните это с локальными устройствами хранения данных (DWA), которые были довольно популярны всего несколько лет назад. Стоимость DWA составляет десятки тысяч долларов за терабайт без учета корпоративной поддержки. Довольно распространены многомиллионные контракты на DWA, поддерживающие всего несколько сотен терабайт.
Когда ИТ-руководители размышляют о выборе платформы данных для своих озер данных, цена объектных магазинов в размере 23 долларов за ТБ в месяц слишком хороша, чтобы сопротивляться. Имеет смысл использовать самое дешевое хранилище для больших объемов данных (от сотен терабайт до петабайт), которые, как ожидается, будут содержать озера данных. Такие хранилища объектов, как S3, кажутся (ошибочно, как мы увидим позже в этом посте) представляют собой тысячукратное ценовое преимущество по сравнению с DWA, все еще используемым на многих крупных предприятиях.
Преимущество хранилища объектов: разделение хранилища и вычислений
Масштаб хранения, необходимый для озера данных, делает использование таких архитектур, как DWA, в которых хранилище и вычислительные ресурсы объединены в одном пакете, непомерно дорогим. Разделение хранилища и вычислений позволяет нам в любой момент времени задействовать нужный объем вычислений по запросу для обработки данных, которые необходимо проанализировать. Это значительно снижает общую стоимость решений для анализа данных.
Понятно, что все эти преимущества имеют решающее значение для повышения популярности S3 и других хранилищ объектов в качестве платформы для озер данных. Но магазины предметов сопряжены с множеством проблем, которым не уделяется должного внимания. Это особенно верно для данных из РСУБД и часто обновляемых (ежедневно / ежечасно) данных, которые составляют основную часть высококачественных данных на предприятии.
Недостаток хранилища объектов: неизменяемость
Все хранилища объектов, включая S3, GCS и хранилище BLOB-объектов Azure, неизменяемы. Это означает, что файлы, однажды записанные в хранилище объектов, никогда не могут быть отредактированы. Пользователи могут только полностью удалить старый файл и создать новый или логически удалить старый файл и создать новый (управление версиями).
При использовании S3 в качестве платформы данных для часто обновляемых данных из РСУБД это приводит к созданию огромного количества небольших файлов для каждой таблицы.
Поскольку вставки, обновления и удаления накапливаются с течением времени, попытки получить текущее состояние таблицы становятся экспоненциально более затратными по времени и вычислительным ресурсам. Большинство специалистов по данным отказываются от этого сложного предприятия и вместо этого запрашивают прямой доступ к исходным системам, в первую очередь сводя на нет цель использования озера данных.
U = обновить, I = вставить, D = удалить
Решение, часть 1: разделите данные
Одним из решений, позволяющих снять ответственность за слияние изменений с конечных пользователей, является разделение данных и повторная запись разделов, на которые были нацелены последние операции вставки, обновления и удаления. Это несколько облегчает нагрузку на конечных пользователей. Однако проблемы с производительностью остаются, особенно если таблица имеет большое количество столбцов и для анализа требуется только подмножество этих столбцов.
Решение, часть 2: используйте столбчатое хранилище
Вышеупомянутое решение можно улучшить, используя столбчатый формат, такой как Apache Parquet или Apache ORC. Столбцовые форматы значительно улучшают производительность за счет лучшего сжатия данных и ограничения ввода-вывода только столбцами, необходимыми для анализа. Однако чтение файлов Parquet с языков и инструментов (таких как Python, R или Tableau) остается сложной задачей.
Решение, часть 3: упростите доступ с помощью интерфейсов SQL
Для дальнейшего развития этого решения многие инженеры добавляют интерфейс SQL (например, AWS Athena, Presto или Spark SQL) поверх необработанных файлов Parquet. Это значительно упрощает доступ к данным для конечных пользователей, которые теперь могут выполнять SQL-запросы на своих любимых языках программирования и инструментах (например, Python, R или Tableau).
Решение, часть 4: добавление возможностей с помощью Delta Lake
Вышеупомянутое решение можно еще раз улучшить, используя уровень хранения с открытым исходным кодом, такой как Delta Lake. Delta Lake дополнительно улучшает формат Parquet, добавляя поддержку транзакций ACID (атомарность, согласованность, изоляция, долговечность), лямбда-архитектуру для поддержки потоковых и пакетных сценариев использования, а также возможность доступа к данным в том виде, в котором они были на дату предыдущего обновления / время (путешествие во времени).
Задача решена?
Не так быстро! Вышеупомянутая архитектура действительно представляет собой работоспособное решение, и многие предприятия похлопывают себя по спине за возможность спроектировать и ввести в действие такое решение. Честно говоря, возможность реализовать это в масштабе - настоящее достижение. Тем не менее, эта архитектура по-прежнему страдает множеством проблем, и есть еще много возможностей для улучшения. Ключевые проблемы с Delta Lake поверх S3 в качестве платформы для озера данных включают:
- Архитектура не касается создания наборов изменений, которые может быть довольно сложно создать.
- Довольно сложно внедрить и поддерживать устойчивые решения для извлечения, преобразования и загрузки (ETL) корпоративного уровня.
- Написание файлов Parquet и Delta требует дополнительных вычислений, а также технических ноу-хау, чтобы настроить и ввести в действие в масштабе кластерные вычислительные платформы, такие как Apache Spark.
- Доступ к интерфейсу SQL (через такие технологии, как AWS Athena, Presto или Spark SQL) требует дополнительной вычислительной инфраструктуры, что увеличивает общую сложность и стоимость решения.
- Сложность решения делает поддержку дорогостоящей.
- S3 предоставляет ограниченные возможности метаданных и тегов
- Интеграция безопасности на уровне таблиц или строк в объекты в S3, особенно для крупных и сложных предприятий, может быть довольно сложной задачей.
- И последнее, но не менее важное: производительность такой платформы сильно отстает от производительности устройств хранилищ данных, которые она намеревалась заменить.
Учитывая скрытые затраты на вычисления и поддержку, интеграцию с безопасностью и проблемы с производительностью, S3 как платформа данных для часто обновляемых данных, полученных из РСУБД, далек от обещанных 23 долларов за ТБ в месяц. После того, как мы сложим все затраты, они начинают постепенно доходить до нескольких тысяч долларов за ТБ в месяц. За такие деньги есть гораздо лучшие альтернативы.
Базы данных управляемой аналитики облачного масштаба, такие как Snowflake, Google BigQuery или Azure Synapse Analytics, предлагают лучшее из обоих миров. Разделяя хранилище и вычислительные ресурсы, они обеспечивают сопоставимые с S3 затраты на хранилище вместе с платформой управляемых данных, которая устраняет сложность внедрения аналитических решений облачного масштаба. Они предлагают ту же совокупную стоимость владения, что и Parquet / ORC / Delta Lake на базе S3, с интерфейсом AWS Athena / Presto / Spark SQL, при этом демонстрируя лучшую производительность, интеграцию безопасности и поддержку схем. Они также сокращают операционные накладные расходы, передавая технический и кадровый риск стороннему поставщику.
А как насчет статических данных из РСУБД?
Полученные из РСУБД, в основном статические данные (т. Е. Они не меняются в течение недель или месяцев) не требуют таких больших затрат на вычисления и поддержку ETL, как часто обновляемые данные из РСУБД. Однако я бы порекомендовал предпочесть облачные управляемые аналитические базы данных, а не хранилище Parquet / ORC / Delta Lake на базе S3 для таких случаев использования, поскольку все проблемы и затраты, связанные с управлением метаданными, интеграцией безопасности и производительностью, остаются.
А как насчет полуструктурированных данных?
Большинство полуструктурированных данных, поступающих на предприятие (в таких форматах, как XML, JSON и CSV), имеют достаточно стабильную схему и могут быть вставлены в реляционные таблицы. Большинство таких данных на крупных предприятиях часто загружаются в аналитические базы данных, такие как AWS Redshift, или доступны через интерфейсы SQL, такие как AWS Athena, Presto или Spark SQL, через хранилище Parquet / ORC / Delta Lake на основе S3. Для этого типа использования я бы порекомендовал рассмотреть базы данных управляемой аналитики, которые разделяют хранилище и вычисления.
ТШО должен быть вашей северной звездой
В конце концов, о решениях следует судить по совокупной стоимости владения (TCO), учитывая возможности, которые они предоставляют, и риски, присущие решению. Если два решения имеют одинаковую совокупную стоимость владения, но одно из них обеспечивает лучшие возможности, согласование с этим решением не составит труда. Кроме того, следует тщательно учитывать технические риски и риски, связанные с талантами, связанные с решениями, разработанными собственными силами. Как правило, для крупных предприятий имеет смысл переложить риски, связанные с технологиями и талантами, на продукты надежных поставщиков, если это целесообразно.
Так когда же хранилища объектов полезны в качестве платформ озера данных?
Хранилища объектов (например, S3) остаются отличной платформой данных для других случаев использования, таких как полуструктурированные и неструктурированные данные, которые не могут или не должны (по причинам стоимости или полезности) загружаться в аналитические базы данных облачного масштаба. Например, не имеет смысла загружать изображения, аудиофайлы, видео, электронные письма, презентации PowerPoint, документы Word или PDF-файлы в базы данных управляемой аналитики. Кроме того, многие из этих распределенных баз данных облачного масштаба используют хранилища объектов (например, S3) в качестве интерфейса приема данных, а некоторые даже используют хранилища объектов в качестве внутренних управляемых платформ хранения за сценой.
В одном из следующих постов мы подробно обсудим, почему облачные управляемые аналитические базы данных, разделяющие хранилище и вычислительные ресурсы (например, Снежинка, Google BigQuery или Azure Synapse Analytics), сочетаются со специализированными инструментами CDC (такими как Qlik Replicate, Oracle GoldenGate или HVR CDC) лучше подходят для часто обновляемых данных, получаемых из РСУБД, в корпоративных озерах данных.
Отказ от ответственности: это личное сообщение в блоге. Мнения, выраженные здесь, принадлежат мне, а не моим нынешним или бывшим работодателям. Все материалы предназначены только для образовательных целей, без каких-либо гарантий пригодности.
