Раскладка паркета: Как укладывать паркет: виды рисунков

Содержание

Как укладывать паркет: виды рисунков

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

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

«Ёлочка»

Укладка доски «ёлочкой» – один из самых применяемых вариантов для деревянного пола. Доски укладываются двумя рядами, расположенными пол углом 90 градусов друг к другу. При этом свет падает на ряды параллельных досок под разным углом, и кажется, что доски имеют разный цветовой оттенок, хотя это не так. Общий рисунок похож на ёлку, откуда и название. «Ёлочка» – это классика советских квартир и общественных зданий, но она по сей день сохранила востребованность.

«Палубный» рисунок

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

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

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

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

«Квадрат» («шахматы»)

Экономный и просто способ, оставляющий мало отходов. Предполагает укладку досок рядами, где 3,4 или более досок (в зависимости от ширины доски: 3, 4 или более досок должны быть по сумме ширин равны длине доски) укладываются параллельно друг другу, а затем идёт ряд из стольких же досок под углом 90 градусов. Из-за разницы в направлении света квадраты из досок будут казаться разного цвета, поэтому можно использовать, как одинаковые по цвету доски, так и разные для квадратов через один, чтобы подчеркнуть контраст.

«Шашки со смещением» («квадраты со смещением»)

Основой является предыдущий способ, но крайние доски квадрата смещаются на расстояние ширины одной доски вниз или вверх. «Пробелы» закрываются квадратиками с ребром в ширину одной доски. Получается вот такой интересный вид. Для квадратиков можно использовать доски более тёмного цвета (если есть остатки досок от другой комнаты).

«Корзинка» («плетёнка»)

В основе – также «квадрат», но шашки представляют собой не квадрат, а прямоугольник, так как длина доски не равна сумме ширин. Прямоугольники укладываются по методу «квадрата», а промежутки закладываются квадратиками из доски. Внешне выглядит как плетёная корзинка, выглядит очень необычно и эстетично. Можно играть с направлением рядов и цветом прямоугольников.

«Ромб»

Укладка паркета ромбами — один из сложных способов: доски укладываются под углом, а стыки придётся спиливать для соединения рисунка. Способ напоминает шахматный, но доски предварительно без фиксации укладываются со смещением одна выше другой, а затем намечаются и ровно спиливаются. Если чередовать горизонтальные и вертикальные «шашки», можно получить интересный эффект объёмного изображения.

Технология укладки паркета – нормативные документы по паркетным работам, СНиП и ГОСТ «Паркетный метр»

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

СНиП 3. 04.01-87	«Изоляционные и отделочные покрытия»	Скачать
ГОСТ 862.1-85	«Изделия паркетные. Паркет штучный. Технические условия»	Скачать
ГОСТ 862.3-86	«Изделия паркетные. Доски паркетные. Технические условия»	Скачать
ГОСТ 8242-88	«Детали профильные из древесины и древесных материалов для строительства. Технические условия»	Скачать
ТР 114-01	«ТУ по технологии устройства покрытия пола из ламинат-паркета»	Скачать

Строительные нормы и правила СНиП 3.04.01-87

«Изоляционные и отделочные покрытия»

Требования данного СНиП распространяются на производство и приемку работ по устройству полов зданий и сооружений.

Показатель	Нормативные требования
Общие требования	Перед устройством полов, в конструкции которых заложены изделия и материалы на основе древесины, в помещении должны быть выполнены штукатурные и др. работы, связанные с возможностью увлажнения покрытий. При устройстве этих полов и в последующий период до сдачи объекта в эксплуатацию относительная влажность воздуха в помещении не должна превышать 60%.
Требования к промежуточным элементам пола	Для стяжек под покрытия из паркета просветы между контрольной двухметровой рейкой и проверяемой поверхностью не должны превышать 2 мм. Отклонения плоскости элемента от горизонтали или заданного уклона – не более 0,2% соответствующего размера помещения.
Влажность материалов	Влажность материалов при их укладке в напольное покрытие не должна превышать: – для досок покрытия и основания – 12%; – штучного паркета, паркетных досок и паркетных щитов – 10%.
Требования к готовому покрытию пола	Отклонения поверхности покрытия от плоскости при проверке контрольной двухметровой рейкой для паркетных и дощатых покрытий не должны превышать 2 мм. Уступы между покрытиями и элементами окаймления пола не должны превышать 2 мм. Отклонения от заданного уклона покрытий – не более 0,2% соответствующего размера помещения, но не более 50 мм. Отклонения по толщине покрытия – не более10% от проектной. Зазоры не должны превышать: – между досками дощатого покрытия – 1,0 мм; – между паркетными доскам и паркетными щитами – 0,5 мм; – между смежными планками штучного паркета – 0,3 мм. Поверхность покрытия не должна иметь выбоин, трещин, волн, вздутий, приподнятых кромок.

