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

Обговорення Apache Hudi вимагають пояснення, чому таблиця озера даних може підтримувати оновлення і вилучення, тому словник зосереджено на upserts, типах таблиць і моделі інкрементальної обробки, яка відрізняє Hudi від простого зберігання озера, що лише додає.

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

** Upsert ** — операція, яка вставляє новий запис, якщо його не існує, або оновлює його, якщо він існує, за допомогою ключа запису, що є основною можливістю Hudi, якої не підтримують звичайні стовпцеві файли на озері даних. “Ми перейшли на Hudi спеціально для upserts — наш попередній конвеєр тільки Parquet не мав чистого способу оновлення одного запису клієнта без перезапису всього розділу.”

** Таблиця копіювання при записі ** — тип таблиці Hudi, який перезаписує всі файли даних, які зазнали змін, під час кожного оновлення, оптимізуючи швидкість читання за рахунок повільнішого, важчого запису. “Ми використовуємо таблицю копіювання-запису для цього набору даних, тому що вона вимагає багато читання — додаткова вартість запису вартує швидшої продуктивності запиту вниз по течії.”

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

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

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

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

• “Затримка запиту збільшилася, оскільки стиснення не виконувалося протягом певного часу — як тільки вона наздоганяє, час читання повертається до нормального.” *

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

• Чи є у нас насправді необхідні upserts тут, або ж цей набір даних справді тільки для додавання?»
• Чи повинна це бути таблиця copy-on-write або таблиця merge-on-read, враховуючи, наскільки важко читати проти важко писати цю роботу?
• Чи можемо ми переключити це завдання на інкрементну обробку замість переобробки повної таблиці кожного запуску?
• Чи є упаковка затримується, або це сповільнення походить з десь ще в шляху запиту? ”
• «Як багато затримки читання ми торгували за пропускну здатність запису з цим вибором типу таблиці?»

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

Обґрунтування рішення щодо типу таблиці:

• “Ми обирали таблицю з об’ єднанням при читанні, оскільки об’ єм поглинання є великим і ми можемо терпіти затримку у стисканні, тоді як таблиця з копіюванням при записі зробила б кожен запис набагато дорожчим.” *

Пропозиція щодо оптимізації конвеєра:

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

Діагностика регресії швидкодії: “Перевірити, чи не сповільнюється стискання у цій таблиці об’ єднання при читанні — зростання затримки нестисканих журналів може пояснити сповільнення читання, яке ми спостерігаємо.”

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

• Обґрунтуйте ** uperts ** як головну причину вибору Hudi замість файлів простих озер — це конкретна можливість, а не нечітка заява про « краще озеро даних ».
• Поясніть copy-on-write проти merge-on-read компромісу явно при запропонуванні типу таблиці - це справжній читання/запис вартості компромісу зацікавлених сторін повинні розуміти, а не деталі реалізації.
• Порівняйте природні обробки з конкретними до/ після часу виконання — це найпереконливіший спосіб виправдати міграцію пакетного завдання.
• Проактивно стежити за затримкою ** стискання ** таблиць з об’ єднанням при читанні — зростання затримки є поширеною, але повільно погіршується причиною сповільнення читання.

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

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

Наприклад, англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська мова: англійська

Будьмо чесними - вивчення професійної англійської, особливо в технічній сфері, такій як Apache Hudi, може бути приголомшливим. Це не просто про те, щоб знати визначення слів; це про розуміння * як * ці слова використовуються в конкретних контекстах, і як тонкі відмінності у фразування можуть драматично змінити значення - і, можливо, вплинути на перегляд коду або обговорення команди. Як людина, для якої мова не є рідною, ви можете неохоче робити свій внесок, бо турбуєтеся про неправильне тлумачення. Ця частина розділу призначена для надання вам інструментів для впевненого керування у цих ситуаціях, зосереджуючись на практичних нюансах ефективного спілкування у середовищі розробки Apache Hudi.

Одним з поширених джерел розчарування є зворотній зв’язок, що надається опосередковано або з надмірно технічним жаргоном. Наприклад, рецензент може прокоментувати опис PR так: «Еволюція схеми здається… проблематичною.» Хоча це технічно вірно, це не відразу пояснює * чому *. Корисніша відповідь, спрямована на чітке спілкування, буде щось на зразок: « Чи можете ви розібратися у потенційних невідповідностях даних, які введено цим upsert? Зокрема, чи забезпечується сумісність з існуючим форматом таблиці під час операції запису?» Зауважте, що якщо ви задасте питання, яке стосується певної проблеми — послідовності даних і сумісності форматів — програма негайно надасть вам докладніше пояснення. Аналогічно, у розмовах у Slack не слід просто стверджувати « Це потрібно виправити ». Замість цього спробуйте « Я бачу деякі проблеми з продуктивністю upsert; чи можемо ми дослідити потенційні вузли або дослідити альтернативні стратегії для обробки цього обсягу даних? » Ключовим є перетворення ваших спостережень у питання, які вимагають глибшого розуміння від ваших колег. Пам’ ятайте, що запитання, що прояснюють, є * завжди * кращими, ніж припущення, що ви повністю розумієте складну технічну концепцію. Не бійтеся ввічливо запитати про приклад очікуваної поведінки, якщо вона не зрозуміла.

Іншою областю, де нюанс має значне значення, є опис типів таблиць Hudi - Copy-on-Write проти Incremental. Поширеною помилкою, навіть серед досвідчених розробників, є використання неточної мови. Сказати «табуля буде інкрементною» без вказівки як вона буде інкрементно оновлюватись, це рецепт для плутанини. Замість цього ви скажете: «Ми налаштовуємо цю таблицю як таблицю з інкрементами у форматі Delta Lake. Це означає, що наступні спроби запису змінюватимуть лише змінені розділи, зменшуючи дублювання даних і покращуючи швидкість запису. » Точна термінологія зменшує неоднозначність і забезпечує, що всі розуміють наслідки своїх дій. Крім того, при документуванні змін, зосередьтеся на що ви зробили і чому, а не тільки на як. Наприклад, замість того, щоб сказати «Оновлена логіка upsert», кращим описом буде: «Вреалізована оптимізована стратегія upsert для цієї таблиці, щоб зменшити затримку запису, використовуючи наявні можливості Hudi upsert»

Ось простий приклад використання hudi-spark для демонстрації того, як ви можете описати процес:

hudi-spark upsert -t my_table -p path/to/new_data --upsert-mode upsert-on-change -c "SELECT * FROM source_table WHERE id = 123"

Ця команда підкреслює основну функціональність — операцію upsert, спеціально розроблену для оновлення існуючих записів за умови. Використовуючи цей тип конкретного прикладу, при поясненні процесу, ви можете сказати: «Ми використовуємо hudi-spark upsert з прапорцем --upsert-mode upsert-on-change, щоб переконатися, що тільки вражені рядки записуються назад в таблицю Hudi»

---

Цей розділ присвячено розвитку ваших навичок спілкування у технічному контексті, спеціально розробленому для тих, хто вивчає англійську мову. Пам’ ятайте, що чітке і точне формулювання є ключовим у розробці Apache Hudi, особливо під час обговорення складних концепцій, таких як інкрементальна обробка і еволюція схем. Сфокусувавшись на тому, щоб задати прояснюючі питання, надати докладні пояснення і використовувати точну термінологію - підтримувану конкретними прикладами, такими як команда hudi-spark - ви можете впевнено внести свій внесок в успіх вашої команди і подолати потенційні бар’єри спілкування.