В 2023 году ландшафт данных претерпел значительные изменения, открыв новые возможности (и потенциальные проблемы) для команд по разработке данных.

Автор: Оз Кац, соучредитель и технический директор Treeverse
 
Я верю, что в этом году мы увидим изменения в области аналитики, OLAP, разработки данных и сервисного слоя, что позволит командам получить усовершенствованные протоколы и больше возможностей для выбора из множества инструментов.
 
Прогнозы Data Lake
 
Переходим от Hadoop: в 2023 году такие инструменты, как DuckDB (C++), Polars (Rust) и Apache Arrow (Go, Rust, Javascript, ...), стали очень популярными, начав демонстрировать трещины в полном доминировании JVM и C/Python в пространстве аналитики.
 
Я полагаю, что темпы инноваций за пределами JVM ускорятся, отправив существующие архитектуры на основе Hadoop в ящик с устаревшим наследием.
 
Хотя большинство компаний уже не используют Hadoop напрямую, большая часть современных разработок по-прежнему построена на основе Hadoop: Apache Spark полностью полагается на реализацию ввода-вывода Hadoop для доступа к своим базовым данным. Многие архитектуры lakehouse основаны либо на таблицах в стиле Apache Hive, либо, что еще более непосредственно, на Hive Metastore и его интерфейсе для создания табличной абстракции поверх уровня хранения.
 
Хотя Hadoop и Hive по своей сути не так уж плохи, они больше не соответствуют передовому опыту. Они полностью основаны на JVM, которая в наши дни невероятно производительна, но все же не лучший выбор, если вы хотите получить максимальное преимущество от процессоров, которые просто не становятся быстрее.
 
Кроме того, Apache Hive, который сделал огромный шаг вперед в обработке больших данных, абстрагировавшись от базовой распределенной природы Hadoop и предоставив привычную абстракцию таблиц SQL (-ish) поверх распределенной файловой системы, начинает демонстрировать свой возраст и ограничения: отсутствие контроля транзакций и параллелизма, отсутствие разделения между метаданными и данными и другие уроки, которые мы извлекли за более чем 15 лет его существования.
 
Я считаю, что в этом году мы увидим, как Apache Spark уходит от этих корней: у Databricks уже есть реализация Apache Spark (Photon) без JVM, в то время как новые форматы таблиц, такие как Apache Iceberg, также отходят от наших коллективных корней Hive, внедряя открытую спецификацию для каталогов таблиц, а также предоставляя более современный подход к уровню ввода-вывода.
 
Битва хранилищ метаданных
 
Поскольку Hive медленно, но неуклонно уходит в прошлое, а форматы открытых таблиц, такие как Delta Lake и Iceberg, становятся повсеместными, центральный компонент любой архитектуры данных также вытесняется — «мета-хранилищем». Это уровень косвенной связи между файлами в объектном хранилище или файловой системе — и таблицами и сущностями, которые они представляют.
 
В то время как форматы таблиц открыты, кажется, что их мета-хранилища становятся все более проприетарными и закрытыми.
Databricks активно подталкивает пользователей к своему каталогу Unity, у AWS есть Glue, а у Snowflake тоже есть собственная реализация каталога. Они не совместимы друг с другом и во многом становятся средством привязки к поставщику для пользователей, стремящихся воспользоваться открытостью, которую предоставляют новые форматы таблиц. Я полагаю, что в какой-то момент маятник качнется в обратную сторону — пользователи будут стремиться к большей стандартизации и гибкости.
 
Big Data Engineering как практика будет развиваться
 
По мере того, как аналитика и дата-инжиниринг становятся все более распространенными, растет объем коллективных знаний и начинают появляться лучшие практики.
 
В 2023 году мы увидели, что инструменты, которые продвигают структурированный подход к инженерии данных от разработки до тестирования, становятся все более распространенными. Data Build Toolчрезвычайно популярен и зарекомендовал себя. Наблюдаемость и мониторинг в настоящее время также рассматриваются как нечто большее, чем просто приятное для имущих, судя по успеху таких инструментов, как Great Expectations, Monte Carlo и других платформ для обеспечения качества и наблюдаемости. lakeFS выступает за управление версиями самих данных, чтобы обеспечить git-подобное ветвление и слияние, позволяя создавать надежные, повторяемые конвейеры разработки, тестирования и выпуска.
 
Кроме того, сейчас мы также наблюдаем, как такие шаблоны, как Data Mesh и Data Products, продвигаются всеми, от Snowflake и Databricks до стартапов, которые появляются, чтобы заполнить пробел в инструментарии, который все еще существует вокруг этих шаблонов.
 