Государственный стандарт ГОСТ 862.1-85

«Изделия паркетные. Паркет штучный.

Технические условия»

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

Показатель	Нормативные требования
Предельные отклонения от номинальных значений	– по длине +/- 0.3 мм – по ширине +/- 0.2 мм – по толщине +/- 0.2 мм
Отклонение от перпендикулярности продольной кромки и торца	не более 0.2 мм на длине 100 мм
Отклонение от плоскостности	– продольной – 0,6 мм (в расчете на длину 1 м) – поперечной – 0,2 мм (на ширину планки)
Механические повреждения (отщеп, скол, вырыв, задир и т.п.)	на лицевой стороне планок не допускаются
Влажность древесины при отгрузке потребителю	9% +/- 3% *
Приемочный уровень дефектности паркетных планок	4% от объема партии в штуках

Государственный стандарт ГОСТ 862.

3-86

«Изделия паркетные. Доски паркетные. Технические условия»

Требования данного ГОСТа распространяются на паркетные доски, предназначенные для устройства полов в жилых зданиях.

Показатель	Нормативные требования
Предельные отклонения от номинальных значений	– по длине +/- 2,0 мм – по ширине +/- 0.3мм – по толщине +/- 0.2 мм
Отклонение от перпендикулярности смежных кромок	не более 0.3 мм на длине 100 мм
Отклонение от прямолинейности	– продольной (в расчете на длину 1 м): по лицевой стороне – 5,0 мм по кромке – 0,5 мм – поперечной – 1,0 мм на 100 мм
Механические повреждения (отщеп, скол, вырыв, задир, выщербина)	не допускаются на лицевой стороне шириной более 0,5 мм и длиной более 10 мм
Влажность древесины при отгрузке досок потребителю	8% +/- 2%
Качество лакового покрытия	не ниже требований 4-го класса по ГОСТ 24404
Толщина лаковой пленки, нанесенной в заводских условиях	не менее 60 мкм (микрон)
Адгезия лакового покрытия к древесине	не ниже балла 3 по ГОСТ 15140
Приемочный уровень дефектности паркетных досок	4% от объема партии в шту

Государственный стандарт ГОСТ 8242-88

«Детали профильные из древесины и древесных материалов для строительства.

Технические условия»

Требования данного ГОСТа распространяются на доски и бруски для покрытия полов, плинтусы, наличники.

Показатель	Нормативные требования
Предельные отклонения от номинальных значений размеров деталей	– по длине +/- 3,0 мм – по ширине +/- 1,0 мм – по толщине +/- 1,0 мм
Отклонение от перпендикулярности сторон деталей	не более 1,0 мм на длине 100 мм
Отклонение от плоскостности (покоробленность) для досок пола. То же, для плинтусов	– по длине – 3,0 мм на 1 м длины; – по ширине – 2,0 мм является допустимым, если может быть устранено легким прижатием к ровной поверхности
Отклонение от прямолинейности любой кромки доски шириной более 70 мм, по ее длине	не более 2 мм на 1 м длины
Механические повреждения (вырыв, вмятина, скол, задир, выщербина и т. п.)	на лицевой стороне досок, под прозрачное покрытие, не допускаются глубиной более 0,5 мм
Влажность древесины при отгрузке потребителю	12% +/- 3% *
Приемочный уровень дефектности деталей	4% от объема партии в штуках

ТЕХНИЧЕСКИЕ РЕКОМЕНДАЦИИ ТР 114-01

