Лицевая обложка - f12a87a0b5fe4f8382918b93f042a313 - Unknown - RutLib.com

Книга: f12a87a0b5fe4f8382918b93f042a313

На главную: Предисловие

Дальше: Запросы к кластеру Presto

Анжелика Ло Дука, Тим Михан,

Вивек Бхаратан и Ин Су

Изучаем

и используем Presto

Angelica Lo Duca, Tim Meehan,

Vivek Bharathan, and Ying Su

Learning

and Operating Presto

Fast, Reliable SQL for Data Analytics

and Lakehouses

Beijing • Boston • Farnham • Sebastopol • Tokyo

Анжелика Ло Дука, Тим Михан,

Вивек Бхаратан и Ин Су

Изучаем

и используем Presto

Быстрый и надежный SQL-движок

для анализа данных

2024

УДК 004.65

ББК 32.972.134

Л68

Ло Дука А., Михан Т., Бхаратан В., Ин Су

Л68 Изучаем и используем Presto / пер. с англ. В. И. Комарова. – М.: Book.kz, 2024. – 182 с.: ил.

ISBN 978-6-01810-343-8

Данная книга посвящена Presto – распределенному SQL-движку с открытым

исходным кодом. Авторы объясняют, как появилась эта платформа и чем она отличается от других инструментов хранения и обработки данных. Вы научитесь

устанавливать и настраивать Presto, подключать его к различным источникам

данных, а также использовать Presto как источник данных для построения отчетов

и бизнес-аналитики. Кроме того, разберетесь с архитектурными концепциями

и типичными сценариями использования Presto.

Издание предназначено аналитикам, архитекторам данных, администраторам

и программистам, которые хотят научиться получать ценную информацию из

разрозненных наборов данных.

УДК 004.65

ББК 32.972.134

Authorized Russian translation of the English edition of Learning and Operating Presto ISBN

владельцев авторских прав.

ISBN 978-1-098-14185-1 (англ.)

ISBN 978-6-01810-343-8 (казах.)

язык, издание, Books.kz, 2024

Содержание

Глава 1.

Глава 2.

6  Содержание

Глава 3.

Глава 4.

Содержание  7

Глава 5.

Глава 6.

Глава 7.

8  Содержание

Глава 8.

Глава 9.

От издательства

Отзывы и пожелания

Мы всегда рады отзывам наших читателей. Расскажите нам, что вы ду маете

об этой книге – что понравилось или, может быть, не понравилось. Отзывы

важны для нас, чтобы выпускать книги, которые будут для вас максимально

полезны.

Вы можете написать отзыв на нашем сайте зайдя на

страницу книги и оставив комментарий в разделе «Отзывы и рецензии».

Также можно послать письмо главному редактору по адрес

том укажите название книги в теме письма.

Если вы являетесь экспертом в какой-либо области и заинтересованы в на-писании новой книги, заполните форму на нашем сайте по адресу

или напишите в издательство по адресу

Список опечаток

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

ошибку в одной из наших книг, мы будем очень благодарны, если вы сооб-щите о ней главному редактору по адресу Сделав это, вы избавите других читателей от недопонимания и поможете нам улучшить

последующие издания этой книги.

Нарушение авторских прав

Пиратство в интернете по-прежнему остается насущной проблемой. Издательство «ДМК Пресс» очень серьезно относится к вопросам защиты авторских прав

и лицензирования. Если вы столкнетесь в интернете с незаконной публикацией

какой-либо из наших книг, пожалуйста, пришлите нам ссылку на интернет-ресурс, чтобы мы могли применить санкции.

Ссылку на подозрительные материалы можно прислать по адресу элект-

ронной по.

Мы высоко ценим любую помощь по защите наших авторов, благодаря

которой мы можем предоставлять вам качественные материалы.

Предисловие

История хранилищ данных началась с того, что разработчики просто перено-сили данных из операционных баз данных в системы, более приспособленные для аналитики. Эксплуатация этих систем обходилась весьма недешево, и людям приходилось очень тщательно выбирать данные для загрузки.

С годами требования к объему обрабатываемых данных росли, значитель-но опережая рост производительности оборудования, описанный законом

Мура. Для традиционных аналитических систем анализ такого объема данных стал непосильной задачей. Рост требований коснулся всех, но некоторые

компании столкнулись с проблемами роста раньше остальных.

Facebook1 стал одной из первых компаний, попытавшихся в 2012 году решить проблему производительности аналитических платформ. В то время

в Facebook для интерактивной аналитики использовался Apache Hive. По

мере роста объема данных выяснилось, что Hive не такой уж интерактивный, а попросту говоря – медленный. Во многом это связано с тем, что Hive является частью экосистемы Hadoop, где главным инструментом исполнения запросов является фреймворк MapReduce. Главный его недостаток в том, что он

сохраняет промежуточные наборы данных на диске, что требует огромного

объема ввода-вывода. Facebook разработал новый движок распределенных

SQL-запросов – Presto, выполняющий промежуточные операции в памяти

и не требующий дискового ввода-вывода для хранения временных данных.

Такой подход позволил выполнять обработку данных на порядки быстрее: теперь многие запросы завершались в течение секунды. Пользователи –

инженеры, менеджеры и аналитики – обнаружили, что анализ снова стал

интерактивным и они могут выполнять множество запросов для проверки

гипотез и создания графиков и диаграмм.

Facebook был одной из первых, но далеко не единственной компанией, столкнувшейся с проблемой роста объемов данных, опережающего рост возможностей аппаратуры. Для решения этой проблемы была разработана архитектура «озера данных» (data lake), где обработка данных отделена от их

хранения. Такая архитектура позволила хранить данные в распределенных

файловых системах, построенных на базе дешевого оборудования, а поз-1 Социальная сеть Facebook принадлежит компании Meta, признанной в России экс-тремистской организацией. Здесь и далее торговая марка Facebook употребляется

исключительно в контексте созданных компанией технологий. – Прим. перев.

Предисловие  11

же – и в облачных хранилищах. Одновременно с дешевыми системами хранения развивались и вычислительные кластеры. Правда, очень долго было

непонятно, как должен быть устроен инструментарий для интерактивной

обработки данных. Часто, как в Facebook до 2012 года, аналитики пытались

использовать инструменты, предназначенные для пакетной обработки, производительность которых их не устраивала.

В 2013 году исходный код Presto был открыт. Платформа быстро завое-вала популярность и получила дополнительное развитие со стороны таких

компаний, как Airbnb, Uber и Netflix. Дело в том, что задачи, стоящие перед

аналитиками Facebook, не были уникальными – просто Facebook столкнулась

с ними раньше всех. Со временем потребность в интерактивных запросах

к озеру данных только росла. По мере роста использования росли и ожидания: пользователи требовали изоляции сеансов (то есть гарантии непро-тиворечивости результатов запросов при одновременно работающих ETL-процессах), эволюцию схемы данных, возможность запросов к предыдущим

версиям данных. Чтобы выполнить растущие требования, разработчикам

пришлось существенно изменить форматы таблиц. Они стали более сложными и функциональными, чем исходный формат Hive. Добавилась поддержка

транзакций (ACID) и индексов. Архитектура Presto также менялась под дей-ствием новых требований. В конце концов архитектура «хранилища-озера»

(lakehouse) стала отраслевым стандартом: дешевая распределенная система

хранения данных, как в традиционном «озере», с аналитическим движком, производительность которого не уступает производительности традиционных аналитических СУБД. Возможности хранилищ, построенных по такому

принципу, практически сравнялись с возможностями традиционных хранилищ, но «хранилища-озера» при этом не требуют сложных процедур загрузки

и преобразования данных (ETL).

Зачем мы написали эту книгу?

Развертывание Presto для построения традиционного хранилища данных

или «хранилища-озера» – весьма серьезное мероприятие. Чтобы все полу-чилось так, как задумано, вам необходимо понять правила, по которым работает Presto, и неукоснительно им следовать. Мы написали эту книгу, чтобы

рассказать вам об этих правилах и об инструментах, которые предоставляет

Presto, одна из самых мощных распределенных платформ анализа данных.

Вы не только поймете ее принципы, но и сможете развернуть и сконфигурировать собственную систему, воспользовавшись всеми преимуществами

платформы. Часть книги посвящена экосистеме, сформировавшейся вокруг

Presto, и способам интеграции Presto с другими популярными платформами

с открытым исходным кодом, например Apache Pinot или Apache Hudi. Эта

интеграция существенно расширит возможности вашей системы. Прочитав

нашу книгу, вы сможете глубоко разобраться в платформе Presto и использовать ее в текущем проекте и во всех последующих.

12  Предисловие

Для кого эта книга?

Эта книга – для тех, кто создает хранилище данных. Для программистов, администраторов, архитекторов, инженеров данных и облачных инженеров.

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

всех компонентов. Они решают вопросы очистки и дедупликации данных, выстраивают процессы управления данными, разрабатывают процедуры

преобразования данных, а также постоянно добавляют к системе новые инструменты и технологии, делающие ее удобнее и полезнее для конечного

пользователя.

Немного об оформлении

В этой книге используется ряд типографских приемов.

Курсивом

выделены новые термины, адреса веб-страниц и электронной почты, име-на файлов.

Моноширинный шрифт

используется для текстов программ, а также внутри обычного текста, чтобы выделить элементы программного кода – функции и переменные, типы

данных, переменные среды, команды и ключевые слова.

Такой элемент содержит подсказку или предложение.

