Съхранение в колони: Овладяване на оптимизацията на Parquet за големи данни

В ерата на големите данни ефективното съхранение и извличане са от първостепенно значение. Форматите за колонично съхранение, като Apache Parquet, се превърнаха в крайъгълен камък за модерното складиране на данни и анализи. Колоничната структура на Parquet позволява значителни оптимизации в компресирането на данни и производителността на заявките, особено при работа с големи набори от данни. Това ръководство предоставя цялостно изследване на техниките за оптимизация на Parquet, като се обръща към глобална аудитория от инженери, анализатори и архитекти на данни.

Разбиране на колоничното съхранение и Parquet

Какво е колонично съхранение?

Традиционните системи за съхранение, ориентирани към редове, съхраняват записи на данни последователно, ред по ред. Въпреки че това е ефективно за извличане на цели записи, то става неефективно, когато за анализ е необходим само подмножество от колони. Колоничното съхранение, от друга страна, съхранява данните по колони. Това означава, че всички стойности за дадена колона се съхраняват непрекъснато. Това оформление предоставя няколко предимства:

• Подобрена компресия: Подобни типове данни в рамките на колона могат да бъдат компресирани по-ефективно, използвайки техники като кодиране с дължина на изпълнение (RLE) или речниково кодиране.
• Намалено I/O: При заявки само на няколко колони системата трябва само да прочете данните от съответната колона, което значително намалява операциите за вход/изход и подобрява производителността на заявките.
• Подобрена аналитична производителност: Колоничното съхранение е добре пригодено за аналитични работни натоварвания, които често включват агрегиране и филтриране на данни в определени колони.

Представяме Apache Parquet

Apache Parquet е формат за колонично съхранение с отворен код, предназначен за ефективно съхранение и извличане на данни. Той е особено подходящ за използване с рамки за обработка на големи данни като Apache Spark, Apache Hadoop и Apache Arrow. Основните характеристики на Parquet включват:

• Колонично съхранение: Както беше обсъдено, Parquet съхранява данните по колони.
• Еволюция на схемата: Parquet поддържа еволюция на схемата, което ви позволява да добавяте или премахвате колони, без да презаписвате целия набор от данни.
• Компресия: Parquet поддържа различни кодеци за компресия, включително Snappy, Gzip, LZO и Brotli, което позволява значително намаляване на пространството за съхранение.
• Кодиране: Parquet използва различни схеми за кодиране, като речниково кодиране, просто кодиране и делта кодиране, за да оптимизира съхранението въз основа на характеристиките на данните.
• Predicate Pushdown: Parquet поддържа predicate pushdown, което позволява филтрирането да се извършва на нивото на съхранение, допълнително намалявайки I/O и подобрявайки производителността на заявките.

Ключови техники за оптимизация за Parquet

1. Дизайн на схема и типове данни

Внимателният дизайн на схемата е от решаващо значение за оптимизацията на Parquet. Изборът на подходящи типове данни за всяка колона може значително да повлияе на ефективността на съхранение и производителността на заявките.

• Избор на правилните типове данни: Използвайте най-малкия тип данни, който може точно да представи данните. Например, ако колона представлява възрасти, използвайте `INT8` или `INT16` вместо `INT32`, ако максималната възраст е в по-малкия диапазон. По същия начин, за парични стойности, помислете за използване на `DECIMAL` с подходяща прецизност и мащаб, за да избегнете неточности с плаваща запетая.
• Вложени структури от данни: Parquet поддържа вложени структури от данни (напр. списъци и карти). Използвайте ги разумно. Въпреки че могат да бъдат полезни за представяне на сложни данни, прекомерното влагане може да повлияе на производителността на заявките. Помислете за денормализиране на данни, ако вложените структури станат твърде сложни.
• Избягвайте големи текстови полета: Големите текстови полета могат значително да увеличат пространството за съхранение и времето за заявки. Ако е възможно, помислете за съхраняване на големи текстови данни в отделна система за съхранение и свързването им с данните от Parquet, използвайки уникален идентификатор. Когато е абсолютно необходимо да съхранявате текст, компресирайте подходящо.

Пример: Помислете за съхраняване на данни за местоположение. Вместо да съхранявате географска ширина и дължина като отделни колони `DOUBLE`, може да обмислите използването на геопространствен тип данни (ако се поддържа от вашия двигател за обработка) или съхраняването им като един `STRING` във добре дефиниран формат (напр. "latitude,longitude"). Това може да подобри ефективността на съхранение и да опрости пространствените заявки.