“ТУ по технологии устройства покрытия пола из ламинат-паркета”

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

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

Показатель	Нормативные требования
Температура воздуха в помещениях	не ниже 15 °С
Относительная влажность воздуха	не должна превышать 60 %.
Прочность железобетонной панели или стяжки из цементно-песчаного раствора	не ниже 15 МПа (150 кГс/см²)
Влажность бетона панели	не допускается выше 4 %,
Влажность стяжки из раствора	не допускается выше 5 %.
Отклонения поверхности основания от горизонтальной плоскости	не должны превышать 0,2 %

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

кодировок | Apache Parquet

Обычная: (PLAIN = 0)

Поддерживаемые типы: все

Это простая кодировка, которая должна поддерживаться для типов. Это предназначена для простейшей кодировки. Значения кодируются подряд.

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

BOOLEAN: Упакованный бит, LSB сначала
INT32: 4 байта с прямым порядком байтов
INT64: 8 байт с прямым порядком байтов
INT96: 12 байтов с прямым порядком байтов (устарело)
FLOAT: 4 байта с прямым порядком байтов IEEE
DOUBLE: 8 байтов с прямым порядком байтов IEEE
BYTE_ARRAY: длина в 4 байта с прямым порядком байтов, за которыми следуют байты, содержащиеся в массиве
2 : байты, содержащиеся в массиве

Для нативных типов это выводит данные с прямым порядком байтов. Плавающий типы точек кодируются в IEEE.

Для типа байтового массива длина кодируется как 4-байтовая маленькая endian, за которым следуют байты.

Кодировка словаря (PLAIN_DICTIONARY = 2 и RLE_DICTIONARY = 8)

Кодировка словаря создает словарь значений, встречающихся в заданном столбце. словарь будет храниться на странице словаря для каждого фрагмента столбца. Значения хранятся как целые числа с использованием гибридного кодирования RLE/Bit-Packing. Если словарь становится слишком большим, будь то размер или количество различных значений, кодировка вернется к обычной кодировке. Страница словаря записывается первым, перед страницами данных фрагмента столбца.

Формат страницы словаря: статьи в словаре – в порядке словаря – с использованием простой кодировки.

Формат страницы данных: разрядность, используемая для кодирования идентификаторов записей, хранящихся как 1 байт (макс. разрядность = 32), за которыми следуют значения, закодированные с использованием описанной выше упаковки RLE/Bit (с заданной разрядностью).

Использование значения перечисления PLAIN_DICTIONARY не рекомендуется в спецификации Parquet 2.0. Предпочтительнее использовать RLE_DICTIONARY на странице данных и PLAIN на странице словаря для файлов Parquet 2.0+.

Гибрид кодирования длин серий и упаковки битов (RLE = 3)

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

Грамматика для этой кодировки выглядит следующим образом, учитывая заранее известную фиксированную разрядность:

 rle-bit-packed-hybrid:  
length := длина  в байтах, хранящихся как 4 байта с прямым порядком байтов (целое число без знака 32)
закодированные данные := *
run :=  | 
bit-packed-run :=  
бит-упакованный-заголовок := varint-encode( << 1 | 1)
// мы всегда побитово упаковываем кратное 8 значениям за раз, поэтому мы сохраняем только количество значений / 8
бит-пакет-масштабируемый-прогон-длина := (бит-упакован-прогон-длина) / 8
bit-packed-run-len := *см. 3 ниже*
битовые значения := *см. 1 ниже*
rle-run :=  <повторяющееся-значение>
rle-header := varint-encode( (rle-run-len) << 1)
rle-run-len := *см. 3 ниже*
повторяющееся значение := значение, которое повторяется с использованием фиксированной ширины округления до следующего байта (битовая ширина)