Это общее замечание.

А так обозначается предупреждение или предостережение.

Использование примеров кода

Дополнительные материалы (исходный код, примеры, упражнения и т. д.) можно загрузить из репозитория на GitHub, созданного специально для этой

книги. Репозиторий находится по адресу

Если у вас возникли технические вопросы или проблемы с использовани-ем примеров кода, напишите письмо по адресу .

Мы написали эту книгу, чтобы помочь вам в работе. В большинстве случаев, если вы хотите использовать пример из этой книги в своей программе

или в документации (если только вы не воспроизводите значительную часть

Предисловие  13

кода), не нужно обращаться за специальным разрешением. Отдельное разрешение требуется, если вы хотите распространять или продавать примеры

из книг издательства O’Reilly. Цитирование книги, как и использование примеров кода, разрешения не требует.

Обычно мы не требуем указания авторства, но очень это ценим. Если вы хотите сослаться на книгу, следует указать ее название, автора, издателя и ISBN.

Например: Анжелика Ло Дука, Тим Михан, Вивек Бхаратан, Ин Су. Изуча ем

и используем Presto. М.: ДМК Пресс, 2024. ISBN 978-5-93700-294-5.

Благодарности

Эта книга является результатом работы многих людей, вклад каждого из

которых бесценен. Мы хотим сказать спасибо всем, кто поделился с нами

своим уникальным опытом и знаниями, кто заразил нас своей преданностью

делу, благодаря которой книга вышла такой удачной. Прежде всего мы хотели

бы выразить благодарность техническим рецензентам Чуньсю Тану (Chunxu Tang), Андреасу Кальтенбруннеру (Andreas Kaltenbrunner) и Скотту Хейнсу

(Scott Haines), которые нашли время, чтобы дать конструктивные отзывы.

Ваши замечания и предложения помогли значительно улучшить книгу, и мы

очень ценим вашу помощь.

Кроме того, мы искренне благодарим Вэнь Фана (Wen Phan), щедро поде-лившегося с нами своим опытом. Его знания и идеи значительно обогатили

книгу, особенно главу 5.

Мы также хотели бы выразить искреннюю благодарность редактору

O’Reilly Аарону Блэку (Aaron Black) за веру в концепцию этой книги и за

предоставленную нам возможность ее издать. Ваша помощь на протяжении

всего процесса работы над книгой была просто бесценна. Спасибо техниче-скому редактору Гэри О’Брайену (Gary O’Brien) за неизменную поддержку

и за стремление сделать эту книгу как можно лучше. Ваше внимание к деталям и содержательные предложения действительно очень помогли.

И особая благодарность всей команде O’Reilly за трудолюбие, профессио-нализм и энтузиазм. Пусть ваш неустанный труд часто был скрыт от посто-ронних глаз, но именно благодаря ему эта книга наконец увидела свет.

Анжелика Ло Дука

В первую очередь я благодарю своего мужа Андреа за его терпение и поддержку во время написания этой книги. Спасибо за наши долгие беседы, которые обеспечили мне душевный комфорт и подняли мотивацию. Сердечное

спасибо моим детям, которые проводили время за играми, пока я набирала

текст. Пока я писала свою книгу, они писали свою. И особая благодарность

Господу Богу Иисусу Христу за то, что дал мне возможность поделиться результатами своих занятий и исследований – ведь отдавать всегда приятнее, чем получать.

14  Предисловие

Тим Михан

Спасибо моей жене и сыну за их бесконечное терпение. Спасибо Гиришу

Баллиге (Girish Balliga) за его идеи и за руководство Фондом Presto. Спасибо

моим коллегам из Meta и IBM, в частности Джеймсу Сану (James Sun), Маше

Басмановой (Masha Basmanova), Стивену Миху (Steven Mih) и Али Леклерк

(Ali LeClerc), за дружбу, поддержку и вдохновение.

Вивек Бхаратан

Сердечное спасибо за вклад в эту книгу сообществу Presto. Спасибо за обсуж-дения, правки, идеи и многое другое. Особая благодарность Ретике Агравал

(Reetika Agrawal), Девешу Агравалу (Devesh Agrawal) и Рохану Педнекару (Ro-han Pednekar). Также не могу не отметить Али Леклерк (Ali LeClerc), чья помощь была просто неоценима. Спасибо Стивену Миху (Stephen Mih)1 и Дипти

Боркару (Dipti Borkar), которые буквально вели нас за собой. Спасибо Дэвиду

Симмену (David Simmen) за руководство и наставления. И наконец, спасибо

моей жене Прие и дочери Ракше, без поддержки которых эта работа была бы

просто невозможна.

Ин Су

Спасибо моим дорогим родителям, которые подарили мне бесконечную лю-бовь, заботу и поддержку. Спасибо Стивену Миху (Steven Mih), Дипти Боркару (Dipti Borkar)2 и Дэвиду Симмену (David Simmen) за их дальновидность, смелость, неустанную работу, огромное доверие и поддержку. Спасибо моим

коллегам из Ahana, IBM и Meta за нашу дружбу и за вдохновение.

1 Steven Mih и Stephen Mih – один и тот же человек, CTO компании Ahana. В сети

встречаются оба варианта написания имени. – Прим. перев.

2 В оригинале – Dipti Borker, но это ошибка. – Прим. перев.

Об авторах

Анжелика Ло Дука – исследователь со степенью доктора компьютерных

наук. Она работает в исследовательском подразделении Института инфор-матики и телематики при Национальном исследовательском совете Италии.

В сферу ее научных интересов входят подготовка и исследование данных, разработка веб-приложений, а также популяризация работы с данными

при помощи лекций и статей. Ряд ее работ связан с сетевой безопасностью, блокчейном и с развитием технологий публикации данных – семантической

паутиной и связанными данными. Кроме того, она является профессором

Пизанского университета, где преподаёт журналистику данных.

Тим Михан большую часть своей карьеры посвятил вопросам обработки

данных. Он работает над проектом Presto с 2018 года. В настоящее время

трудится в IBM и возглавляет технический комитет Presto. До IBM он работал

в таких компаниях, как Meta, Bloomberg, Goldman Sachs и других.

Вивек Бхаратан – соучредитель и главный инженер в компании Ahana, являющейся частью IBM. Ранее работал программистом в Uber, где управлял

кластерами Presto, состоявшими из более чем двух с половиной тысяч узлов

и обрабатывающими до 35 петабайт данных ежедневно, а также дорабатывал Presto, чтобы закрыть потребности Uber в интерактивной аналитике. До

прихода в Uber Вивек был одним из первых сотрудников команды по оптимизации запросов в Vertica Systems и внес значительный вклад в разработку

ядра Vertica и ее экосистемы, а его вклад в Presto включает в себя анализ час-тичных агрегаций. Ему принадлежит ряд алгоритмов для систем поддержки

принятия решений и логических рассуждений, которые он разрабатывал

в начале своей карьеры в Лаборатории исследований искусственного интеллекта. Вивек получил степень магистра компьютерных наук и инженерии

в Университете штата Огайо.

Ин Су – архитектор в компании Ahana, где она работает над повышени-ем производительности и эффективности сервисов на базе Presto и Velox.

В прошлом она работала над SQL Server в Microsoft и над Presto в Meta. Она

является коммиттером Presto и членом правления TSC.

Колофон

Животное на обложке этой книги – мабуя обыкновенная ( Mabuya mabouya).

Об этих ящерицах из семейства сцинковых известно не так уж много. Они –

эндемики Мартиники. Мабуи обитают на суше и покрыты кожей бронзового

цвета со светлыми полосками на верхней части туловища.

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

них нападают хищники, а потом в течение нескольких месяцев могут отрас-тить его заново – по крайней мере частично. Сцинки питаются в основном

насекомыми, такими как сверчки, жуки, гусеницы и мухи.

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

O’Reilly находятся под угрозой исчезновения, и очень важно их сохранить.

Иллюстрация на обложке принадлежит кисти Карен Монтгомери (Karen Montgomery) и написана по мотивам старинной гравюры из книги Pictorial Museum of Animated Nature.

Глава 1

Введение в Presto

В последние несколько лет растущий объем данных, как создаваемых пользователями, так и автоматически генерируемых, ставит новые задачи перед

организациями, желающими разобраться в этих данных для принятия более

эффективных решений. Чтобы находить новые идеи, видеть новые возможности и меняться в соответствии с требованиями времени, критически важно

ориентироваться именно на объективные данные. Появился даже новый

термин – «data-driven organization», буквально – «организация, управляемая

данными». Объем этих данных огромен, и их обработка требует значительных усилий, но полученные преимущества стоят затраченных усилий.

Данные извлекаются из разных источников в разных форматах, а для обращения к ним используются разные языки. Пользователи, пытающиеся

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

обработки. Эти требования заставили Facebook (теперь Meta), Airbnb, Uber, Netflix и другие компании переосмыслить методы управления данными. Постепенно они перешли от старой парадигмы хранилищ данных (warehouse) к парадигме хранилищ-озер (lakehouse). Если традиционное хранилище

данных содержит структурированные данные и историю их изменения, то

хранилище-озеро также может содержать и неструктурированные, и слабоструктурированные данные, обновляемые в режиме реального времени.

Presto – один из инструментов, решающих задачу обработки данных в хранилищах-озерах. Presto представляет собой распределенный движок SQL, созданный и используемый в Facebook. Вы можете легко интегрировать Presto в свое хранилище данных, чтобы эффективно выполнять SQL-запросы