2. Избор на правилното кодиране

Parquet предлага различни схеми за кодиране, всяка от които е подходяща за различни видове данни. Изборът на подходящо кодиране може значително да повлияе на компресията и производителността на заявките.

• Обикновено кодиране: Това е кодирането по подразбиране и просто съхранява стойностите на данните такива, каквито са. Подходящо е за данни, които не се компресират лесно.
• Речниково кодиране: Това кодиране създава речник от уникални стойности за колона и след това съхранява индексите на речника вместо действителните стойности. То е много ефективно за колони с малък брой отделни стойности (напр. категорийни данни като кодове на държави, продуктови категории или кодове на състояния).
• Кодиране с дължина на изпълнение (RLE): RLE е подходящ за колони с дълги последователности от повтарящи се стойности. Той съхранява стойността и броя пъти, които се повтаря.
• Делта кодиране: Делта кодирането съхранява разликата между последователните стойности. Ефективно е за данни от времеви серии или други данни, където стойностите са склонни да бъдат близо една до друга.
• Bit-Packed кодиране: Това кодиране ефективно пакетира няколко стойности в един байт, намалявайки пространството за съхранение, особено за малки цели числа.

Пример: Помислете за колона, представляваща "статуса на поръчката" на транзакциите за електронна търговия (напр. "В очакване", "Изпратено", "Доставено", "Отменено"). Речниковото кодиране би било много ефективно в този сценарий, защото колоната има ограничен брой отделни стойности. От друга страна, колона, съдържаща уникални потребителски идентификатори, не би се възползвала от речниковото кодиране.

3. Кодеци за компресия

Parquet поддържа различни кодеци за компресия за намаляване на пространството за съхранение. Изборът на кодек може значително да повлияе както на размера на съхранението, така и на използването на CPU по време на компресия и декомпресия.

• Snappy: Snappy е бърз кодек за компресия, който предлага добър баланс между съотношение на компресия и скорост. Често е добър избор по подразбиране.
• Gzip: Gzip осигурява по-високи коефициенти на компресия от Snappy, но е по-бавен. Подходящ е за данни, до които се осъществява рядък достъп, или когато пространството за съхранение е основен приоритет.
• LZO: LZO е друг бърз кодек за компресия, който често се използва в Hadoop среди.
• Brotli: Brotli предлага още по-добри коефициенти на компресия от Gzip, но обикновено е по-бавен. Може да бъде добър вариант, когато пространството за съхранение е прекалено голямо и използването на CPU е по-малко проблемно.
• Zstandard (Zstd): Zstd предоставя широка гама от нива на компресия, което ви позволява да търгувате със съотношение на компресия за скорост. Често предлага по-добра производителност от Gzip при подобни нива на компресия.
• Некомпресиран: За отстраняване на грешки или конкретни критични за производителността сценарии можете да изберете да съхранявате данните некомпресирани, но това обикновено не се препоръчва за големи набори от данни.

Пример: За често достъпвани данни, използвани в анализи в реално време, Snappy или Zstd с по-ниско ниво на компресия биха били добър избор. За архивирани данни, до които се осъществява рядък достъп, Gzip или Brotli биха били по-подходящи.

4. Разделяне

Разделянето включва разделяне на набор от данни на по-малки, по-управляеми части въз основа на стойностите на една или повече колони. Това ви позволява да ограничите заявките до само съответните дялове, значително намалявайки I/O и подобрявайки производителността на заявките.

• Избор на колони за разделяне: Изберете колони за разделяне, които често се използват във филтрите на заявките. Общите колони за разделяне включват дата, държава, регион и категория.
• Разделяне на гранулиране: Обмислете гранулирането на вашите дялове. Твърде много дялове могат да доведат до малки файлове, което може да повлияе негативно на производителността. Твърде малко дялове могат да доведат до големи дялове, които са трудни за обработка.
• Йерархично разделяне: За данни от времеви серии обмислете използването на йерархично разделяне (напр. година/месец/ден). Това ви позволява ефективно да запитвате данни за конкретни времеви диапазони.
• Избягвайте разделяне с висока кардиналност: Избягвайте разделяне на колони с голям брой отделни стойности (висока кардиналност), тъй като това може да доведе до голям брой малки дялове.

Пример: За набор от данни за транзакции за продажби можете да разделите по `година` и `месец`. Това ще ви позволи ефективно да запитвате данни за продажби за конкретен месец или година. Ако често запитвате данни за продажби по държава, можете също да добавите `държава` като колона за разделяне.

