Англійська для розробників Trino

Trino (раніше PrestoSQL) — це розподілений рушій запитів SQL, побудований для запитів даних, де вони живуть — об’єктне зберігання, реляційні бази даних, Kafka — без спочатку завантаження їх в єдиний склад. Ця модель «запит на місці» приносить словник (конектор, каталог, федеративний запит, розділи), який команди, які звикли до однієї бази даних, повинні швидко підібрати. Цей підручник містить англійську мову, яку використовують під час обговорення Trino з командою.

Ключовий словник

** Connector ** — додаток, який надає змогу Trino читати (а іноді і записувати) певне джерело даних — Hive, Iceberg, PostgreSQL, Kafka — перетворюючи оригінальний формат цього джерела даних на рушій запитів Trino. “Ми не можемо ефективно відсунути цей фільтр вниз, оскільки з’ єднання для цього джерела ще не підтримує відсунути предикат — воно має відтягнути весь розділ і відфільтрувати його після цього.”

** Каталог ** — названа конфігурація з’ єднання, яка вказує на певне джерело даних, надаючи кожній таблиці назву з трьох частин ( catalog.schema.table ), щоб один запит міг об’ єднати декілька систем.

• “Спостерігайте за таблицями складу за допомогою каталогу iceberg і даними замовлень за допомогою каталогу postgres — ви можете об’ єднати обидва каталоги в один запит.” *

** Спільний запит ** — це єдиний запит, який об’ єднує дані з декількох каталогів (а отже, з декількох базових систем) без фізичного пересування якихось з них.

• “Цей федеративний запит об’ єднує вчорашній знімок Айсберга з сьогоднішніми живими замовленнями Postgres — не потрібно жодного кроку ETL, щоб відповісти на запитання.” *

** Розділити ** — одиниця роботи Trino розділяє таблицю сканування на частини для паралельного виконання на різних робочих вузлах, приблизно аналогічно до одночасної обробки розділів або діапазонів файлів.

• “Якщо один з розділів набагато більший за інші, цей робочий об’ єкт стає вузлом — це класичне відхилення даних, яке з’ являється на рівні розділу.” *

** Передавати передбачені дані у вигляді відкидання ** — оптимізація запиту за допомогою передачі умов фільтрування до роз’ єднання, так що джерело, з якого було отримано дані, самостійно виконує фільтрування, замість того, щоб Trino отримував всі дані і фільтрував їх після цього.

• “Якщо натиснення предиката працює правильно, цей запит читає лише три відповідних розділи з S3 замість сканування всієї таблиці.” *

Звичайні фрази

• Чи підтримує цей коннектор відкидання предикатів, або ми витягуємо більше даних, ніж нам потрібно?»
• Чи є це федеративним запитом по каталогах, або може залишатися в одному джерелі?»
• Чи є розділи приблизно рівними, або один працівник робить непропорційно більше роботи?
• «Який каталог ця таблиця насправді живе під — чи ми впевнені, що це не неоднозначно?»
• Чи можемо ми уникнути переміщення цих даних взагалі і просто запитати їх федеративно замість цього?»

Приклади висловлювань

Перегляд запиту на звантаження:

• “Цей запит витягує всю таблицю перед фільтруванням у коді програми — переписати клаузулу WHERE, щоб предикат pushdown міг виконати фільтрування у джерелі.” *

Пояснення рішення про проектування:

• “Ми використовували федеративний запит замість нічних завдань ETL, оскільки вимога щодо свіжості тут становить хвилини, а не години.” *

Опис події: “Запит застряг на дев’яносто п’ять відсотків протягом двадцяти хвилин через розділення на частини - один розділ був в десять разів більший за інші, і один працівник все ще працював над ним.”

Професійні поради

• Використовувати « predict pushdown », коли запит повільний через надмірне отримання — це дає назву конкретній відсутній оптимізації і вказує переглядачам на виправлення.
• При проектуванні крос-системної аналітики, запитайте **“чи це має бути федеративним запитом, чи ми повинні матеріалізувати його спочатку?” ** - федерація є потужним, але не завжди найдешевшим варіантом.
• Використовуйте ** « каталог » ** правильно, щоб вказати налаштоване з’ єднання, а не назву джерела даних — змішування цих двох назв призведе до неправильного розуміння того, де насправді знаходиться таблиця.
• Згадуйте ** split skew ** явно, коли діагностуєте повільний, нерівномірно прогресуючий запит — це окрема проблема від відсутнього індексу або поганого порядку з’ єднання.