независимо от физического местоположения и формата данных.

Эта глава познакомит вас с концепцией озера данных и расскажет, чем

оно отличается от классического хранилища данных. Вы узнаете, что такое

Presto, зачем этот движок был создан и почему его использует так много

компаний. Вы также ознакомитесь с наиболее популярными сценариями

применения Presto, такими как специальные (ad hoc) запросы, отчеты и информационные панели. Наконец, вы познакомитесь с хранилищем, которое

будет использоваться в качестве примера далее во всех главах.

18  Введение в Presto

Хранилища данных и озера данных

Все данные можно разделить на три вида: структурированные, слабоструктурированные и неструктурированные. В табл. 1.1 собрана информация о ви-дах данных: краткое описание, популярные форматы, достоинства и недостатки, а также примеры использования.

Таблица 1.1. Виды данных

Слабоструктури-

Неструктури-

Структурированные рованные

рованные

Описание

Структура данных

Данные

жестко зафиксиро-

структурированы,

не структурированы

вана

но единой схемы нет

Популярные SQL, CSV

JSON, XML

Аудио, видео, текст

форматы

Достоинства Легко извлекать

Более гибкий

Хорошо поддаются

информацию

и универсальный

масштабированию

подход, чем структури-

рованные данные

Недостатки Масштабирование

Метаданные

Сложно что-либо

ограничено структурой не структурированы

искать

Примеры

База данных

Текст с аннотациями,

Текст, цифровые

например твиты

фотографии

с хештегами

Разные классы хранилищ данных отличаются видами данных, которые

они способны хранить и обрабатывать. Так, традиционные хранилища данных

( data warehouse) – это централизованные системы, которые содержат только

структурированные данные и используются для аналитики и отчетности.

На рис. 1.1 изображена общая архитектура традиционного хранилища. Оно

состоит из четырех основных компонентов:

структурированные данные, собранные из разных источников, например из реляционных баз данных;

ETL – Extract, Transform, Load – процесс, приводящий данные к требу-емому формату;

слой детальных данных 1, содержит данные, готовые к использованию

конечными потребителями;

отчетность, информационные панели и интеллектуальный анализ данных. Верхний уровень – инструменты, использующие информацию из

хранилища, с которыми непосредственно работают пользователи.

1 В оригинальном тексте data warehouse является частью data warehouse. Термин

«слой детальных данных», detail data store (DDS), взят из других источников. –

Прим. перев.

Хранилища данных и озера данных  19

Отчетность

ETL

Хранилище

данных

Структурированные

Информационные

панели

данные

Data mining

Рис. 1.1  Общая архитектура традиционного хранилища данных

С появлением больших данных выяснилось, что хранилища, построен-ные по традиционной архитектуре, не справляются с требуемыми объемами.

Крупные компании, такие как Facebook, столкнулись с рядом проблем:

неструктурированные данные. Поскольку хранилища предназначены

для хранения и обработки структурированных данных, их нельзя ис-

пользовать для хранения таких данных, как текст или аудио. Прежде

чем записать эти данные в хранилище, их необходимо обработать;

масштабирование. С ростом объема данных стоимость и техническая

сложность традиционных хранилищ растет нелинейно;

предоставление данных в режиме реального времени. Традиционное

хранилище не способно предоставлять данные в режиме реального

времени, поскольку перед загрузкой данные должны быть обработаны

и преобразованы;

озеро данных решает эти проблемы. На рис. 1.2 показана общая архитектура озера данных.

В отличие от традиционного хранилища, озеро данных хранит структурированные, слабоструктурированные и неструктурированные данные

и предоставляет механизмы для их обработки и использования. Озеро может загружать сырые данные в режиме реального времени и затем хранить

их наряду с историческими данными. Со временем концепция озера эволю-ционировала в хранилище-озеро ( data lakehouse), включающее возможность

выполнения транзакций поверх озера данных. На практике хранилище-озеро изменяет данные в озере, следуя семантике традиционного хранилища.

Мы обсудим концепцию хранилища-озера и разработаем такое хранилище

в главе 5.

Поначалу озера данных располагались целиком на оборудовании компа-

ний, которым они принадлежали ( on-premise data lakes). Их главным пре-имуществом был полный контроль системы компанией-владельцем. С по-

явлением облачных вычислений озера данных постепенно переместились

20  Введение в Presto

в облака, где вопросы управления, обслуживания и безопасности решаются

инженерами компании-провайдера. Разумеется, клиенты разделяют с облачными провайдерами ответственность за безопасность данных. Такой подход называется облачным озером данных, и его популярность непрерывно растет. Основные игроки на этом рынке – Amazon Web Service (AWS), Microsoft Azure и Google Cloud, а наиболее популярной инфраструктурой для хранения

данных стало объектное хранилище 1 .

Структурированные

данные

Отчетность

Метаданные

Озеро данных

и подсистема

Слабоструктури

управления

рованные данные

Информационные

панели

Неструктури

рованные данные

Data mining

Рис. 1.2  Общая архитектура озера данных

Чтобы обеспечить доступ инструментам верхнего уровня (отчетность, информационные панели, инструменты интеллектуального анализа) к данным, в озере есть промежуточный уровень, называемый уровнем управления и метаданных ( metadata and governance), который обеспечивает согласованность

данных и управление доступом.

Роль Presto в озере данных

Presto – это распределенный движок SQL с открытым исходным кодом, который поддерживает в качестве источников как структурированные, так и слабоструктурированные данные. Вы можете использовать Presto для обращения к данным вне зависимости от того, где они находятся, что удобно для

подключения к хранилищу-озеру. Для выполнения запроса нет необходимости перемещать данные. Запросы в Presto выполняются параллельно, что

позволяет масштабировать эту платформу, а выполнение запросов в памяти

обеспечивает высокую скорость.

1 Имеется в виду сервис S3, simple storage service, впервые предложенный в 2006 году

компанией Amazon. – Прим. перев.

Происхождение и истоки архитектуры Presto  21

Узел-координатор анализирует SQL-запрос (поддерживается стандарт

ANSI SQL1), составляет план запроса, раздает задания рабочим узлам, непосредственно работающим с источниками данных, а затем возвращает пользователю результат запроса. В зависимости от сложности запроса план может

содержать разное, иногда большое количество шагов. Например, если запрос

выполняет соединение нескольких больших таблиц, ему может понадобиться

несколько проходов, агрегирующих данные. Вы можете воспринимать эти

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

Происхождение и истоки архитектуры

Presto

Разработка Presto началась в компании Facebook в 2012 году. Целью было

избавление от недостатков Apache Hive – распределенного SQL-движка, раз-работанного на фреймворке MapReduce в Hadoop. Одно из хранилищ данных

Facebook было построено как раз на базе Apache Hive, и главной претензией

пользователей к хранилищу была низкая скорость выполнения запросов над

большими объемами данных.

Apache Hive

Apache Hive также был разработан в Facebook в 2010 году, и его код тоже был открыт.

В основе Apache Hive, как и в основе других платформ в экосистеме Hadoop, лежит

фреймворк MapReduce, предусматривающий запись промежуточных результатов выполнения запроса на диск. Такая архитектура требует частого доступа к диску и большого объема ввода-вывода.

Presto, новый распределенный SQL-движок, был призван решить эту

проблему за счет обработки данных в памяти. У него не было потребности

в массивном вводе-выводе, и в результате запросы стали выполняться на

несколько порядков быстрее. Время выполнения многих запросов теперь не

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

Рисунок 1.3 показывает, как выполняют запросы Presto и Hive. Hive использует фреймворк MapReduce, который записывает на диск промежуточные результаты как после фазы Map, так и после фазы Reduce. В отличие от

него, Presto экономит время за счет сокращения ввода-вывода: все операции

выполняются в памяти рабочих узлов.

1 В книге не указана версия стандарта, которую поддерживает Presto. Обычно под

ANSI SQL понимают стандарт SQL92, но на самом деле стандарт живет и развивается, и последняя на момент перевода версия – SQL:2023 (ISO/IEC 9075:2023). – Прим.

перев.

22  Введение в Presto

Hive

Presto

Reduce

Задача

Этапы образуют

конвейер

• Нет ожидания

Диск

между этапами

• Не обеспечива

каждого этапа

ется отказо

Ожидание окончания

устойчивость

Map

Задача

Диск

Reduce

Задача

Данные передаются

из памяти одного

процесса в память

Диск

Запись

другого

промежу

• Нет дискового

точных

вводавывода

данных

• Данные должны

Map

на диск

Задача

помещаться

в оперативную

память

Рис. 1.3  Как Hive и Presto выполняют запросы

В 2013 году Facebook открыл исходный код Presto под лицензией Apache 2.0

и выложил репозиторий на GitHub. Позже Facebook спонсировал проект, передав его под управление Фонда Linux (Linux Foundation), который в свою

очередь основал дочернюю организацию – фонд Presto (Presto Foundation).

Создатели Presto ставили перед собой следующие цели: высокая производительность, легкое масштабирование, соответствие стандарту ANSI SQL, объединение разрозненных данных и возможность запуска в облаке.

Высокая производительность

В оптимизаторе Presto реализовано множество правил, включая такие хорошо известные приемы, как проталкивание предикатов, исключение колонок, оптимизация коррелированных подзапросов. Сложный алгоритм в зависимости от возможностей конкретного источника выбирает, какие операции