5. Размер на файла и размер на блока

Parquet файловете обикновено са разделени на блокове. Размерът на блока влияе върху степента на паралелизъм по време на обработката на заявките. Оптималният размер на файла и размерът на блока зависят от конкретния случай на използване и основната инфраструктура.

• Размер на файла: Обикновено се предпочитат по-големи размери на файловете (напр. 128MB до 1GB) за оптимална производителност. По-малките файлове могат да доведат до увеличен общ обем поради управлението на метаданните и увеличените операции за вход/изход.
• Размер на блока: Размерът на блока обикновено се задава на размера на блока HDFS (напр. 128MB или 256MB).
• Уплътняване: Редовно уплътнявайте малките Parquet файлове в по-големи файлове, за да подобрите производителността.

6. Pushdown на предикати

Predicate pushdown е мощна техника за оптимизация, която позволява филтрирането да се извършва на нивото на съхранение, преди данните да бъдат прочетени в паметта. Това значително намалява I/O и подобрява производителността на заявките.

• Активиране на Pushdown на предикати: Уверете се, че pushdown на предикати е активиран във вашия двигател за заявки (напр. Apache Spark).
• Ефективно използвайте филтри: Използвайте филтри във вашите заявки, за да ограничите обема на данните, които трябва да бъдат прочетени.
• Изрязване на дялове: Pushdown на предикати може да се използва и за изрязване на дялове, където цели дялове се пропускат, ако не отговарят на филтъра на заявката.

7. Техники за пропускане на данни

Освен pushdown на предикати, могат да се използват и други техники за пропускане на данни, за да се намали допълнително I/O. Min/Max индексите, bloom филтрите и зоновите карти са някои стратегии за пропускане на четене на нерелевантни данни въз основа на статистиките на колоните или предварително изчислени индекси.

• Min/Max индекси: Съхраняването на минималните и максималните стойности за всяка колона в блок данни позволява на двигателя за заявки да пропуска блокове, които попадат извън обхвата на заявката.
• Bloom филтри: Bloom филтрите предоставят вероятен начин за проверка дали даден елемент е член на набор. Те могат да се използват за пропускане на блокове, които е малко вероятно да съдържат съвпадащи стойности.
• Зонови карти: Подобно на Min/Max индексите, Zone Maps съхраняват допълнителна статистика за данните в блок, което позволява по-сложно пропускане на данни.

8. Оптимизация на механизма за заявки

Производителността на Parquet заявките също зависи от използвания двигател за заявки (напр. Apache Spark, Apache Hive, Apache Impala). Разбирането как да оптимизирате заявките за вашия конкретен двигател за заявки е от решаващо значение.

• Оптимизирайте плановете за заявки: Анализирайте плановете за заявки, за да идентифицирате потенциални тесни места и да оптимизирате изпълнението на заявките.
• Оптимизация на свързване: Използвайте подходящи стратегии за свързване (напр. broadcast hash join, shuffle hash join) въз основа на размера на наборите от данни, които се свързват.
• Кеширане: Кеширайте често достъпвани данни в паметта, за да намалите I/O.
• Разпределение на ресурси: Правилно разпределете ресурси (напр. памет, CPU) на двигателя за заявки, за да осигурите оптимална производителност.

9. Локалност на данните

Локалността на данните се отнася до близостта на данните до възлите за обработка. Когато данните се съхраняват локално на същите възли, които ги обработват, I/O е минимизиран и производителността е подобрена.

• Съвместно разполагане на данни и обработка: Уверете се, че вашите Parquet данни се съхраняват на същите възли, които изпълняват вашия двигател за заявки.
• Осъзнаване на HDFS: Конфигурирайте вашия двигател за заявки да е наясно с топологията на HDFS и да дава приоритет на четенето на данни от локални възли.

10. Редовна поддръжка и наблюдение

Оптимизацията на Parquet е непрекъснат процес. Редовно наблюдавайте производителността на вашите Parquet набори от данни и правете корекции, ако е необходимо.

• Наблюдение на производителността на заявките: Проследявайте времената за изпълнение на заявките и идентифицирайте бавно работещите заявки.
• Наблюдение на използването на хранилище: Наблюдавайте пространството за съхранение, използвано от вашите Parquet набори от данни, и идентифицирайте възможности за компресия и оптимизация.
• Качество на данните: Уверете се, че вашите данни са чисти и последователни. Проблемите с качеството на данните могат да повлияят негативно на производителността на заявките.
• Еволюция на схемата: Планирайте внимателно еволюцията на схемата. Добавянето или премахването на колони може да повлияе на производителността, ако не се направи правилно.

