Это был пост в блоге, который я планировал написать еще весной, когда увидел, что ажиотаж вокруг DuckDB начал подниматься на новый уровень. С тех пор обсуждение DuckDB только усилилось в сообществе разработчиков и специалистов по обработке данных. В настоящее время я вижу две тенденции в сообществе данных с высоким уровнем вовлеченности: DuckDB и Rust берут на себя разработку данных . Но в чем на самом деле шумиха вокруг DuckDB? Давайте немного поцарапаем поверхность.

Сегодняшнее ускорение в пространстве данных может быть связано со взрывным ростом облачных хранилищ данных за последние несколько лет. Облачные хранилища данных стали краеугольным камнем стеков данных: компании и организации всех размеров используют хранилища данных для реализации сценариев использования аналитики. Стремительный взлет Snowflake, кульминацией которого стало ее блокбастерное IPO в сентябре 2020 года, ставшее крупнейшим IPO программного обеспечения в истории, стал образцом этой тенденции.

Рассматривая 3 Vs больших данных (скорость, объем, разнообразие), многие в сообществе данных, с которыми я говорил в последнее время, сказали, что наиболее востребованным параметром в последние годы была скорость.

Как отмечает Мехди Уазза (штатный инженер по данным в Trade Republic) — правда в том, что не у всех есть «большие» данные, — но требование низкой задержки потребления микросервиса для активов данных, обрабатываемых из вашей базы данных OLTP, является общий вариант использования.

Как говорит Мехди , если посмотреть на некоторые тенденции в продуктах (RocksDB, DuckDB, Clickhouse), все они обеспечивают более простой интерфейс для потребления с низкой задержкой. В эти приложения инвестировали даже некоторые гиганты облачных хранилищ данных, такие как Snowflake Unistore .

Тем не менее, текущая парадигма облачного хранилища данных по-прежнему сильно перекошена для варианта использования клиент-сервер и игнорирует растущий сегмент пользователей. Как отмечает Томаш Тунгуз (инвестор Redpoint Ventures):

«Большинство рабочих нагрузок невелики. Вместо того, чтобы требовать масштабируемую базу данных в небе, большинство анализов выполняются быстрее с оптимизированной базой данных на вашем компьютере, которая при необходимости может использовать облако».

DuckDB меняет это.

Как видно из приведенных выше данных поиска Google Trends, за последние несколько месяцев вокруг DuckDB в сообществе данных нарастало обсуждение и ощутимая шумиха.

Растущий импульс

Растущий импульс DuckDB становится очевидным, просто просматривая сообщения в социальных сетях. Например , Роберт Сахлин (руководитель отдела обработки данных в MatHem) еще в июле отметил в LinkedIn следующее:

«В последнее время я слышал много хорошего о DuckDB и нашел подкасты с участием Джордана Тигани (основателя MotherDuck и знаменитости BigQuery) и Ханнеса Мюлейзена (создателя-основателя DuckDB Labs). Поэтому мне пришлось попробовать. Моя первая программа заключалась в создании таблицы DuckDB путем чтения непосредственно из таблицы BigQuery с использованием BigQuery Storage Read API, поскольку он поддерживает таблицы со стрелками (и не требует вычислений). Оказалось, что это очень просто, поделившись сутью. Не терпится поэкспериментировать с DuckDB и с большими объемами данных, у нее определенно огромный потенциал».