можно выполнить прямо на источнике. Например, СУБД могут самостоятельно выполнять фильтрацию, агрегацию, вычисление функций и т. д. Осу-ществляя эти операции максимально близко к данным, Presto существенно

сокращает объем ввода-вывода и сетевой трафик. Часть запроса, например

соединение данных из разных источников, выполняется непосредственно

самим Presto.

Происхождение и истоки архитектуры Presto  23

Масштабирование

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

этом для первоначального запуска какая-то мощная инфраструктура вовсе

не требуется. Прежде чем обрабатывать действительно большие наборы данных, вы можете разработать прототип вашей системы, используя маленькие

инсталляции. Благодаря быстрому отклику платформы накладные расходы

даже на запуск множества мелких запросов невелики.

Соответствие стандарту ANSI SQL

Синтаксис запросов Presto строго придерживается стандартов ANSI SQL. Поскольку большинство пользователей уже знают SQL, использование Presto не требует изучения нового языка. Практически все сценарии применения

доступны прямо «из коробки».

Что значит «соответствует стандарту ANSI SQL»

Это значит, что такие команды, как SELECT, UPDATE, DELETE, INSERT и JOIN1, в большинстве

случаев делают именно то, что от них ожидается.

Объединение данных

Presto – это федеративный SQL-движок ( federated SQL-engine), позволяющий

запрашивать данные как из одного источника, так и из нескольких источников, в том числе и разнородных.

Для доступа к данным Presto использует коннекторы, позволяющие читать

данные из разных источников и даже записывать их туда. Коннекторы для

многих популярных баз данных и форматов уже написаны и доступны «из

коробки».

Федеративные запросы

Федеративным запросом называется запрос, извлекающий данные из нескольких

разнородных источников. Федеративный подход противопоставляется централизо-ванному подходу, при котором данные перед обработкой должны быть сохранены

в едином физическом формате. Presto изначально разработан для выполнения федеративных запросов.

На рис. 1.4 изображены базовые шаги, осуществляемые движком в про-

цессе выполнения федеративного запроса2. Получив запрос, движок раз-1 В книге JOIN указывается именно как отдельная команда, хотя в стандарте SQL это

только одна из частей команды SELECT. – Прим. перев.

2 Kemele M. Endris, Maria-Esther Vidal, and Damien Graux, “Chapter 5, Federated Query Processing,” in Knowledge Graphs and Big Data Processing, ed. Valentina Janev, Damien Graux, Hajira Jabeen, and Emanuel Sallinger (Springer, 2020),

24  Введение в Presto

бирает его ( стадия разбора, query parsing) и выбирает один или несколько

источников, данные из которых потребуются для выполнения запроса ( выбор

источников, data source selection). В результате этого шага запрос разбивается

на подзапросы.

Запрос

Результат

Разбор запроса

Окончательная

обработка данных

Выбор источника

Оптимизация

Выполнение

данных

запроса

Каталог

источников

Источники данных

Рис. 1.4  Базовые шаги

при обработке федеративного запроса

На следующем шаге строится логический план ( оптимизация, query optimization), определяющий алгоритм выполнения запроса и набор операций

(JOIN, UNION, FILTER и т. д.), которые будут использованы. Как правило, план

представляется в виде дерева ( tree-based plan), листья которого соответству-ют подзапросам, а внутренние узлы представляют собой операции, которые

будут выполнены самим движком.

После построения плана запроса наступает стадия выполнения ( query execution)1, во время которой подзапросы непосредственно выполняются, а затем их результаты приводятся к единому формату ( query reconciliation) и из них собирается общий результат запроса.

1 Авторы используют также термин «физический план» (physical plan) как синоним

исполнения. – Прим. перев.

Архитектура Presto и его ключевые компоненты  25

Запуск в облаке

Вы можете как запустить Presto в кластере, развернутом на собственной ин-фраструктуре вашей компании, так и воспользоваться каким-либо облачным

сервисом. Есть множество услуг на базе Apache Presto, например Amazon Elastic MapReduce (EMR) или Google Dataproc. Другие поставщики облачных

услуг, скажем IBM, предлагают Presto в составе платформы для построения

озера данных. Облачные сервисы позволяют быстро развернуть несколько

кластеров Presto для разных сценариев использования.

Архитектура Presto и его ключевые

компоненты

На рис. 1.5 изображена архитектура Presto. Платформа развернута в виде

двух сервисов – координатора, единственного на всю инсталляцию, и множества рабочих узлов. Координатор – это «мозг» платформы. Он принимает

запросы от клиентов, разбирает их, строит планы выполнения и распределяет задачи между рабочими узлами. Координатор состоит из трех основных

компонентов: модуля разбора (parser), оптимизатора (planner) и организа-тора (scheduler).

Узел-координатор

Модуль разбора Оптимизатор

(parser)

(planner)

JDBCклиент

Организатор

(scheduler)

Рабочий узел

Внешний

источник

данных A

данных B

Рис. 1.5  Архитектура Presto

Все рабочие узлы выполняют задания параллельно, и если их мощности

недостаточно, вы в любой момент можете добавить к кластеру нужное коли-

26  Введение в Presto

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

каталогов (источников).

Вы можете сконфигурировать Presto одним из трех способов:

единственный источник данных. Пользователи такой инсталляции могут выполнять запросы к единственному источнику. В этом случае

Presto представляет собой обычный SQL-движок, построенный поверх

некого каталога данных, использующий его метаданные и позволяю-

щий обращаться к нему при помощи SQL;

несколько источников данных, опрашиваемых независимо. В данном случае пользователь видит множество источников, над каждым из кото-

рых установлен SQL-движок. Пользователь по-прежнему в запросе мо-

жет обращаться только к одному источнику, но разные запросы могут

обращаться к разным источникам. Для обращения ко всем источникам

применяется один и тот же интерфейс, что позволяет пользователю

выполнять все запросы единообразно и не думать о различиях между

источниками;

несколько источников данных, допускающих совместное использование.

Следующим шагом на пути к федерации данных является возможность

в каждом запросе использовать данные двух или более источников.

В такой конфигурации пользователи могут совместно анализировать

любые данные без необходимости перемещать их в единое хранилище.

Достоинства каждой конфигурации сведены в табл. 1.2. Если у вас единственный источник данных, то Presto просто обеспечивает быстрое выполнение аналитических запросов. Если источников данных много, то Presto вдобавок обеспечивает федеративный доступ. И наконец, если разрешен

одновременный доступ к разным источникам, то аналитика не только фе-деративная, но и унифицированная.

Таблица 1.2. Возможности, предоставляемые разными конфигурациями Presto

Быстрое

исполнение Федеративная Унифицированная

Конфигурация

запросов

аналитика

Единственный источник

–

Несколько независимых

–

источников

Совместное использование +

источников

Альтернативы Presto

Существует множество платформ, решающих те же задачи, что и Presto. Задачу построения быстрого масштабируемого распределенного движка для

выполнения аналитических запросов, способных обрабатывать огромные

Альтернативы Presto  27

объемы данных, решал не один коллектив разработчиков. Поскольку объем

данных, с которыми приходится работать современным компаниям, постоянно растет, такие решения, как Presto и его аналоги, неизменно пользуются

высоким спросом.

Apache Impala

Apache Impala – распределенный движок для выполнения SQL-запросов

в экосистеме Hadoop, разработанный в компании Cloudera. Может быть развернут, например, в облаке Amazon или в составе платформы MapR. Хорошо

показывает себя в запросах к наборам данных среднего объема. К недостат-кам можно отнести отсутствие поддержки некоторых операторов SQL, например UPDATE и DELETE.

Apache Hive

Apache Hive – платформа для обработки больших данных, поддерживающая

SQL. Hive также работает в экосистеме Haddop. Поддерживает множество

форматов данных – текстовые файлы, разделенные запятыми или табуля-циями, Apache Parquet и другие. Позволяет подключать дополнительные

коннекторы для поддержки других форматов. Hive можно использовать совместно с Presto.

Spark SQL

Spark SQL – это модуль Apache Spark, поддерживающий структурированные

данные. Spark SQL – тоже распределенный SQL-движок, который можно использовать совместно с остальными модулями Apache Spark.

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

Presto использует конвейеризацию, при которой следующий шаг не ждет завершения

предыдущего, а вместо этого начинает работу, как только предыдущий шаг выдает

первые результаты.

Trino

Когда основатели Presto покинули Facebook в 2018 году, у оригинального

проекта (которому и посвящена эта книга) появилось ответвление (форк) –

PrestoSQL. В 2021 году этот новый проект был переименован в Trino.

28  Введение в Presto

Так же, как и Presto, Trino способна быстро выполнять федеративные запросы без копирования и перемещения данных из источников во временное

хранилище.

Сценарии использования Presto

Изначально платформа Presto была разработана для интерактивной аналитики и выполнения специальных запросов. Постепенно платформа разви-валась, а возможности получения данных, включая обновление в реальном

времени, расширялись. Соответственно, росло и количество сценариев использования Presto. В этом разделе рассмотрим самые популярные сценарии.

Отчетность и информационные панели

В отличие от ранних статичных таблиц и графиков, современные отчеты

и информационные панели должны быть интерактивными. Их пользовате-

ли – аналитики, инженеры, менеджеры по продуктам, маркетологи и прочие – хотят не просто видеть значения ключевых показателей эффективности

(и другие значения – статистических показателей, показателей телеметрии

и т. д.), но и получить более глубокую аналитику по отдельным цифрам, вы-зывающим наибольший интерес.

