К основному содержимому
#Data

Big Data is Dead (Рубрика Data)

#Data #Database #Architecure #Software #SystemDesign #Engineering

Этот пост Jordan Tigani вышел почти два года назад в блоге компании MotherDuck, которая является материнской для DuckDB. Сам Jordan был одним из инженеров, что стояли у основ Google BigQuery, а потом он отвечал за ее продуктовое развитие, а значит знает о чем говорит. Ну а компания MotherDuck пытается сделать облачную версию DuckDB, интересную аналитическую in-process базу данных, про которую рассказывали в докладе "DuckDB: Crunching Data Anywhere, From Laptops to Servers • Gabor Szarnyas • GOTO 2024 ", который я уже разбирал. Но если возвращаться к самой статье, то основной посыл Джордана в том, что эпоха «больших данных» как доминирующей концепции завершилась. Суть в том, что большинство организаций на самом деле не работают с огромными объемами данных, и акцент должен сместиться с размера данных на получение практических инсайтов. Ключевыми идеями статьи являются

1) Рассмотрение хайпа больших данных через призму реальности: нарратив о том, что компании перегружены огромными объемами данных, не оправдался для большинства организаций. Хотя объемы данных растут, развитие аппаратного обеспечения и технологий баз данных опережает эти темпы, делая традиционные системы достаточными для многих задач. 2) У большинства компаний умеренный объем данных: анализ клиентских данных Google BigQuery показывает, что большинство организаций управляют относительно небольшими наборами данных, часто менее 1 терабайта. Даже крупные предприятия редко генерируют или обрабатывают действительно огромные массивы данных, а типичные рабочие нагрузки затрагивают лишь небольшую часть хранимой информации. 3) Разделение compute и storage: современные облачные архитектуры разделяют хранение и вычислительные ресурсы, позволяя масштабировать их независимо. Это привело к росту объема хранилищ при тех же вычислительных потребностях, так как аналитика чаще сосредоточена на актуальных или агрегированных данных, а не на исторических архивах. 4) Экономические и практические ограничения: обработка больших объемов данных дорогостоящая и зачастую избыточная. Такие технологии, как колоночное хранилище, отсечение разделов и сжатие данных, сокращают объем обрабатываемой информации, что соответствует экономическим стимулам минимизировать затраты. 5) Данные как источник риска: хранение большого количества неиспользуемых данных может создавать риски, включая проблемы с соблюдением нормативных требований (например, GDPR), юридическую ответственность и операционные сложности из-за «старения» старых наборов данных. 6) Спад популярности систем для больших данных: традиционные монолитные базы данных (например, MySQL и Postgres) демонстрируют рост популярности, тогда как масштабируемые системы вроде NoSQL стагнируют. Количество рабочих нагрузок, требующих распределенных систем, сократилось благодаря значительному увеличению возможностей одиночных машин.

Напоследок Джордан предлагает компаниям оценивать свои реальные потребности в работе с данными вместо того, чтобы следовать маркетинговым нарративам о «больших данных». Большинство организаций могут извлечь выгоду из инструментов для управления данными меньшего масштаба вместо инвестиций в системы для гипотетически огромных массивов информации. Кстати, одним из таких инструментов может быть и DuckDB (это читается между строк).

P.S. В продолжении темы можно изучить

  1. Статью "What Goes Around Comes Around... And Around..." Майкла Стоунбрейкера, создателя Postgres, и Эндрю Павло, исследователя баз данных, про развитие СУБД за последние 20 лет. У меня есть краткий обзор в трех частях: 1, 2 и 3
  2. Выступление от создателя DuckDB "A Short Summary of the Last Decades of Data Management • Hannes Mühleisen • GOTO 2024" и мое краткое саммари
  3. Подкаст "Research Insights #6 с Колей Головым про дата платформы"
  4. Подкаст "Code of leadership #22 с Димой Аношиным про data engineering"

#Database #Architecure #Software #Data #SystemDesign #Engineering