Битовая упаковка здесь выполняется в другом порядке, чем в устаревшей кодировке битовой упаковки. Значения упаковываются от младшего значащего бита каждого байта до самого старшего бита, хотя порядок битов в каждом значении остается в обычном порядке от наиболее значимого к наименее значительный. Например, чтобы упаковать те же значения, что и в устаревшей кодировке выше:
Числа от 1 до 7 с разрядностью 3:
```
 dec value: 0 1 2 3 4 5 6 7
битовое значение: 000 001 010 011 100 101 110 111
метка бита: ABC DEF GHI JKL MNO PQR STU VWX
 
```
будет закодирован следующим образом, где пробелы обозначают границы байтов (3 байта):
```
 битовое значение: 10001000 11000110 11111010
битовая метка: HIDEFABC RMNOJKLG VWXSTUPQ
 
```
Причина такого порядка упаковки состоит в том, чтобы иметь меньше границ слов на оборудовании с прямым порядком байтов. при десериализации более одного байта за раз. Это потому, что 4 байта могут быть прочитаны в 32-битный регистр (или 8 байт в 64-битном регистре), и значения могут быть распакованы просто сдвиг и операция ИЛИ с маской. (чтобы эта оптимизация работала на машине с обратным порядком байтов, вам придется использовать порядок, используемый в устаревшей кодировке битовой упаковки)
varint-encode() — кодировка ULEB-128, см. https://en.wikipedia.org/wiki/LEB128
bit-packed-run-len и rle-run-len должны быть диапазон [1, 2 ³¹ - 1]. Это означает, что реализация Parquet всегда может хранить длину прогона в подписанном файле. 32-битное целое число. Это ограничение длины не было частью Parquet 2.5.0 и более ранних версий. спецификации, но более длинные пробеги не читались самым обычным паркетом. реализации, так что на практике было небезопасно для авторов Parquet.

Обратите внимание, что метод кодирования RLE поддерживается только для следующих типов data:

Уровни повторения и определения
Словарные индексы
Логические значения на страницах данных, как альтернатива кодированию PLAIN кодирование, которое устарело и будет заменено гибридным кодированием RLE/bit-packing. Каждое значение кодируется последовательно, используя фиксированную ширину. Между значениями нет заполнения (за исключением последнего байта), который дополняется нулями. Например, если максимальный уровень повторения равен 3 (2 бита), а максимальный уровень четкости равен 3 (2 бита), для кодирования 30 значений у нас было бы 30 * 2 = 60 бит = 8 байт.
Эта реализация устарела, поскольку гибрид RLE/бит-упаковки является расширенным набором этой реализации. По соображениям совместимости эта реализация упаковывает значения от самого старшего бита до самого младшего бита, что не то же самое, что гибрид RLE/bit-packing.
Например, числа от 1 до 7 с разрядностью 3:
```
 Десятичное значение: 0 1 2 3 4 5 6 7
битовое значение: 000 001 010 011 100 101 110 111
метка бита: ABC DEF GHI JKL MNO PQR STU VWX
 
```
будет закодирован следующим образом, где пробелы обозначают границы байтов (3 байта):
```
 битовое значение: 00000101 00111001 01110111
битовая метка: ABCDEFGH IJKLMNOP QRSTUVWX
 
```
Обратите внимание, что метод кодирования BIT_PACKED поддерживается только для кодирования уровни повторения и определения.
Дельта-кодирование (DELTA_BINARY_PACKED = 5)
Поддерживаемые типы: INT32, INT64
Это кодирование адаптировано из упаковки Binary, описанной в «Декодировании миллиардов целых чисел в секунду посредством векторизации» Д. Лемира и Л. Бойцова.
В дельта-кодировании мы используем целые числа переменной длины для хранения различных чисел (а не сами дельты). Для значений без знака мы используем ULEB128, который является версией LEB128 без знака (https://en.wikipedia.org/wiki/LEB128#Unsigned_LEB128). Для значений со знаком мы используем зигзагообразное кодирование (https://developers.google.com/protocol-buffers/docs/encoding#signed-integers), чтобы сопоставить отрицательные значения с положительными и применить к результату ULEB128.
Дельта-кодирование состоит из заголовка, за которым следуют блоки дельта-кодированных значений, упакованных в двоичном виде. Каждый блок состоит из миниблоков, каждый из которых бинарно упакован со своей разрядностью.
Заголовок определяется следующим образом:
```
 <размер блока в значениях> <количество миниблоков в блоке> <общее количество значений> <первое значение>
 
```
- размер блока кратен 128; он хранится как ULEB128 int
- количество миниблоков на блок является делителем размера блока, так что их частное, количество значений в миниблоке, кратно 32; он хранится как ULEB128 int
- общее количество значений хранится как ULEB128 int
- первое значение хранится в виде зигзага ULEB128 int
Каждый блок содержит
```
  <список разрядностей миниблоков> 
 
```
- минимальная дельта представляет собой зигзаг ULEB128 int (мы вычисляем минимум, так как нам нужны положительные целые числа для упаковки битов)
- битовая ширина каждого блока хранится в виде байта
- каждый миниблок представляет собой список упакованных битов целых чисел в соответствии с разрядность, сохраненная в начале блока
Чтобы закодировать блок, мы:
1. Вычислим разницу между последовательными элементами. Для первого элемента в блоке используйте последний элемент в предыдущем блоке или, в случае первого блока, используйте первое значение всей последовательности, сохраненное в заголовке.
2. Вычислить систему отсчета (минимум дельт в блоке). Вычтите эту минимальную дельту из всех дельт в блоке. Это гарантирует, что все значения неотрицательны.
3. Кодирует систему отсчета (мин. дельта) как зигзагообразный ULEB128 int, за которым следует битовая ширина миниблоков и дельта-значения (минус дельта), упакованные в каждый миниблок.
Наличие нескольких блоков позволяет нам адаптироваться к изменениям в данных путем изменения системы отсчета (минимальной дельты), что может привести к меньшим значениям после вычитания, что, опять же, означает, что мы можем хранить их с меньшей разрядностью .
Если для заполнения последнего миниблока недостаточно значений, мы дополняем миниблок так, чтобы его длина всегда равнялась числу значений в полном миниблоке, умноженному на разрядность. Значения битов заполнения должны быть равны нулю, но считыватели также должны принимать заполнения, состоящие из произвольных битов.
Если в последнем блоке для хранения значений требуется менее <количество миниблоков в блоке> миниблоков, то байты, хранящие разрядность ненужных миниблоков, все еще присутствуют, их значение должно быть равно нулю, но читатели также должны принимать произвольные значения. Однако для тел миниблоков нет дополнительных байтов заполнения, как если бы их битовая ширина была равна 0 (независимо от фактических значений байтов). Читатель знает, когда прекратить чтение, отслеживая количество прочитанных значений.
В следующих примерах в качестве размера блока используется 8, чтобы примеры были короткими, но в реальных случаях это было бы недопустимо.
Пример 1
1, 2, 3, 4, 5
После шага 1 мы вычисляем дельты как:
1, 1, 1, 1
дельты становятся
0, 0, 0, 0
Окончательные закодированные данные:
заголовок: 8 (размер блока), 1 (количество миниблоков), 5 (количество значений), 1 (первое значение)
блока 1 (минимальная дельта), 0 (битовая ширина), (для битовой ширины 0 данные не требуются)
Пример 2
7, 5, 3, 1, 2, 3, 4, 5, дельты будут
-2, -2, -2, 1, 1, 1, 1
Минимум - 2, поэтому относительные дельты:
0, 0, 0, 3, 3, 3, 3
Закодированные данные — заголовок
: 8 (размер блока), 1 (количество миниблоков), 8 (количество значений), 7 (первое значение)
блок -2 (минимальная дельта), 2 (разрядность), 00000011111111b (0,0,0,3,3,3,3, упакованные по 2 бита)
Характеристики
Эта кодировка аналогична кодировке RLE/битовой упаковки. Однако кодирование RLE/bit-packing специально используется, когда диапазон целых чисел невелик по всей странице, что справедливо для уровней повторения и определения. Он использует один бит для всей страницы. Алгоритм дельта-кодирования, описанный выше, сохраняет битовую ширину на миниблок и менее чувствителен к изменениям размера закодированных целых чисел. Это также в некоторой степени выполняет кодирование RLE, поскольку блок, содержащий все те же значения, будет бит упакован до нулевой разрядности, таким образом, являясь только заголовком.
Массив байтов дельта-длины: (DELTA_LENGTH_BYTE_ARRAY = 6)
Поддерживаемые типы: BYTE_ARRAY
Эта кодировка всегда предпочтительнее PLAIN для столбцов массива байтов.
Для этой кодировки мы возьмем все длины массива байтов и закодируем их с помощью дельты кодировка (DELTA_BINARY_PACKED). Данные массива байтов следуют за всеми данными длины только соединены спиной к спине. Ожидаемая экономия за счет стоимости кодирования длин и, возможно, лучшее сжатие данных (они больше не чередуются с длинами).
Поток данных выглядит так:
Например, если данные были «Hello», «World», «Foobar», «ABCDEF»:
Закодированные данные будут DeltaEncoding(5, 5, 6, 6) «HelloWorldFoobarABCDEF»
Дельта-строки: (DELTA_BYTE_ARRAY = 7)
Поддерживаемые типы: BYTE_ARRAY
Это также известно как инкрементное кодирование или фронтальное сжатие: для каждого элемента в последовательность строк, сохраните длину префикса предыдущей записи плюс суффикс.
Более подробное описание см. на странице https://en.wikipedia.org/wiki/Incremental_encoding.
Сохраняется как последовательность длин префиксов в дельта-кодировании (DELTA_BINARY_PACKED), за которыми следует суффиксы, закодированные как массивы байтов дельта-длины (DELTA_LENGTH_BYTE_ARRAY).
Разделение потока байтов: (BYTE_STREAM_SPLIT = 9)
Поддерживаемые типы: FLOAT DOUBLE
Это кодирование не уменьшает размер данных, но может значительно улучшить коэффициент сжатия и скорость при последующем использовании алгоритма сжатия.
Эта кодировка создает K байтовых потоков длины N, где K — размер данных в байтах. тип, а N — количество элементов в последовательности данных. Байты каждого значения разбросаны по соответствующим потокам. 0-й байт идет в 0-й поток, 1-й байт идет в 1-й поток и так далее. Потоки объединяются в следующем порядке: 0-й поток, 1-й поток и т. д.
Пример: Исходные данные — это три 32-битных числа с плавающей запятой, и для простоты мы рассмотрим их необработанное представление.
```
 Элемент 0 Элемент 1 Элемент 2
Байты AA BB CC DD 00 11 22 33 A3 B4 C5 D6
 
```
После применения преобразования данные имеют следующее представление:
```
 Байт AA 00 A3 BB 11 B4 CC 22 C5 DD 33 D6
 
```
Последнее изменение 24 марта 2022 г.: Final Squash (3563721)
Демистификация формата файла Parquet | Майкл Берк
Формат файла по умолчанию для любого рабочего процесса обработки данных
Вы когда-нибудь использовали pd.read_csv() в pandas? Ну, эта команда могла бы работать примерно в 50 раз быстрее, если бы вы использовали паркет вместо CSV.
Фото Майка Бенна на Unsplash
В этом посте мы обсудим apache parquet, чрезвычайно эффективный и хорошо поддерживаемый файловый формат. Этот пост предназначен для специалистов по работе с данными (ML, DE, DS), поэтому мы сосредоточимся на концепциях высокого уровня и используем SQL для обсуждения основных концепций, но ссылки на дополнительные ресурсы можно найти в посте и в комментариях.
Без лишних слов, вперед!
Паркет Apache — это формат файлов с открытым исходным кодом, обеспечивающий эффективное хранение и высокую скорость чтения. Он использует гибридный формат хранения, в котором последовательно хранятся фрагменты столбцов, что обеспечивает высокую производительность при выборе и фильтрации данных. Помимо надежной поддержки алгоритмов сжатия (snappy, gzip, LZO), он также предоставляет несколько хитростей для уменьшения числа сканирований файлов и кодирования повторяющихся переменных.
Если вам важна скорость, обратите внимание на паркет.
Хорошо, давайте немного замедлимся и поговорим о паркете на простом английском языке.
1 — Проблема хранения данных
Допустим, мы инженеры по обработке данных. Мы стремимся создать архитектуру данных, которая облегчит онлайн-аналитические процессы ( OLAP ), которые представляют собой просто выборочные запросы, ориентированные на анализ данных. Некоторыми примерами функций данных, оптимизированных в среде OLAP, являются исследовательский анализ данных или наука о принятии решений.
Но как хранить данные на диске?
Рисунок 1: пример преобразования двумерной таблицы в двоичную. Изображение автора.
Ну, есть много соображений, когда мы думаем о том, является ли наше преобразование хорошим или плохим , но для рабочих процессов OLAP нас в основном интересуют два…
- Скорость чтения : насколько быстро мы можем получить доступ и декодировать соответствующую информацию из двоичных файлов
- Размер на диске : сколько места требуется нашему файлу в двоичном формате
Обратите внимание, что существуют и другие критерии успеха алгоритма сжатия файлов, такие как скорость записи и поддержка метаданных, но мы просто сосредоточимся на двух вышеупомянутых сейчас.
Итак, как работает паркет по сравнению с CSV-файлом? Занимает на 87 % меньше места и выполняет запросы в 34 раза быстрее (1 ТБ данных, хранилище S3) — src
2 — Основные функции Parquet
Но почему паркет настолько эффективнее, чем CSV и другие популярные форматы файлов? Первый ответ — схема хранения…
2.1 — Гибридная схема хранения
Когда мы преобразуем двумерную таблицу в последовательность нулей и единиц, мы должны тщательно продумать оптимальную структуру. Должен ли быть написан первый столбец, затем второй, затем третий? Или мы должны последовательно хранить строки?
Традиционно существует три основных макета, которые преобразуют нашу двумерную таблицу в 1:
1. На основе строк: последовательно хранят строки (CSV).
2. На основе столбцов: последовательно хранить столбцы (ORC).
3. Гибрид-база: последовательно хранить куски столбцов (Паркет).
Мы можем увидеть графическое представление каждого из этих форматов на рисунке 2.
Рисунок 2: 3 основных типа хранения. Изображение автора.
Теперь гибридные макеты действительно эффективны для рабочих процессов OLAP, поскольку они поддерживают как проекцию, так и предикаты.
Проекция — это процесс выбора столбцов — вы можете думать об этом как о операторе SELECT в SQL-запросе. Проекция лучше всего поддерживается макетом на основе столбцов. Например, если мы хотим прочитать первый столбец таблицы, используя макет на основе столбцов, мы можем просто прочитать первые n индексов в нашем двоичном файле, десериализовать их и представить пользователю. Довольно эффективно, правда?
Предикаты — это критерии, используемые для выбора строк.0159 Предложение WHERE в запросе SQL. Предикаты лучше всего поддерживаются хранилищем на основе строк. Если нам нужны все строки в соответствии с некоторыми критериями, такими как Int >= 2 , мы можем просто упорядочить нашу таблицу по Int (по убыванию), сканировать до тех пор, пока наши критерии не будут удовлетворены, и вернуть все строки выше этой недопустимой строки.
В обоих этих сценариях мы стремимся пройти как можно меньшую часть файла . А поскольку наука о данных часто требует подмножества как строк, так и столбцов, гибридная структура хранилища дает нам нечто среднее между столбцовыми и строковыми форматами файлов.
Прежде чем двигаться дальше, важно отметить, что паркет часто называют столбчатым форматом. Однако из-за того, что он хранит фрагменты столбцов, как показано в нижней части рисунка 2, гибридная схема хранения является более точным описанием.
Отлично! Поэтому, если мы хотим получить данные, мы можем просто хранить последовательные фрагменты столбцов, и обычно дают очень хорошую производительность. Но масштабируется ли этот метод?
2.2 — Метаданные паркета
Ответ — громкое «да». Parquet использует метаданные, чтобы пропускать части наших данных, которые могут быть исключены в соответствии с нашим предикатом.
Рис. 3. Гибридное преобразование схемы хранения из двухмерной в одномерную. Изображение автора.
Взяв пример таблицы на рис. 3, мы видим, что размер нашей группы строк равен 2, что означает, что мы храним 2 строки данного столбца, 2 строки следующего столбца, 2 строки третьего столбца и так далее.
После того, как у нас закончились столбцы, мы переходим к следующему набору строк. Обратите внимание, что в приведенной выше таблице всего 3 строки, поэтому в последней группе строк будет только 1 строка.
Теперь предположим, что мы фактически храним 100 000 значений в наших группах строк вместо 2. Если мы попытаемся найти все строки, в которых наши Столбец Int имеет заданное значение (т. е. предикат равенства), в худшем случае будет сканирование каждой строки в таблице.
Рисунок 4: пример того, как паркет обрабатывает предикаты для групп строк. Изображение автора.
Parquet разумно решает эту проблему, сохраняя значения max и min для каждой группы строк, что позволяет нам пропускать целые группы строк, как показано на рисунке 4. Но это еще не все! Поскольку паркет часто записывает множество файлов .parquet в один каталог, мы можем просмотреть метаданные столбца для всего файла и определить, следует ли его сканировать.
Включив некоторые дополнительные данные, мы можем пропустить фрагменты наших данных и значительно увеличить скорость запросов. Подробнее см. здесь.
2.3 — Структура файла Parquet
Итак, мы намекнули, как данные преобразуются из двумерного формата в одномерный, но как устроена вся файловая система?
Ну, как упоминалось выше, паркет может записать много файлов .parquet за одну запись. С небольшими наборами данных это проблема, и вам, вероятно, следует перераспределить свои данные перед записью. Однако для больших наборов данных разбиение данных на несколько файлов может значительно повысить производительность.
В целом паркет имеет следующую структуру. Давайте рассмотрим каждый из них по очереди...
Root > Parquet Files > Row Groups > Columns > Data Page
Во-первых, наш корень файла — это просто каталог, который содержит все. Внутри корня у нас есть много отдельных .parquet файлов , каждый из которых содержит раздел наших данных. Один файл паркета состоит из многих групп строк , а одна группа строк содержит множество столбцов . Наконец, в наших столбцах есть страниц данных , которые фактически содержат необработанные данные и некоторые соответствующие метаданные.
Мы можем видеть упрощенное представление одного файла .parquet на рисунке 4 ниже.
Рисунок 4: Слои иерархической структуры паркета в последовательном порядке. Изображение автора.
Если вам интересны подробности, вот документация. Уровни повторения и определения также необходимы для полного понимания того, как работает страница данных, но это лишь некоторые бонусы.
3 — Дополнительные оптимизации
С момента своего появления в 2013 году паркет стал намного умнее. Базовая структура в основном не изменилась по сравнению с вышеуказанным форматом, но было добавлено множество интересных функций, повышающих производительность для определенных типов данных.
Давайте рассмотрим несколько примеров…
3.1 — В моих данных много повторяющихся значений!
Решение: кодирование длины цикла (RLE)
Допустим, у нас есть столбец с 10 000 000 значений, но все значения равны 9.0159 0 . Чтобы сохранить эту информацию, нам просто нужно 2 числа: 0 и 10 000 000 — значение и количество повторений .
RLE делает именно это. Когда обнаруживается много последовательных дубликатов, паркет может кодировать эту информацию как кортеж, соответствующий значению и количеству. В нашем примере это избавило бы нас от хранения 9 999 998 чисел.
3.2 — У моих данных очень большие типы!
Решение: кодирование по словарю с упаковкой битов
Допустим, у нас есть столбец, содержащий названия стран, некоторые из которых очень длинные. Если бы мы хотели сохранить «Демократическая Республика Конго», нам понадобился бы строковый столбец, который может обрабатывать не менее 32 символов.
Кодирование по словарю заменяет каждое значение в нашем столбце небольшим целым числом и сохраняет сопоставление в метаданных нашей страницы данных. На диске наши закодированные значения упакованы побитно, чтобы занимать как можно меньше места, но когда мы читаем данные, мы все еще можем преобразовать наш столбец обратно в исходные значения.
3.3 — Я использую сложные фильтры для своих данных!
Решение: проекция и проталкивание предиката
В искровой среде мы можем избежать чтения всей таблицы в память с помощью проекции и проталкивания предиката. Поскольку операции искры оцениваются лениво, то есть они не выполняются до тех пор, пока мы не запросим данные, искра может извлекать наименьшее количество данных в память.
В качестве краткого напоминания, предикаты подмножеств строк и проекций подмножеств столбцов. Итак, если мы знаем, что нам нужны только несколько столбцов и подмножество строк, нам фактически не нужно считывать всю таблицу в память — она фильтруется во время чтения.