Presto предоставляет конечным пользователям возможность самостоятельно запрашивать данные из разных источников и не зависеть от разработчиков

хранилища. Задача самих разработчиков также значительно упрощается –

ведь теперь у них есть единая точка доступа к данным для инструментов подготовки отчетности, например Tableau, Graphana, Apache Superset и других.

Специальные (ad hoc) запросы

Пользователи могут заниматься тонкой настройкой своих запросов – либо

вручную дописывая SQL, либо используя один из многочисленных инструментов визуализации или бизнес-аналитики. Кластер Presto способен одновременно выполнять множество сложных запросов над данными, расположенными

где угодно. С таким инструментом пользователи могут мгновенно проверять

свои гипотезы или же строить сложные отчеты, постепенно выполняя все более

сложные запросы и с каждой итерацией приближаясь к желаемому результату.

Извлечение и загрузка данных с использованием SQL

При помощи Presto аналитики могут запускать эффективные ETL-процессы

(extract, transform, load – извлечение, преобразование и загрузка). Presto

Сценарии использования Presto  29

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

пропускной способностью.

Запуск ETL-процессов в пакетном режиме требует гораздо больших затрат

процессорного времени и дискового пространства, чем последовательность

интерактивных задач1. Поскольку вместе с объемом данных растет и мощность кластеров для их обработки, некоторые компании делят кластеры Presto на две группы: кластеры первой группы используются для ETL-процессов, а кластеры второй – для выполнения пользовательских запросов. С точки

зрения эксплуатации использование одного и того же инструмента для разных задач выгодно, поскольку требует от администраторов одних и тех же

навыков.

ETL и ELT

В разных источниках вам могут встретиться две разные аббревиатуры: ETL (extract, transform, load) и ELT (extract, load, transform). Несмотря на то что они обозначают

один и тот же набор операций, сами процессы отличаются друг от друга. Разница даже

не в порядке выполнения отдельных операций – обычно все они выполняются параллельно. Главное отличие заключается в том, где именно выполняется преобразование

данных. В ETL-процессах преобразования выполняются в специальной области для

подготовки данных (staging area), а в ELT-процессах – непосредственно в хранилище

данных.

Хранилище-озеро

Озеро данных позволяет сохранять любые данные, как структурированные, так и неструктурированные, и выполнять над этими данными аналитические запросы. Хранилище-озеро допускает как SQL-запросы, так и запросы

других видов, например разные методы машинного обучения на неструктурированных данных. В качестве движка SQL-запросов прекрасно подойдет

Presto, позволяющий выполнять запросы над данными, не перемещая и не

преобразуя их.

Аналитика в реальном времени

Аналитика в реальном времени обычно предполагает объединение самых

свежих данных, собираемых в режиме реального времени, с исторически-ми или архивными данными. Представьте, например, что вам требуется

анализировать транзакции интернет-магазина. Завершенные транзакции

хранятся в одном месте, например в распределенном хранилище S3, а актуальная информация, включая содержимое корзин, – в другом, например

в базе Apache Pinot. Мало того, текущие транзакции тоже завершаются, и ин-1 Весьма спорное утверждение. – Прим. перев.

30  Введение в Presto

формация о них перемещается из одного хранилища в другое, например

фоновым процессом через равные промежутки времени.

Используя Presto для объединения данных из обоих источников и анали-зируя полную информацию, вы можете получать маркетинговые сигналы или

предупреждения о возможном мошенничестве в режиме реального времени.

Введение в модельное хранилище

Presto может быть использован в самых разных сценариях, включая задачи

интеллектуального анализа данных и мониторинга в реальном времени, а также высокопроизводительные системы отчетности. Для демонстрации

возможностей Presto мы создали модельное хранилище данных, которое

будем использовать на протяжении всей книги, где только это возможно.

Представьте себе, что у вас есть доступ к хранилищу данных компании-дистрибьютора, распространяющей по всему миру самые разные товары –

книги, одежду и многое другое. Для моделирования такого хранилища мы

будем использовать базу данных для теста TPC-H (Transaction Processing Per-formance Council Benchmark H), которая замечательно подходит для Presto.

Схема базы данных TPC-H1, состоящей из восьми таблиц, изображена на

рис. 1.6. Стрелки на схеме показывают связи (внешние ключи) между таблицами. База для теста TPC-H представляет собой хранилище некой абст-рактной компании. Подобные базы с разными объемами данных широко

используются в целях тестирования.

Partsupp

Строка заказа

(lineitem)

Деталь (part)

Клиент

(customer)

Заказ (order)

Поставщик

(supplier)

Страна

Регион

(nation)

(region)

Рис. 1.6  Схема базы данных TPC-H

На рис. 1.7 представлена архитектура нашего хранилища. Данные поступают из двух источников:

актуальная информация о клиентских транзакциях. Информация о клиентских транзакциях, получаемая в режиме реального времени. При-

мер такой информации – содержимое корзины;

продуктовый каталог. Информация о продуктах, которыми торгует

компания.

Заключение  31

Текущие

Загрузка

операции

операционных

клиентов

данных

Отчетность

Архивные операции

Presto DB

Текущие операции

Информационные

панели

Каталог

продуктов

Справочники

Озеро данных

Data mining

Рис. 1.7  Архитектура модельного хранилища

Данные из обоих источников поступают в хранилище. Периодически исто-рическая информация о клиентских транзакциях перемещается в архив –

специально выделенный сегмент озера данных. Presto обращается ко всем

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

Заключение

Из этой главы вы узнали, что такое Presto и какую роль эта платформа играет

в озерах данных. Presto представляет собой распределенный движок для выполнения SQL-запросов над всеми видами данных – структурированными, слабоструктурированными и неструктурированными. При помощи Presto вы можете выполнять запросы, написанные на стандартном ANSI SQL, над

большими объемами любых данных. Presto обеспечивает высокую производительность и легкое масштабирование, а также может быть развернут

в облаке.

Вы узнали базовые концепции, лежащие в основе Presto, включая архитектуру платформы, подход к выполнению федеративных запросов и типичные

сценарии использования. И теперь вы готовы сделать следующий шаг – развернуть собственную копию Presto и выполнить на ней первый запрос.

В главе 2 мы расскажем, как установить и запустить Presto. Упор будет сделан на развертывание в виде Docker-образов с использованием оркестратора

контейнеров Kubernetes.

Глава 2

Первые шаги

в освоении Presto

Есть несколько способов развертывания Presto. Сначала мы немного поговорим о том, как установить Presto вручную, но подробно обсуждать этот

способ не будем. Наша цель – развернуть локально кластер Presto, поскольку

именно кластеры используются в промышленных инсталляциях.

Вы научитесь запускать экземпляр Presto в Docker-контейнере и разворачивать локальный кластер с использованием Kubernetes. Закончив установку, вы сможете выполнить в Presto первые запросы. Особенно подробно мы

остановимся на том, как получить список каталогов и схем и как написать

запрос к таблице.

Мы подразумеваем, что у вас уже есть некоторый опыт работы в командной строке, а также опыт использования Docker и Kubernetes. Если это не так, просто в точности следуйте инструкциям от начала до конца, и к концу главы

вы получите работающий кластер.

Установка Presto вручную

Для установки Presto вы можете просто следовать процедуре, описанной

в официальной документации1. Поскольку код Presto написан на языке Java, обратите внимание, чтобы у вас была установлена подходящая версия JRE

(Java Runtime Environment). Presto требует Java 8 и поддерживает как Oracle JDK, так и OpenJDK.

Запуск Presto в Docker

Локальный экземпляр Presto отлично подходит для разработки и отладки.

Вы можете настроить полноценный кластер из нескольких узлов, разверну-1

Запуск Presto в Docker  33

тых на физических или виртуальных машинах. Не забудьте только, что вам

придется самостоятельно настроить мониторинг кластера, обеспечить его

доступность и масштабирование. И вот тут-то вам пригодятся контейнеры

и Kubernetes.

В этом разделе мы установим и запустим Presto в контейнере Docker, а в следующем из того же самого образа создадим при помощи Kubernetes полноценный кластер, практически ничем не отличающийся от тех кластеров, которые используются в промышленных средах.

Запуск Presto в Docker может быть полезен, когда вам нужен единственный

узел без сопутствующей инфраструктуры. Если же вам нужна более сложная

конфигурация, например вы хотите подключить Apache Ranger для управления

доступом, то гораздо удобнее создать такую конфигурацию при помощи Kubernetes. Нам понадобится образ Presto как основа нашего кластера, а для развертывания полного набора компонентов мы будем использовать Kubernetes.

Установка Docker

Чтобы запускать контейнеры, вам необходимо установить Docker на свой

компьютер. Весь код, приведенный в этой книге, был протестирован в Docker 4.2.0, но и более свежие версии также должны работать. Docker требует как

минимум 4 Гбайт оперативной памяти, но для запуска Presto мы рекомендуем как минимум 8 Гбайт. В Windows или MacOS вы можете использовать

Docker Desktop1, а в Linux – Docker Engine2.

В ходе выполнения упражнений из этой книги вы будете сами собирать все

необходимые контейнеры. Однако это требуется не всегда – готовые образы

можно просто скачивать из Docker registry или какого-либо альтернативного

хранилища образов, например Amazon ECR, командой docker pull. Более того, вы можете публиковать и свои образы – для этого подключиться к хранилищу командой docker login.

Образ Presto