И Роберт определенно не единственный, кто в восторге от DuckDB, читая сообщения в социальных сетях (я рекомендую просто выполнить поиск по хэштегу #duckdb в LinkedIn или Twitter). Например , Абхишек Чоудхари (старший ведущий инженер по обработке данных Bayer) недавно написал в LinkedIn следующее :

«Мнение: DuckDB — одна из самых захватывающих новых технологий для Data Engineering/Data Science. DuckDB безумно быстр, а с Apache Arrow этот дуэт способен давать поразительные результаты. Еще одним важным моментом DuckDB является его простота. Он не претендует на какие-либо новаторские решения, но придерживается принципа простого и быстрого доступа к данным».

Тем не менее, мой любимый комментарий в социальных сетях о DuckDB, скорее всего, принадлежит Джошу Уиллсу в ветке Twitter , в которой обсуждается сообщение в блоге « Как Snowflake терпит неудачу » всегда интересного Бенна Стансила (рекомендую подписаться на его Substack ):

Ниже вы найдете несколько дополнительных скриншотов твитов, демонстрирующих интерес, который в настоящее время вызывает DuckDB в сообществе данных:

Создание управляемого решения поверх DuckDB

Это довольно классическая схема: возьмите инструмент с открытым исходным кодом, демонстрирующий импульс, и создайте на его основе сервис. Например, Databricks сделал это со Spark, а Confluent с Kafka.

Джордан Тигани , давний руководитель продукта BigQuery в Google (знаменитость BigQuery, как ранее отмечал Роберт Сахлин), объявил в мае, что он является соучредителем бессерверной облачной версии DuckDB под названием MotherDuck . К нему присоединяется его коллега по Google Тино Терешко .

Помимо MotherDuck, у нас есть DuckDB Labs — коммерческая компания, созданная Ханнесом Мюлейзеном и другими создателями DuckDB в июле 2021 года для предоставления поддержки, пользовательских расширений и даже пользовательских версий продукта в качестве способа его монетизации.

Как отметила Лорен Балик в своем блоге « 6 основанных на реальности прогнозов для данных в 2023 году », венчурные капиталисты и специалисты по данным правы, стекаясь в DuckDB.

Этот интерес материализовался вчера, когда MotherDuck объявила о своем раунде финансирования на сумму 47,5 млн долларов, возглавляемом, например, a16z (ранние инвесторы, например, в Databricks) и Redpoint Ventures (ранние инвесторы, например, в Snowflake). Одновременно MotherDuck и DuckDB Labs объявили о стратегическом партнерстве .

Джордан Тигани (соучредитель MotherDuck) прокомментировал TechCrunch следующее, объявляя о раунде финансирования:

«Пользователи хотят простых и быстрых ответов на свои вопросы — они не хотят ждать облака… Дело в том, что современный ноутбук работает быстрее, чем современное хранилище данных. Поставщики облачных данных сосредоточены на производительности запросов объемом 100 ТБ, что не только не имеет значения для подавляющего большинства пользователей, но и отвлекает от способности поставщиков обеспечить отличное взаимодействие с пользователем».

Но что это за шумиха? Давайте немного поцарапаем поверхность.

DuckDB — это простая в использовании внутрипроцессная база данных OLAP с открытым исходным кодом (которая обрабатывает данные в памяти и не требует выделенного сервера/службы), которую многие в упрощенном виде описывают как эквивалент SQLite для аналитических рабочих нагрузок OLAP.

На HackerNoon его однажды описали как «мутантное потомство SQLite и Redshift».

Как отмечает команда MoterDuck , DuckDB , будучи внутрипроцессной базой данных, представляет собой механизм хранения и вычислений, который позволяет разработчикам, специалистам по обработке и анализу данных, инженерам данных и аналитикам данных дополнять свой код чрезвычайно быстрым анализом с использованием простого SQL. Кроме того, DuckDB может анализировать данные там, где они могут храниться, например, на ноутбуке или в облаке. Кроме того, DuckDB поставляется с простым интерфейсом командной строки для быстрого прототипирования — без необходимости настройки, разрешений, создания таблиц и управления ими и т. д.

Основываясь на чтении тем, например, на HackerNews, Reddit и Twitter, кажется, что в DuckDB есть что понравиться, например:

• Его производительность для аналитических рабочих нагрузок на машинах с одним узлом кажется впечатляющей, а установка безболезненна (технически вы можете начать изучать DuckDB в течение 5 минут).
• DuckDB встраивается — как SQLite — и оптимизирован для аналитики. Самое важное здесь — это встраиваемая часть (например, библиотека без типичной зависимости PostgreSQL), устраняющая сетевую задержку, которую вы обычно получаете при общении с базой данных.
• У DuckDB также очень мало усилий по развертыванию — `pip install duckdb`, и вы готовы к гонкам.
• Кроме того, DuckDB работает быстро — по сравнению с запросами Postgres, DuckDB в 80 раз быстрее , и при тестировании других систем мы можем увидеть столь же впечатляющие результаты .

На практике любой ЦП можно мобилизовать для выполнения мощной аналитики через DuckDB. Кроме того, DuckDB является переносимым и модульным, без каких-либо внешних зависимостей. Конкретно это означает, что вы можете запускать DuckDB на облачной виртуальной машине, в облачной функции, в браузере или на своем ноутбуке, как упоминалось ранее.

Сделаем шаг назад

В следующем разделе я в значительной степени заимствую отличный июньский пост Коджо Осея (инвестора Matrix Partners) в блоге о DuckDB.

Как отмечает Коджо, новая категория хранилищ данных находится на пересечении аналитических запросов и встроенных развертываний. Чтобы проиллюстрировать, почему это так убедительно, он классифицирует базы данных по двум осям:

Как видно выше и отмечено Коджо, текущие базы данных оптимизированы для аналитических или транзакционных рабочих нагрузок. Аналитические рабочие нагрузки, также называемые оперативной аналитической обработкой (OLAP), представляют собой сложные запросы к историческим данным. Например, вы можете проанализировать регистрацию пользователей с разбивкой по демографическим данным, таким как возраст и местоположение. С другой стороны, транзакционные рабочие нагрузки, также называемые оперативной обработкой транзакций (OLTP), оптимизированы для быстрого чтения и записи в реальном времени.

Перейдем к типам развертывания.

Как показано выше и отмечено Коджо, современные технологии баз данных развертываются как автономные или встроенные решения. Автономные базы данных обычно развертываются в парадигме клиент-сервер. База данных находится на централизованном сервере и запрашивается клиентским приложением. Встроенные базы данных выполняются внутри основного процесса любого приложения, обращающегося к базе данных.

Теперь немного магии. Когда мы объединяем эти две оси, мы видим инновационный разрыв! Как подчеркивает Коджо, текущие инновации в базах данных OLAP сосредоточены на автономных базах данных OLAP, таких как Snowflake, ClickHouse и Redshift (не знаю, почему он не упомянул BigQuery). Это привело нас к ситуации, когда варианты использования встроенной аналитики упускались из виду и недостаточно обслуживались. DuckDB меняет это.

Примеры использования DuckDB

В глоссарии Airbyte есть краткое описание примеров использования DuckDB:

• Сверхбыстрый аналитический вариант использования локально. Например, пример такси в глоссарии Airbyte включает пример данных о такси за 10 лет, 1,5 миллиарда строк, который до сих пор работает на ноутбуке. См. бенчмарки здесь .
• Его можно использовать как оболочку SQL с нулевыми копиями (поверх паркетов в S3).
• Предоставьте свои данные пользователям вместо больших циклов и задержек, выполняя вызовы REST. Вместо этого вы можете поместить данные внутрь клиента. Вы можете делать 60 кадров в секунду, так как данные находятся там, где находится запрос.
• DuckDB на Kubernetes для слоя с нулевым копированием для чтения S3 в Data Lake ! Вдохновленный этим твитом. Самый дешевый и быстрый вариант для начала.

• Обработка и хранение наборов табличных данных, например, из файлов CSV или Parquet
• Выполнение интерактивного анализа данных, например объединение и объединение нескольких больших таблиц.
• Одновременные большие изменения в нескольких больших таблицах, например добавление строк, добавление/удаление/обновление столбцов
• Передача большого набора результатов клиенту

• Наличие сценариев использования с большими объемами транзакций (например, отслеживание заказов электронной коммерции)
• Запись в одну базу данных из нескольких параллельных процессов
• Наличие крупных клиент-серверных установок для централизованного хранения корпоративных данных

Последние мысли

Существует множество систем управления базами данных. Но, как отмечают создатели DuckDB: универсальной системы баз данных не существует. Все они идут на разные компромиссы, чтобы лучше приспособиться к конкретным случаям использования. DuckDB ничем не отличается.

Когда вы думаете о выборе ядра базы данных для своего проекта, вы обычно рассматриваете варианты, ориентированные на обслуживание нескольких одновременных пользователей. Иногда то, что вам действительно нужно, — это встроенная база данных, которая молниеносно справляется с однопользовательскими рабочими нагрузками. Войдите в DuckDB.

Кроме того, кажется, что DuckDB также позволяет всему сообществу энтузиастов SQL мгновенно продуктивно работать с Python, никогда не изучая ничего, кроме самых базовых Pandas. Растет число членов сообщества данных, которые больше никогда не используют Pandas для чего-либо сложного, потому что они предпочитают SQL.

Луис Веласко (руководитель отдела обработки данных в Google) несколько месяцев назад хорошо резюмировал в LinkedIn , почему он считает DuckDB важным делом:

1. Мы живем в эпоху великой дезагрегации платформ централизованных данных. Наиболее экстремальная парадигма децентрализованного вычисления, о которой я могу думать, — это сетка из ноутбуков. Комбинация таких технологий, как паркет + pyaArrow с векторизованным выполнением, позволяет эффективно запрашивать большие наборы данных на персональных устройствах.

2. С повышением грамотности данных и улучшением навыков кодирования у подавляющего большинства работников, работающих с данными, потребление аналитических данных далеко не статично (панельные панели), а является исследовательским и самообслуживаемым. Поэтому я представляю, как аналитики данных получают доступ к данным в облачном хранилище, выполняя встроенный анализ локально с помощью duckDB.

3. SQL живее, чем когда-либо прежде — и точка.

4. Нулевые усилия по развертыванию — `pip install duckdb` и вы в

5. Открытый исходный код. Формируется активное сообщество с поддержкой таких ключевых элементов, как pandas, dbt или apachesuperset, не говоря уже о новых стартапах, таких как DuckDB Labs и MotherDuck.

Что вы думаете о будущем DuckDB?

PS: я рекомендую посмотреть видео The Seattle Data Guy «Что такое DuckDB» , в котором он вместе с Джозефом Мачадо (старшим инженером по данным в LinkedIn) обсуждает, как DuckDB стремительно вошла в мир данных.