Я думаю, що основна відмінність, яку я можу описати, стосується форматів, орієнтованих на запис, а також на стовпці. Формати, орієнтовані на запис - це те, до чого ми звикли - текстові файли, розмежовані формати, такі як CSV, TSV. AVRO трохи крутіше, ніж ті, тому що він може змінювати схему з часом, наприклад додавання або видалення стовпців із запису. Інші хитрощі різних форматів (особливо включаючи стиснення) передбачають, чи можна розділити формат - тобто чи можете ви прочитати блок записів з будь-якого місця набору даних і все ще знаєте, що це схема? Але ось детальніше про стовпчикові формати, як Паркет.
Паркет та інші стовпчасті формати вирішують загальну ситуацію Hadoop дуже ефективно. Зазвичай у таблицях (наборах даних) є набагато більше стовпців, ніж можна було б очікувати, у добре розробленій реляційній базі даних - сто чи двісті стовпців не є незвичайним. Це тому, що ми часто використовуємо Hadoop як місце для денормалізації даних із реляційних форматів - так, ви отримуєте безліч повторених значень і багато таблиць, зведених в одну. Але запитів стає набагато простіше, оскільки всі з'єднання відпрацьовані. Є й інші переваги, такі як збереження даних за станом часу. Тож у будь-якому випадку в таблиці є звичайне завантаження стовпчиків.
Скажімо, є 132 стовпчики, і деякі з них - це дійсно довгі текстові поля, кожен різний стовпець один за іншим, і може використовуватись до 10K на запис.
Хоча запит до цих таблиць простий з точки зору SQL, звичайно, що вам потрібно отримати деякий діапазон записів на основі лише декількох сто-плюс стовпців. Наприклад, ви можете зажадати всіх записів у лютому та березні для клієнтів із продажами> 500 доларів.
Для цього у форматі рядків запит повинен буде сканувати кожен запис набору даних. Прочитайте перший рядок, розберіть запис на поля (стовпці) та отримайте стовпці дати та продажу, включіть його у свій результат, якщо він задовольняє умові. Повторіть. Якщо у вас є 10 років (120 місяців) історії, ви читаєте кожен запис, щоб знайти два з цих місяців. Звичайно, це прекрасна можливість використовувати розділ на рік і місяць, але навіть ви читаєте та аналізуєте 10K кожного запису / рядка за ці два місяці, щоб дізнатися, чи продажі клієнта> 500 доларів.
У стовпчастому форматі кожен стовпець (поле) запису зберігається з іншими подібними видами, розкиданими по багатьох різних блоках на диску - стовпці за рік разом, стовпці за місяць разом, стовпці для довідника працівника клієнта (або інші довгий текст) та всі інші, які роблять ці записи такими величезними, все у своєму окремому місці на диску, і, звичайно, стовпці для спільного продажу. Ну, чорт, дата та місяці - це цифри, а також продажі - вони лише кілька байт. Хіба це не було б здорово, якби нам довелося лише прочитати кілька байтів для кожного запису, щоб визначити, які записи відповідають нашому запиту? Стовпчасте зберігання на допомогу!
Навіть без розділів сканування невеликих полів, необхідних для задоволення нашого запиту, є надзвичайно швидким - вони все впорядковані за записом та однакового розміру, тому диск шукає набагато менше перевірки даних щодо включених записів. Не потрібно читати цей посібник працівника та інші довгі текстові поля - просто ігноруйте їх. Тож, групуючи стовпці між собою, замість рядків, ви можете майже завжди сканувати менше даних. Виграй!
Але чекай, стає краще. Якщо для вашого запиту потрібно було знати лише ці значення та ще декілька (скажімо, 10 із 132 стовпців) і не хвилювався цей стовпець у посібнику службовців, після того, як він вибрав правильні записи для повернення, він повинен був би перейти лише зараз повернутися до 10 стовпців, необхідних для відображення результатів, ігноруючи інші 122 зі 132 в нашому наборі даних. Знову ми пропускаємо багато читання.
(Примітка. З цієї причини стовпчикові формати - це невдалий вибір при прямих перетвореннях, наприклад, якщо ви об'єднуєте всі дві таблиці в один великий (німецький) набір результатів, який ви зберігаєте як нову таблицю, джерела у будь-якому разі сканується повністю, тому корисності читання не мають великої користі, і оскільки стовпчикові формати повинні більше пам’ятати про те, де знаходиться, вони використовують більше пам’яті, ніж подібний формат рядків).
Ще одна перевага стовпців: дані поширюються навколо. Щоб отримати єдиний запис, ви можете мати 132 працівників, які читають (і записують) дані з / в 132 різних місцях на 132 блоках даних. Так, для паралелізації!
А тепер для клінчер: алгоритми стиснення працюють набагато краще, коли він може знайти повторювані шаблони. Ви можете стиснути AABBBBBBCCCCCCCCCCCCCCCCяк, 2A6B16Cале ABCABCBCBCBCCCCCCCCCCCCCCне отримаєте настільки маленькі (ну, насправді, у цьому випадку це було б, але повірте мені :-)). Тож ще раз, менше читайте. І писати теж.
Таким чином, ми читаємо набагато менше даних, щоб відповідати на поширені запити, можливо, паралельно читати і писати паралельно, а стиснення, як правило, працює набагато краще.
Стовпчик чудовий, коли ваша сторона вводу велика, а ваш вихід - відфільтрований підмножина: від великої до малої - великої. Не настільки вигідно, коли вхід і вихід приблизно однакові.
Але в нашому випадку Імпала брав наші старі запити у вуликах, які тривали через 5, 10, 20 чи 30 хвилин і закінчували більшість за кілька секунд чи хвилину.
Сподіваюся, це допоможе відповісти хоча б на частину вашого запитання!