Начнем с того, что склонируем репозиторий Presto (если только вы до сих

пор не сделали этого):

git clone https://github.com/alod83/Learning-and-Operating-Prest\o.git Код, приведенный в этом разделе, можно взять в папке3 02/presto-docker.

Помимо файла README.md, содержащего краткую инструкцию, в ней находятся следующие файлы:

3 Поскольку термин каталог (catalog) используется для обозначения источника данных Presto, для обозначения каталога файловой системы будем использовать термин «папка». – Прим. перев.

34  Первые шаги в освоении Presto

Dockerfile – конфигурационный файл для Docker, используемый при

сборке образа;

etc/ – папка, содержащая конфигурационные файлы для Presto.

Остаток раздела мы посвятим разбору файла Dockerfile и содержимого папки /etc, изменение которых позволит нам сконфигурировать инсталляцию

Presto по своему вкусу. Если вас устраивает конфигурация по умолчанию, вы

можете пропустить текст до раздела «Сборка и запуск Presto».

Dockerfile

Образ Presto, описанный в Dockerfile, базируется на CentOS 7. Он содержит сер-верную и клиентскую части Presto, а также необходимые зависимости и ряд

вспомогательных инструментов. Давайте разберем содержимое этого файла.

Первая строка определяет базовый образ. Затем идет описание параметров, определяющих версию Presto, которую требуется загрузить, а также URL, по которым находятся серверная и клиентская части:

FROM centos:7

ARG PRESTO_VERSION

ARG PRESTO_BIN=https://repo1.maven.org/maven2/com/\

facebook/presto/presto-server/${PRESTO_VERSION}/\

presto-server-${PRESTO_VERSION}.tar.gz

ARG PRESTO_CLI_BIN=https://repo1.maven.org/maven2/com/\

facebook/presto/presto-cli/${PRESTO_VERSION}/\

presto-cli-${PRESTO_VERSION}-executable.jar

Установка CentOS на компьютерах с процессором ARM

Если ваш компьютер построен на процессоре ARM (как, например, современные но-утбуки Apple), процесс сборки образа завершится с ошибкой. Для решения этой проблемы, во-первых, укажите в качестве базового образа amd64/centos:7, а во-вторых, запускайте Docker с флагом --platform linux/amd64. Подробности – далее в этой главе.

Следующие шаги загружают системное программное обеспечение (серти-

фикаты удостоверяющих центров, используемые для проверки сертификатов серверов и JDK), необходимое для установки Presto, а затем удаляет кеш

пакетов, чтобы уменьшить размер образа:

RUN yum update -y &&\

yum install -y wget ca-certificates tar less &&\

yum install -y java-1.8.0-openjdk &\

yum clean all

Затем создается папка /opt, куда будет установлен Presto, а после этого

загружаются файлы клиентской и серверной частей Presto, которые поме-щаются в созданную папку1:

1 Каждый вызов RUN создает свой «слой» в файловой системе Docker, что приводит

к увеличению объема полученного образа. Общепринятая практика состоит в выполнении всего набора команд единственным вызовом RUN, в котором команды

разделены символами &&, – этот подход продемонстрирован в последних трех стро-ках. – Прим. перев.

Запуск Presto в Docker  35

RUN mkdir -p /opt

RUN wget --quiet ${PRESTO_BIN}

RUN tar -xf presto-server-${PRESTO_VERSION}.tar.gz -C /opt

RUN rm presto-server-${PRESTO_VERSION}.tar.gz

RUN ln -s /opt/presto-server-${PRESTO_VERSION} /opt/presto

RUN wget --quiet "${PRESTO_CLI_BIN}"

RUN mv presto-cli-${PRESTO_VERSION}-executable.jar /usr/local/bin/presto RUN chmod +x /usr/local/bin/presto && \

mkdir /opt/presto/data && \

mkdir /opt/presto/log

Теперь копируем содержимое папки etc/ в локальную файловую систему

Docker-образа:

COPY etc /opt/presto/etc

Монтирование локальной папки в Docker-контейнере

Поскольку вы копируете настройки командой COPY etc /opt/presto/etc, изменение

каких-либо параметров в локальной копии папки etc/ потребует повторной сборки

образа. Вы можете убрать команду копирования из сценария сборки и монтировать

в контейнере локальную папку. Это делается во время запуска образа добавлением

в командную строку Docker опции -v <source_path>:<dest_path>.

Наконец, последняя строка содержит команду, запускающую Presto при

старте контейнера:

CMD ["/opt/presto/bin/launcher", "run"]

Папка etc/

Папка etc/ содержит конфигурационные файлы Presto. В этом разделе мы

разберемся, как сконфигурировать Presto для локального запуска. Наш кластер будет состоять из координатора и единственного рабочего узла. В разделе

«Сборка и запуск Presto» вы узнаете, как создать промышленную конфигурацию. Для того чтобы познакомиться с Presto и начать работу, текущей

конфигурации будет вполне достаточно.

В папке etc/ находятся следующие файлы и дочерние папки:

node.properties;

jvm.config;

config.properties;

log.properties;

catalog/.

Вы можете использовать эти файлы как есть или попытаться изменить их, чтобы изменить настройки Presto под свои задачи. Далее мы детально рассмотрим содержимое каждого файла.

node.properties

Узел (node) – это экземпляр Presto, и этот файл содержит настройки, специ-фичные для узла. Пример ниже показывает минимальные настройки, которые должны быть определены в файле node.properties:

36  Первые шаги в освоении Presto

node.environment=presto_local

node.id=1a674699-500c-414c-b480-9ac0df416403

node.data-dir=data

Минимальные настройки включают:

node.environment

Эта переменная содержит имя среды (кластера). У всех узлов кластера

значение этой переменной должно быть одинаково.

node.id

Идентификатор узла. Каждый узел в кластере должен иметь уникальный

идентификатор1, который должен оставаться неизменным в течение всего

жизненного цикла узла, включая перезагрузки и обновления программно-го обеспечения. В качестве идентификатора вы можете использовать UUID

(universally unique identifier).

node.data-dir

Указывает папку, где Presto будет хранить журналы и другие данные.

jvm.config

Поскольку Presto написан на языке Java, он запускается в виртуальной машине (JVM), и этот файл содержит параметры запуска виртуальной машины.

Для начала мы используем следующие параметры:

-server

-Xms3G

-Xmx3G

-Djdk.attach.allowAttachSelf=true

Параметр -server выбирает виртуальную машину HotSpot2. Параметр

-Xms3G выделяет при старте 3 Гбайта памяти, а параметр -Xmx3G сообщает, что 3 Гбайта – это максимальный объем памяти, доступный виртуальной

машине. Таким образом динамическое выделение памяти запрещается. Параметр -Djdk.attach.allowAttachSelf=true нужен, чтобы избежать ошибок при

запуске, позволив загрузиться библиотечным классам3.

1 В книге вводится понятие «инсталляции» (installation) и указывается, что у всех

узлов в рамках инсталляции должен быть одинаковый node.id, однако это

противоречит документации Presto, доступной по адресу . – Прим.

перев.

2 JRE может поддерживать несколько разных виртуальных машин Java. HotSpot JVM

при запуске выполняет более сложную компиляцию (JIT, just-in-time compilation), что ведет к большей задержке при запуске, но более эффективному выполнению

кода. 64-битная Oracle JRE не поддерживает других виртуальных машин, кроме

HotSpot, поэтому в этой среде запуск с параметром -server и без него ничем не

отличается. – Прим. перев.

3 Флаг исправляет работу библиотек, неправильно использующих Java attach API, изменившийся при переходе с Java 8 на Java 9. Ошибка зафиксирована под именем

JDK-8180425. – Прим. перев.

Запуск Presto в Docker  37

Более детально содержимое этого файла мы разберем в главе 6 «Администрирование Presto».

config.properties

Этот файл используется для конфигурации узла Presto. Узел может играть

роль координатора, рабочего узла или обе роли одновременно. Для нашего

локального координатора мы будем использовать следующие настройки: coordinator=true

node-scheduler.include-coordinator=true

http-server.http.port=8080

memory.heap-headroom-per-node=0.5GB

query.max-memory=1GB

query.max-memory-per-node=0.5GB

query.max-total-memory-per-node=2GB

discovery-server.enabled=true

discovery.uri=http://localhost:8080

Разберем значение каждого параметра:

coordinator. Если значение установлено в true, то узел может принимать запросы от пользователей и управлять установленными соеди-

нениями;

node-scheduler.include-coordinator. Установив этот параметр в true, вы

запускаете на узле-координаторе организатор (scheduler). Обычно

в промышленных средах этот параметр устанавливается в false, чтобы

управление клиентскими подключениями и управление выполнением

запросов не конкурировали между собой за ресурсы узла. Подробнее

управление запросами рассмотрим в главе 3 «Коннекторы»;

http-server.http.port. Порт, используемый как для межузловых, так

и для внешних соединений по протоколу HTTP;

query.max-memory. Максимальный объем памяти, которую запрос может

использовать во время выполнения. Ограничение относится ко всему

кластеру. Если запрос требует больше памяти, то Presto автоматически

прерывает его выполнение;

query.max-memory-per-node. Максимальный объем пользовательской области памяти, который запрос может использовать на каждом рабочем

узле. Если хотя бы на одном узле объем пользовательской области памяти выходит за этот лимит, Presto автоматически прерывает выпол-

нение запроса;

query.max-total-memory-per-node. Максимальный общий объем памяти, который запрос может использовать на каждом рабочем узле. Если хотя