Практичні вправи

1. Поясніть двома реченнями різницю між з’ єднувачем і каталогом у Trino.
2. Написати коментар перегляду коду у одному реченні, у якому рекомендується переписати запит, щоб увімкнути відкидання предикатів.
3. Опишемо вашими словами, як виглядає розділене відхилення під час виконання запиту.

Навигація по лінії — практичний підхід

Для багатьох людей, для яких англійська не є рідною мовою, працюючи з технологіями, такими як Trino, розуміння * нюанс * зворотнього зв’язку - чи це коментар перегляду коду, обговорення Slack про проблеми з продуктивністю, або опис запитів на витягування - може бути неймовірно складним. Це не просто про знання окремих слів; це про розпізнавання немовлених очікувань і тонких способів зворотного зв’язку, що надається в професійному технічному спілкуванні. Здається простим запит на зміну може швидко стати заплутаним, якщо ви не звикли до того, як ці розмови зазвичай розгортаються в команді розробників. Цей розділ присвячено побудові такого розуміння, особливо щодо формування ваших відповідей і активного пошуку пояснень, якщо це потрібно.

Один поширений сценарій виникає під час перегляду коду. Уявіть, що ви отримали такий коментар: « Цей запит можна було б оптимізувати — розгляньте можливість використання функцій вікна замість підзапитів ». Звучить це просто, але * метою * цього коментаря є не лише ефективність; це пропозиція щодо поліпшення, запрошення до дослідження альтернативних підходів. Природною відповіддю може бути: « Чи можете ви розібратися, чому, на вашу думку, функції вікон були б тут більш підходящими? » Я намагався зробити його зрозумілим у цьому конкретному випадку.»  Зауважте активний елемент — безпосереднє запитання про пояснення демонструє залученість і бажання зрозуміти обґрунтування за пропозицією. Аналогічно, під час написання опису запиту на звантаження, уникайте нечітких вказівок, на зразок « Виправлено проблему з швидкодією ». Замість цього використовуйте такі фрази, як « Оптимізовано план запиту за допомогою адаптивного рушія виконання Trino » або « Зменшено затримку за допомогою переходу від кореляційного підзапиту до агрегації функцій вікна ». Точні слова створюють впевненість у вашій роботі і пояснюють цінність вашого вкладу.

Інша критична область - розуміння тону. Пряма критика може бути жорсткою, навіть якщо вона конструктивна. Навчання отримувати зворотній зв’язок грациозно - визнання пропозиції без негайного захисту вашого підходу - є ключовим. Фрази на кшталт «Це хороша точка зору, я ціную відгук» або «Я розслідую це далі» демонструють професіоналізм і відкривають вас для продуктивної дискусії. Не бійтеся ставити прояснюючі питання; набагато краще шукати розуміння, ніж неправильно інтерпретувати початковий намір. Пам’ятайте, що мета - це співпраця, а не конфронтація.

Нарешті, пам’ятайте про важливість документування ваших міркувань. Якщо ви зробили навмисний вибір — можливо, ви віддали перевагу простішому запиту для підтримки — коротке пояснення * чому * у повідомленні про перенесення або описі PR може запобігти майбутнім непорозумінням і надати цінний контекст для інших розробників.

# Example Trino query planning optimization (using Trino's adaptive execution)
trino --query "SELECT SUM(sales) FROM orders WHERE order_date BETWEEN '2023-01-01' AND '2023-12-31'" --explain

Цей приклад показує простий запит, але справжня цінність в розумінні адаптивного виконання Trino полягає в тому, як він * автоматично * оптимізує запити на основі характеристик даних. Знання цього дозволяє обговорювати поліпшення продуктивності з більшою впевненістю і точністю, а не просто заявивши «цей запит працює швидше»