Усъвършенствани техники за оптимизация на Parquet

Векторно четене с Apache Arrow

Apache Arrow е междуезикова платформа за разработка на данни в паметта. Интегрирането на Parquet с Apache Arrow позволява векторно четене, което значително подобрява производителността на заявките чрез обработка на данни в по-големи партиди. Това избягва режийните разходи за обработка на ред, което позволява много по-бързи аналитични работни натоварвания. Реализациите често включват директно използване на колоничен формат на Arrow в паметта от Parquet файлове, заобикаляйки традиционната итерация, базирана на редове.

Пренареждане на колони

Физическият ред на колоните във файл Parquet може да повлияе на компресията и производителността на заявките. Пренареждането на колоните така, че тези с подобни характеристики (напр. висока кардиналност спрямо ниска кардиналност) да се съхраняват заедно, може да подобри коефициентите на компресия и да намали I/O при достъп до конкретни групи колони. Експериментирането и профилирането са от решаващо значение за определяне на оптималния ред на колоните за даден набор от данни и работно натоварване.

Bloom филтри за колони от низове

Докато Bloom филтрите обикновено са ефективни за числени колони, те могат да бъдат полезни и за колони от низове, особено при филтриране на предикати за равенство (напр. `WHERE product_name = 'Specific Product'`). Активирането на Bloom филтри за често филтрирани колони от низове може значително да намали I/O чрез пропускане на блокове, които е малко вероятно да съдържат съвпадащи стойности. Ефективността зависи от кардиналността и разпределението на низовите стойности.

Персонализирано кодиране

За силно специализирани типове данни или модели обмислете прилагането на персонализирани схеми за кодиране, които са пригодени към специфичните характеристики на данните. Това може да включва разработване на персонализирани кодеци или използване на съществуващи библиотеки, които предоставят специализирани алгоритми за кодиране. Разработването и поддръжката на персонализирани кодирания изискват значителен опит, но могат да дадат значителни увеличения на производителността в конкретни сценарии.

Кеширане на метаданни на Parquet

Parquet файловете съдържат метаданни, които описват схемата, кодирането и статистиките на данните. Кеширането на тези метаданни в паметта може значително да намали латентността на заявките, особено за заявки, които имат достъп до голям брой Parquet файлове. Механизмите за заявки често предоставят механизми за кеширане на метаданни и е важно да конфигурирате тези настройки по подходящ начин, за да увеличите максимално производителността.

Глобални съображения за оптимизация на Parquet

При работа с Parquet в глобален контекст е важно да вземете предвид следното:

• Часови зони: Когато съхранявате времеви печати, използвайте UTC (Coordinated Universal Time), за да избегнете двусмислици и да осигурите последователност в различните часови зони.
• Кодиране на символи: Използвайте UTF-8 кодиране за всички текстови данни, за да поддържате широка гама от символи от различни езици.
• Валута: Когато съхранявате парични стойности, използвайте последователна валута и помислете за използване на десетичен тип данни, за да избегнете неточности с плаваща запетая.
• Управление на данни: Приложете подходящи политики за управление на данни, за да осигурите качеството и последователността на данните в различните региони и екипи.
• Съответствие: Бъдете наясно с разпоредбите за поверителност на данните (напр. GDPR, CCPA) и се уверете, че вашите Parquet данни се съхраняват и обработват в съответствие с тези разпоредби.
• Културни различия: Имайте предвид културните различия при проектирането на вашата схема за данни и избора на типове данни. Например, форматите на датите и форматите на числата може да варират в различните региони.

Заключение

Оптимизацията на Parquet е многостранен процес, който изисква задълбочено разбиране на характеристиките на данните, схемите за кодиране, кодеците за компресия и поведението на двигателите за заявки. Чрез прилагане на техниките, обсъдени в това ръководство, инженерите и архитектите на данни могат значително да подобрят производителността и ефективността на своите приложения за големи данни. Не забравяйте, че оптималната стратегия за оптимизация зависи от конкретния случай на използване и основната инфраструктура. Непрекъснатият мониторинг и експериментиране са от решаващо значение за постигане на възможно най-добрите резултати в постоянно развиващия се пейзаж на големите данни.