бы на одном узле сумма пользовательской и системной областей па-

мяти выходит за этот лимит, Presto автоматически прерывает выпол-

нение запроса. Подробнее о концепции пользовательской и системной

областей памяти поговорим в главе 6 «Администрирование Presto»;

discovery-server.enabled. Каждый узел, запускаясь, регистрирует себя

в каталоге службы обнаружения ( discovery service). Чтобы не полагать-ся на какую-либо внешнюю службу, узел-координатор может поддер-

38  Первые шаги в освоении Presto

живать встроенный сервер каталога. Этот параметр разрешает запуск

встроенной службы обнаружения, что существенно упрощает общую

конфигурацию кластера;

discovery.uri. Этот параметр указывает адрес службы обнаружения.

Поскольку установкой предыдущего параметра в true мы разреши-ли запуск встроенного сервера каталога на узле-координаторе, здесь

требуется указать адрес координатора. Сервер и порт, заданные в этом

параметре, должны совпадать с адресом сервера, где запущен коорди-

натор, и с портом, на котором координатор принимает соединения. На

конце адреса не должно быть символа / (слеша).

log.properties

Журналирование необходимо для понимания работы сервера, а также для

поиска и устранения неисправностей. Существует четыре уровня журналирования: DEBUG, INFO, WARN и ERROR. При необходимости вы можете указать свой уровень журналирования для каждого пакета. Для начала можно

использовать такую конфигурацию:

com.facebook.presto=INFO

Задав такую настройку, вы увидите в журнале значения всех параметров

в момент запуска узла, а также массу другой информации, которая может

быть полезна при отладке. Подробнее о настройках журналирования поговорим в главе 6 «Администрирование Presto».

catalog/<connector>.properties

Эта папка содержит настройки для всех коннекторов, используемых вашей

инсталляцией Presto. Как мы уже говорили в главе 1, коннекторы в Presto используются для доступа к различным источникам данных. Именно коннекторы обеспечивают реализацию парадигмы SQL поверх чего угодно ( SQL on any-thing). Для доступа к данным и их обработки Presto использует интерфейсы, специфические для источника. Так, например, для доступа к реляционным

базам данных применяются JDBC-драйверы, а для доступа к нереляционным

хранилищам, таким как S3 или Elastic, – соответствующие API и SDK.

Коннектор может использовать для взаимодействия с источником любой

механизм – SQL, RESTful API, HTTP или другие специфические интерфейсы

и протоколы, но от пользователя все эти механизмы скрыты. Коннектор

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

Составляя запрос к данным, вы должны только написать корректный SQL-запрос, а коннектор позаботится об остальном. Подробнее мы поговорим

о коннекторах в главе 3.

Коннектор устанавливает соединение между Presto и каталогом, к которому вы обращаетесь при помощи SQL. Коннектор скрывает от вас физическую

природу каталога: не имеет значения, что это такое – файл, NoSQL база данных, API или реляционная БД.

Запуск Presto в Docker  39

Чтобы зарегистрировать каталог, вам необходимо создать файл с настройками этого каталога в папке etc/catalog. Например, чтобы подключить каталог

TPC-H, вы можете создать файл tpch.properties со следующим содержимым: connector.name=tpch

Этот файл создаст каталог tpch при помощи коннектора tpch.

Сборка и запуск Presto

Теперь вы наконец готовы собрать Docker-образ. Для этого перейдите в папку, где находится файл Dockerfile, и запустите в терминале следующую команду:

docker build --build-arg PRESTO_VERSION=0.276.1 . -t prestodb:latest В переменной PRESTO_VERSION необходимо указать версию Presto, которую

вы хотите поместить в образ. На момент написания книги актуальная версия

Presto имела номер 0.276.1.

Когда сборка образа закончится, запустите его:

docker run --name presto prestodb:latest

Эта команда запускает контейнер с узлом Presto. Вы увидите на экране кучу информации, которую сервер отправляет в потоки stdout и stderrr.

И если после всего этого потока вы увидите вот такое сообщение:

INFO main com.facebook.presto.server.PrestoServer

======== SERVER STARTED ========

– это значит, что Presto успешно запустился.

Чтобы проверить, что сервер действительно работает, вы можете открыть

терминал прямо в том контейнере, где он запущен:

docker exec -it presto presto

Эта команда запустит клиентское приложение Presto, и вы сможете выполнить в нем какой-нибудь запрос. Например, запросить список каталогов: presto> show catalogs;

Команда должна вернуть следующий результат:

Catalog

-------

system

tpch

(2 rows)

Query 20220919_085038_00001_j5vrm, FINISHED, 1 node

Splits: 19 total, 19 done (100.00%)

0:22 [0 rows, 0B] [0 rows/s, 0B/s]

40  Первые шаги в освоении Presto

Этот результат говорит о том, что сервер видит два каталога – system и tpch.

Каталог tpch был создан нами в процессе настройки, и теперь мы убедились, что Presto корректно обработал конфигурационные файлы.

«Песочница» для Presto

Мы рассказали, как собрать собственный образ Presto с нуля. Если вам требуются дополнительные модули или библиотеки, вы можете использовать

готовый образ-«песочницу»1. В этом образе уже есть все библиотеки, позволяющие реализовать целый ряд сценариев, включая хранилище-озеро, которое мы будем строить в главе 5. Запуск «песочницы» подробно описан

в нашей документации2.

Развертывание Presto в Kubernetes

На рис. 2.1 вы видите кластер, который мы собираемся развернуть в среде

Kubernetes на локальном компьютере. Мы будем использовать два источника – модельное хранилище TPC-H и базу данных под управлением MySQL.

Наш кластер будет состоять из трех узлов, координатора и двух рабочих, каждый из которых представляет собой под3 в Kubernetes. Эта конфигурация

требует минимум 4 ГБайт оперативной памяти на каждом узле, и если на вашей машине недостаточно памяти или дисков, то вы можете оставить только

один рабочий узел. Можно было бы развернуть отдельный под с клиентским

модулем, но это привело бы к дополнительному расходу ресурсов. В целях

экономии мы развернем клиент Presto вместе с узлом-координатором.

Рабочий узел

TPCH

Клиент

Узел

Presto

координатор

Рабочий узел

MySQL

Кластер Presto

Каталоги

Рис. 2.1  Конфигурация Presto, которую мы развернем в Kubernetes: один координатор, два рабочих узла и два каталога

2 .

3 Pod – это единица развертывания приложения, запущенный контейнер, состоящий

из одного или нескольких образов. Слово pod не является аббревиатурой и обозначает стручок – вероятно, горошины в этом стручке и есть образы. Устоявшегося

русского термина не существует, специалисты так и называют эти объекты «по-дами». – Прим. перев.

Развертывание Presto в Kubernetes  41

Введение в Kubernetes

Чтобы развернуть локальный кластер Presto, на вашей машине должен быть

установлен Kubernetes. Способов установить Kubernetes на свою машину

множество, и не важно, какой из них вы выберете. Взаимодействие с Kubernetes осуществляется через утилиту командной строки kubectl. Эта утилита

входит в состав клиентского ПО Kubernetes; позаботьтесь о том, чтобы оно

также было у вас установлено. На нашем сайте1 вы можете найти подробные

инструкции для вашей ОС.

Код, приведенный в книге, работает в версии Kubernetes, входящей в Docker Desktop. Чтобы установить эту версию, первым делом вам надо установить сам

Docker Desktop, как это описано в предыдущем разделе, а затем выполнить еще

несколько шагов, чтобы активировать встроенную инсталляцию Kubernetes.

1. Запустите Docker Desktop и активируйте Dashboard2.

2. Нажмите кнопку «Settings» в правой верхней части окна.

Из меню в боковой панели слева выберите «Kubernetes», затем выбе-

рите «Enable Kubernetes» и нажмите кнопку «Apply & Restart».

Настройка Presto в Kubernetes

Код, использованный в данном разделе, доступен в папке 02/presto-kubernetes нашего репозитория. Кроме документации в файле README.md, папка содержит следующие файлы:

presto-coordinator.yaml – конфигурационный файл узла-координатора;

presto-workers.yaml – конфигурационный файл рабочего узла;

presto-config-map.yaml – используется для динамического изменения

параметров Presto;

presto-secrets.yaml – содержит секреты3, используемые в работе Presto;

MySQL configuration files – необходимы для добавления источника (каталога) в базе под управлением MySQL;

deploy.sh – скрипт развертывания кластера.

На рис. 2.2 видно, как связаны файлы, используемые для конфигурации

координатора и рабочих узлов.

Оставшуюся часть этого раздела мы посвятим описанию .yaml-файлов, используемых для конфигурации кластера, а затем разберемся, как добавить

к кластеру каталог на базе MySQL («Добавление каталога») и как устроен скрипт

deploy.sh («Запуск приложения в Kubernetes»). Если конфигурация кластера по

умолчанию вас устраивает, можете переходить к следующему разделу.

1 .

2 Docker Desktop на момент перевода книги не русифицирован, и русских терминов

для обозначения его компонентов просто не существует. Во избежание путаницы

в тексте используются английские термины без перевода. – Прим. перев.

3 К секретам относятся пароли к базам данных, приватные ключи к сертификатам, ключи симметричного шифрования и прочая информация, которую следует охранять от неавторизованного доступа. – Прим. перев.

42  Первые шаги в освоении Presto

prestoconfigmap.yaml

configcoordinator.properties

config.properties

