Содержание
Сегодня мы совершим небольшую экскурсию по движущимся частям, которые составляют материализацию.
Этот тур не должен быть исчерпывающим, а скорее показать некоторые моменты, когда вещи могут отличаться от того, что вы ожидаете, и дать вам представление о том, почему Materialize относительно лучше поддерживает SQL-запросы по сравнению с изменяющимися данными. В частности, как он обеспечивает интерактивный доступ к современным данным, как он делает это, используя меньше ресурсов, чем вы могли бы ожидать, и как он операционно проще, чем другие подходы.
Широкими Мазками
Давайте начнем с нескольких широких штрихов, которые называют движущиеся части системы.
Мы будем использовать следующую принципиальную схему:
Пользователи взаимодействуют с Materialize в основном через интерфейс pgwire-esque с помощью SQL-команд, которые создают, запрашивают и удаляют источники данных, представления и материализации. Эти команды направляются координатору, задача которого состоит в отслеживании метаданных об этих источниках, представлениях и материализациях, а также в обмене информацией со слоем потока данных о том, что он должен делать дальше. Уровень потока данных отвечает за выполнение и обслуживание представлений, предоставляемых координатором.
Мы будем погружаться в каждую из них все более подробно. В основном они все больше отличаются от существующей инфраструктуры, и поэтому по мере того, как мы углубляемся вглубь, нам нужно сказать еще больше. Я также лучше знаком с более глубокими вещами; нам нужно будет попросить некоторых других людей объяснить, как Materialize адаптируется к существующим идиомам SQL и ожиданиям.
Передний конец
Мы намеренно стремились сделать пользовательские интерфейсы Materialize как можно более неинтересными. Чем более обычны эти интерфейсы, тем больше существующих инструментов и вариантов использования могут напрямую подключаться к материализации и двигаться вперед без новых SDK или усилий по программированию. Вы можете использовать psql для прямого подключения к Materialize или BI-инструменты, такие как Metabase, для обогащения опыта. Со стороны мы хотим, чтобы Materialize выглядела и чувствовала себя как база данных, которую вы и ваша инфраструктура данных ожидаете.
Конкретно это означает, что вы (или инструменты от вашего имени) устанавливаете сеансы, в которых вы создаете, выбираете из них, ХВОСТИРУЕТЕ и отбрасываете различные объекты. Вы можете прочитать о полном словаре в документации Materialize. Ваша сессия передаст ваши команды координатору, который определит, имеют ли они смысл и какой ответ предоставить.
Координатор
Сразу за пользовательскими интерфейсами живет координатор, мозги которого материализуются. Здесь мы отслеживаем информацию об источниках данных, которые вы (и другие пользователи) установили, представлениях, которые вы создали над ними, и материализациях, которые мы поддерживаем для вас. Здесь мы анализируем, планируем и оптимизируем ваши SQL-запросы и, когда это уместно, поручаем слою потока данных запустить новое вычисление для выполнения и поддержания их результатов. Координатор также отслеживает состояние материализаций и гарантирует, что мы воспользуемся ими при планировании того, как отвечать на новые запросы и поддерживать их.
Когда ваши запросы поступают, они немного больше, чем текст SQL, и должны быть проанализированы, спланированы и оптимизированы. Этот процесс в значительной степени хорошо понятен, хотя и чреват семантической опасностью, но есть некоторые причуды, которые материализуются специфично. Стоимость обслуживания потока данных может сильно отличаться от стоимости выполнения запроса один раз. Материализованные запросы будут выполняться как долгоживущий поток данных с сохранением состояния и накладывать постоянные затраты на вычисления и память. По мере изменения входных данных мы хотим быстро реагировать и не можем позволить себе полную переоценку запроса. Это приводит к процессу оптимизации, который имеет другие приоритеты, чем традиционные оптимизаторы.
Координатор также отвечает за отслеживание свойств материализаций, которые мы поддерживаем. Материализация состоит из некоторых наборов данных, и они упорядочены некоторыми ключами (часто столбцами). Эти две характеристики говорят координатору, может ли материализация помочь в построении и поддержании нового потока данных. Использование и повторное использование материализованных данных лежит в основе того, что отличает Materialize от существующих систем.
В конечном счете, основная роль координатора заключается в предоставлении инструкций слою потока данных, где собираются и поддерживаются вычисления потока данных для запросов, и где хранятся данные, поддерживающие материализацию.
Выполнение Потока Данных
Если координатор-это мозг, который думает о том, что делать с обработкой данных, то слой потока данных-это мышца, которая заставляет это происходить. Уровень потока данных содержит основные отклонения от стандартных реляционных баз данных и от механизмов потоковой обработки, с которыми вы, возможно, наиболее знакомы.
Наш уровень потока данных построен на своевременном потоке данных и дифференциальном потоке данных, масштабируемых структурах параллельного потока данных, предназначенных для обработки информации настолько эффективно,насколько мы знаем. Важно отметить, что эти фреймворки предназначены для захвата и совместного использования состояния в нескольких потоках данных с использованием инструмента под названием shared arrangements: потоковый эквивалент потоков данных индексов реляционных баз данных. Мы объясним, что это такое, и свяжем точки с поддержанием SQL-запросов над изменяющимися данными.
В своевременном потоке данных несколько рабочих потоков взаимодействуют для выполнения и поддержания нескольких потоков данных. Каждый рабочий поток знает обо всех потоках данных и может выполнять логику для любого из операторов; маршрутизация данных отдельным рабочим определяет, где на самом деле происходит работа и где удерживается состояние. Это отличается от многих систем больших данных, которые изолируют каждого оператора на своем собственном потоке или компьютере.
Ключевая концепция 1 Дизайн Materialize отделяет сложность ваших запросов от сложности вашего развертывания. Вы можете поддерживать сотни запросов на одной машине и масштабировать их до нескольких машин только тогда, когда захотите.
Когда несколько работников сотрудничают в вычислении, особенно в быстродействующем вычислении, они рискуют внести хаос. Традиционные механизмы работы с базами данных, регулярная блокировка и координация между потоками негативно влияют на масштабируемость и пропускную способность. Традиционные механизмы потоковых систем изолируют единицы выполняемой работы, что ограничивает возможность совместного использования ресурсов в потоках данных. В materialize мы хотим обеспечить как масштабируемость, так и экономичность, а также должны использовать более четкие механизмы координации.
Все обновления в Materialize имеют логическую метку времени, недвусмысленное указание на то, когда обновление «происходит». Эта временная метка может быть временем настенных часов или идентификатором транзакции из вашей базы данных; вы можете выбрать ее значение. Все операторы сохраняют эту логическую метку времени в своих выходных данных и тем самым поддерживают согласованное представление результатов. Результаты запросов всегда корректны относительно этой временной метки и никогда не выходят из синхронизации друг с другом, даже если их выполнение является асинхронным и выполняется несколькими параллельными рабочими.
Ключевая концепция 2 логические временные метки позволяют материализовать детерминированные, всегда последовательные результаты запросов, не требуя тонкой координации между работниками и изоляции между их рабочими элементами.
Конструкция своевременного потока данных позволяет нашим рабочим потокам совместно использовать локальное состояние рабочего потока и вычисления в потоках данных. Это привносит концепцию базы данных общего индекса в мир потоковых вычислений, а вместе с ней и интерактивный анализ всегда свежих данных. Давайте рассмотрим пример того, как это работает.
В этом примере потока данных, взятом из нашего обзора выше, есть коллекция итогов, которая определяется запросом, который объединяет два входных сигнала и агрегирует результаты. Результатом является материализация результатов в памяти, «общая договоренность», выделенная выше оранжевым. Эта материализация индексируется любым ключом, который использовался для агрегации, возможно, SQL GROUP BY keys, и она постоянно поддерживается по мере изменения входных данных. Как и индекс базы данных, материализация обеспечивает произвольный доступ к ее данным и может значительно повысить производительность новых запросов, которые должны были бы повторно обрабатывать свои входные данные в других системах.
Если мы хотим использовать его в новом запросе, он готов к работе без необходимости повторной обработки каких-либо входных данных. Вы можете получить немедленный произвольный доступ к нему и настроить новые потоки данных, которые зависят от него, не перестраивая его для каждого потока данных.
Этот новый поток данных строится с использованием общего расположения в памяти, а не для повторного чтения (или, что еще хуже, повторного вычисления) коллекции итогов. Мы также повторно используем проделанную работу для поддержания договоренности по мере изменения базовых данных. Любое количество запросов может повторно использовать одну и ту же схему, и стоимость каждого запроса определяется только новой работой, которую он вводит.
Ключевая концепция 3 материализация результатов в общих механизмах обеспечивает низкую задержку запросов и ресурсоэффективность индексов реляционных баз данных при сохранении масштабируемой архитектуры систем параллельных потоков данных.
Конечно, в Materialize многое происходит, но эти три концепции торчали для меня в качестве основы для того, почему вы можете ожидать чего-то другого здесь. Они обеспечивают качественно иной опыт анализа данных, с быстрыми запросами, быстрыми обновлениями, и все это в том масштабе, который подходит именно вам.
Ограничения
Разумно задаться вопросом, каковы могут быть ограничения Materialize, учитывая его несколько преимуществ. Неофициально такая система, как Materialize, которая разделяет поддерживаемое состояние, оптимизируется для этого варианта использования больше, чем для других вариантов использования. Вычисления, которые не нуждаются в сохранении своих результатов, могут быть лучше реализованы путем опроса более традиционного процессора данных, выполняющего работу только по запросу. Вычисления, которые не нуждаются (или не ожидают) совместного использования состояния, могут лучше выполнять каждый запрос de novo, используя самую быструю возможную технологию чтения данных (например, столбчатые хранилища). Мы приложили все усилия к тому варианту использования, который, по нашему мнению, наиболее недостаточно обслуживается, эффективно поддерживая вычисления больших данных, и это происходит за счет того, что мы не создаем что-то еще.
Тем не менее, мы получили отличную реакцию от пользователей, которые сообщают, что сочетание интерактивного и всегда актуального анализа Materialize соответствует как их потребностям, так и ожиданиям. У нас здесь достаточно нового материала, чтобы нам было довольно комфортно откровенно говорить об ограничениях, так что возьмите его на спин и скажите нам, что вы думаете!
В Заключение
Materialize-это система, предназначенная для поддержания реляционных запросов к постоянно меняющимся данным. Он имеет ряд специфических преимуществ перед другими системами, которые делают его более подходящим для этой задачи. В частности, Materialize хорошо оснащена для поддержания индексированных представлений коллекций данных по мере их изменения и использования этих индексов при поддержании запросов к реляционным данным. Он сочетает преимущества индексов реляционных баз данных с масштабируемостью и производительностью потоковых процессоров. Все это со знакомым интерфейсом SQL, который работает так, как вы ожидаете.
Если вы хотите увидеть, насколько хорошо Materialize работает для вас, скачайте копию и попробуйте!
https://materialize.com/materialize-under-the-hood/
Загрузка...