Я верю, что в 2024 году мы увидим всплеск инструментов, которые помогут нам достичь этих целей. От мониторинга и протоколирования, ориентированного на данные, до систем тестирования и улучшенных опций CI/CD — в практике разработки программного обеспечения предстоит многое наверстать, и сейчас самое подходящее время устранить эти пробелы.
 
Будущее сервисного слоя
 
Собственные облачные приложения будут перемещать большую часть своего состояния в объектное хранилище. В конце 2023 года AWS объявила, что в S3, ее основной службе хранения данных, появится одна из крупнейших функций с момента ее создания в 2006 году.
 
Эта функция, «S3 Express One-Zone», позволяет клиентам использовать тот же стандартный API объектного хранилища, который предоставляется S3, но с постоянной задержкой в миллисекундах для доступа к данным. При этом итоговая стоимость — примерно вдвое меньше, чем вызовы API.
 
Это знаменует собой кардинальное изменение. До сих пор варианты использования объектного хранилища были несколько узкими: хотя они позволяли хранить практически бесконечные объемы данных, приходилось довольствоваться более длительным временем доступа, даже если вы хотели прочитать лишь небольшой объем данных.
 
Очевидно, что этот компромисс сделал такие хранилища очень популярными для аналитики и обработки больших объемов данных, где задержка часто менее важна, чем общая пропускная способность, но это означало, что системы с низкой задержкой, такие как базы данных, высокопроизводительные вычисления и пользовательские приложения, не могли по-настоящему полагаться на них как на часть своего важного пути.
 
Если они и использовали объектное хранилище, то, как правило, в качестве архивного или резервного уровня хранения. Если вам нужен быстрый доступ, вы должны выбрать блочное устройство, подключенное к вашему экземпляру в той или иной форме, и отказаться от преимуществ масштабируемости и долговечности, которые предоставляют объектные хранилища.
Я считаю, что S3 Express One-Zone — первый шаг к изменению ситуации.
 
Благодаря последовательному чтению с низкой задержкой теперь теоретически возможно создавать базы данных, полностью поддерживаемые объектным хранилищем, которые вообще не полагаются на блочное хранилище. S3 — это новый дисковод.
Учитывая это, я прогнозирую, что в 2024 году мы увидим, что все больше операционных баз данных начнут применять эту концепцию на практике, позволяя базам данных работать в совершенно эфемерных вычислительных средах и полагаясь исключительно на хранилище объектов для сохранения данных.
 
Операционные базы данных начнут дезагрегироваться
 
Учитывая предыдущее предсказание, мы можем шагнуть дальше: что, если мы стандартизируем уровень хранения для OLTP так же, как мы стандартизировали его для OLAP?
 
Одно из самых больших преимуществ Data Lake — возможность разделения хранилища и вычислений, чтобы данные, записанные с помощью одной технологии, могли быть прочитаны другой.
 
Это дает разработчикам свободу выбора лучшего в своем классе стека, который максимально соответствует их сценарию использования. Нам потребовалось некоторое время, чтобы достичь этого, но с такими технологиями, как Apache Parquet, Delta Lake и Apache Iceberg, это теперь выполнимо.
 
Что, если нам удастся стандартизировать форматы, используемые также для оперативного доступа к данным? Давайте представим абстракцию ключ/значение (возможно, аналогичную LSM sstables?), которая позволяет хранить отсортированные пары ключ-значение, оптимально подходящие для хранения объектов.
 
Мы можем развернуть систему управления базами данных без учета состояния, чтобы обеспечить возможности анализа/планирования/выполнения запросов сверху, даже в виде лямбда-функции по требованию. Другая система могла бы использовать ту же абстракцию хранилища для хранения инвертированного индекса для поиска или индекса векторного сходства для крутого приложения с генеративным искусственным интеллектом.
 
Хотя я не думаю, что через год мы будем использовать все наши базы данных как лямбда-функции, я полагаю, что мы увидим переход в операционных базах данных от «объектных хранилищ как архива» к «объектным хранилищам как системе записи».
 
Заключение
 
Я с оптимизмом смотрю на то, что в 2024 году ландшафт данных продолжит развиваться в основном в правильном направлении: улучшение абстракций, совершенствование интерфейсов между различными частями стека и новые возможности, открываемые технологической эволюцией.
 
Да, это не всегда будет идеально, и за простоту использования придется заплатить меньшей гибкостью, но, наблюдая за ростом этой экосистемы в течение последних двух десятилетий, я думаю, что мы находимся в лучшей форме, чем когда-либо.
 
У нас больше выбора, лучшие протоколы и инструменты, а барьер входа ниже, чем когда-либо прежде. И я не думаю, что ситуация изменится.
 
Ссылка на источник