prestocoordinator.yaml

prestoworker.yaml

Узелкоординатор

Рабочий узел

prestosecrets.yaml

mysql.properties

Рис. 2.2  Взаимоотношения между конфигурационными .yaml-файлами

для координатора и рабочих узлов

presto-coordinator.yaml

Этот файл размещает в кластере узел-координатор Presto, используя шаблон

ReplicationController1, и создает связанный с ним сервис.

Для начала создадим сервис и назовем его presto-coordinator:

apiVersion: v1

kind: Service

metadata:

spec:

ports:

- port: 8080

protocol: TCP

targetPort: 8080

type: LoadBalancer

selector:

app: presto-coordinator

Затем создадим ReplicationController и используем Docker-образ, созданный в предыдущем разделе:

---

apiVersion: v1

kind: ReplicationController

metadata:

spec:

1 Replication controller – шаблон развертывания, при котором Kubernetes автоматически поддерживает заданное количество экземпляров контейнера: останавливает

лишние и запускает недостающие. – Прим. перев.

Развертывание Presto в Kubernetes  43

replicas: 1

template:

metadata:

labels:

app: presto-coordinator

spec:

containers:

- name: presto-coordinator

image: prestodb:latest

imagePullPolicy: Never

ports:

- containerPort: 8080

- containerPort: 8889

resources:

requests:

memory: "4Gi"

limits:

memory: "4Gi"

Управление памятью вашего компьютера

Указывая объем оперативной памяти, выделяемой для пода, помните о том, сколько

физической памяти установлено в вашем компьютере. Общий объем памяти, выде-ленной для всех подов, не должен превышать объема доступной памяти. Если такое

случится, Kubernetes просто не сможет запустить некоторые поды.

Docker-образ, который мы создали, одновременно выполняет функции

и контроллера, и рабочего узла. Сейчас мы хотим разделить рабочий узел

и контроллер, и чтобы указать роль узла, необходимо внести изменения

в файл config.properties.

Указать роли узлов можно несколькими способами. Самый простой – изменить содержимое файла непосредственно внутри образа, однако в этом

случае образ придется собирать повторно. Мы решим эту задачу другим

способом – с использованием объектов ConfigMap и Secret.

Объект ConfigMap хранит информацию, не являющуюся конфиденциаль-

ной, в виде пар «ключ–значение». Под может использовать эту информацию, получив ее через параметры командной строки, через переменные среды

или в виде файла. В нашей конфигурации узлы будут использовать ConfigMap для хранения конфигурационных файлов Presto.

Объект Secret также хранит пары «ключ–значение», но, в отличие от ConfigMap, используется для конфиденциальной информации. Мы будем применять такой объект для информации о подключении каталога MySQL.

В файловую систему пода-координатора монтируются файл config.properties, указанный в ConfigMap, и файл mysql.properties, представленный объ-ектом Secret:

volumeMounts:

- name: config

mountPath: "/opt/presto/etc/config.properties"

subPath: config.properties

- name: mysql

44  Первые шаги в освоении Presto

mountPath: "/opt/presto/etc/catalog/mysql.properties"

subPath: mysql.properties

А теперь создадим собственно тома, которые будем монтировать. Для сек-ретной информации будем использовать объект Secret, а для обычной (или, на жаргоне системных администраторов, «нечувствительной», от англ. non-sensitive) – ConfigMap. Чуть позже мы разберемся, как устроены эти объекты, сейчас же сосредоточимся на том, как их сконфигурировать, чтобы узел-координатор мог ими воспользоваться:

volumes:

- name: config

configMap:

- key: "config-coordinator.properties"

path: "config.properties"

- name: mysql

secret:

secretName: presto-mysql-secrets

Обратите внимание, что в ConfigMap мы указали, что файл config-coordinator.properties изнутри пода будет виден под именем config.properties.

Смонтируем созданные тома:

volumeMounts:

- name: config

mountPath: "/opt/presto/etc/config.properties"

subPath: config.properties

- name: mysql

mountPath: "/opt/presto/etc/catalog/mysql.properties"

subPath: mysql.properties

Созданный том config мы смонтировали в файловую систему пода как

файл config.properties, а том mysql– как файл mysql.properties.

presto-workers.yaml

Этот файл разворачивает один или несколько рабочих узлов Presto, также используя шаблон ReplicationController. Конфигурационный файл очень похож

на конфигурационный файл координатора, поскольку мы используем тот же

самый Docker-образ для его запуска:

---

apiVersion: v1

kind: ReplicationController

metadata:

spec:

replicas: 2

template:

metadata:

labels:

Развертывание Presto в Kubernetes  45

app: presto-worker

spec:

containers:

- name: presto-worker

image: prestodb:latest

imagePullPolicy: Never

resources:

requests:

memory: "4Gi"

limits:

memory: "4Gi"

ports:

- containerPort: 8080

Мы решили ограничиться двумя рабочими узлами, но вы можете изменить

их количество, поменяв значение параметра replicas.

Сконфигурируем параметры для рабочего узла. Точно так же, как и для

координатора, будем передавать параметры с помощью объектов ConfigMap и Secret с той лишь разницей, что рабочий узел будет использовать другой

файл config.properties:

volumeMounts:

- name: config

mountPath: "/opt/presto/etc/config.properties"

subPath: config.properties

- name: mysql

mountPath: "/opt/presto/etc/catalog/mysql.properties"

subPath: mysql.properties

volumes:

- name: config

configMap:

- key: "config.properties"

path: "config.properties"

- name: mysql

secret:

secretName: presto-mysql-secrets

presto-ConfigMap.yaml

Этот файл содержит настройки, которые мы передаем узлу-координатору

и рабочим узлам. Если вы хотите изменить какие-то настройки или добавить

новые, отредактируйте этот файл. Мы указали в нем два разных файла config.

properties: один – для рабочих узлов, а другой – для координатора: apiVersion: v1

kind: ConfigMap

metadata:

data:

config.properties: |

coordinator=false

46  Первые шаги в освоении Presto

http-server.http.port=8080

memory.heap-headroom-per-node=0.5GB

query.max-memory=1GB

query.max-memory-per-node=0.5GB

query.max-total-memory-per-node=2GB

discovery.uri=http://presto-coordinator:8080

config-coordinator.properties: |

coordinator=true

node-scheduler.include-coordinator=true

http-server.http.port=8080

memory.heap-headroom-per-node=0.5GB

query.max-memory=1GB

query.max-memory-per-node=0.5GB

query.max-total-memory-per-node=2GB

discovery-server.enabled=true

discovery.uri=http://presto-coordinator:8080

Файлы почти одинаковые. Они различаются значением трех параметров –

coordinator, discovery-server.enabled и node-scheduler.include-coordinator.

presto-secrets.yaml

Для хранения конфигурации каталога на базе MySQL, содержащего параметры подключения к базе данных, мы используем объект Kubernetes под названием Secret. Если вы хотите добавить к вашей инсталляции Presto новые

каталоги, добавляйте их описание в этот файл. Наш файл приведен ниже:

---

apiVersion: v1

stringData:

mysql.properties: |-

connector.name=mysql

connection-url=jdbc:mysql://mysql:3306

connection-user=root

connection-password=dbuser

kind: Secret

metadata:

type: Opaque

Для создания каталога необходимо дать ему имя (параметр connector.name) и указать параметры подключения – адрес сервера (connection-url), а также

имя учетной записи и пароль (connection-user и connection-password).

Добавление каталога

Чтобы создать новый каталог, вам необходимо развернуть СУБД и определить сервис, с которым будет взаимодействовать коннектор Presto. В этом

разделе мы развернем каталог на базе MySQL, но вы можете по аналогии

развернуть любой другой каталог.

Развертывание Presto в Kubernetes  47

В нашем репозитории вы найдете следующие файлы:

mysql-pv.yaml – создает том (presistent volume), на котором MySQL будет

хранить данные;

mysql-deployment.yaml – разворачивает MySQL в кластере Kubernetes (создает deployment), а также создает сервис. Сервер читает параметры (например, пароли) из объекта Secret, который хранится в файле

mysql-secrets.yaml;

mysql-secrets.yaml – создает секреты для сервера MySQL. Все секреты

закодированы1 в BASE64. Вы можете самостоятельно сгенерировать

секрет следующей командой в терминале:

echo -h "your_password" | base64

Запуск приложения в Kubernetes

Чтобы развернуть созданную нами инсталляцию, запустите скрипт deploy.sh:

./deploy.sh -d

Можете также использовать флаг -r, чтобы удалить развернутый кластер

Presto, либо -b, чтобы сначала удалить кластер, а потом развернуть его

вновь.

Можно развернуть кластер и вручную.

1. Создайте пространство имен:

kubectl create namespace presto

2. Разверните MySQL:

kubectl create -f mysql-secrets.yaml --namespace presto

kubectl apply -f mysql-pv.yaml --namespace presto

kubectl apply -f mysql-deployment.yaml --namespace presto

3. Поместите в кластер объекты Secret и ConfigMap:

kubectl create -f presto-secrets.yaml --namespace presto

kubectl apply -f presto-config-map.yaml --namespace presto

4. И наконец запустите узел-координатор и рабочие узлы:

kubectl apply -f presto-coordinator.yaml --namespace presto

kubectl apply -f presto-workers.yaml --namespace presto

Вот и все, теперь ваш кластер Presto запущен. Можете проверить состояние

всех подов:

Дальше: Запросы к кластеру Presto