Фарматы файлаў у вялікіх дадзеных: кароткі лікбез

Weather Deity by Remarin

Каманда Mail.ru Cloud Solutions прапануе пераклад артыкула інжынера Рахула Бхат з кампаніі Clairvoyant аб тым, якія ёсць фарматы файлаў у вялікіх дадзеных, якія самыя распаўсюджаныя функцыі фарматаў Hadoop і які фармат лепш выкарыстоўваць.

Навошта патрэбны розныя фарматы файлаў

Сур'ёзнае вузкае месца ў прадукцыйнасці прыкладанняў з падтрымкай HDFS, такіх як MapReduce і Spark - час пошуку, чытання, а таксама запісы дадзеных. Гэтыя праблемы пагаршаюцца цяжкасцямі ў кіраванні вялікімі наборамі дадзеных, калі ў нас не фіксаваная, а эвалюцыяніруючая схема, ці прысутнічаюць нейкія абмежаванні на захоўванне.

Апрацоўка вялікіх дадзеных павялічвае нагрузку на падсістэму захоўвання – Hadoop захоўвае дадзеныя залішне для дасягнення адмоваўстойлівасці. Акрамя дыскаў, нагружаюцца працэсар, сетка, сістэма ўводу-вываду і гэтак далей. Па меры росту аб'ёму даных павялічваецца і кошт іх апрацоўкі і захоўвання.

Розныя фарматы файлаў у Hadoop прыдуманы для вырашэння менавіта гэтых праблем. Выбар прыдатнага фармату файла можа даць некаторыя істотныя перавагі:

1. Больш хуткі час чытання.
2. Больш хуткі час запісу.
3. Падзяляюцца файлы.
4. Падтрымка эвалюцыі схем.
5. Пашыраная падтрымка сціску.

Адны фарматы файлаў прызначаны для агульнага выкарыстання, іншыя для больш спецыфічных варыянтаў, а некаторыя распрацаваны з улікам канкрэтных характарыстык дадзеных. Так што выбар сапраўды дастаткова вялікі.

Фармат файлаў Avro

Для серыялізацыі дадзеных шырока выкарыстоўваюць Avro - гэта заснаваны на радках, гэта значыць радковы, фармат захоўвання дадзеных у Hadoop. Ён захоўвае схему ў фармаце JSON, аблягчаючы яе чытанне і інтэрпрэтацыю любой праграмай. Самі дадзеныя ляжаць у двайковым фармаце, кампактна і эфектыўна.

Сістэма серыялізацыі Avro нейтральная да мовы. Файлы можна апрацоўваць рознымі мовамі, зараз гэта C, C++, C#, Java, Python і Ruby.

Ключавой асаблівасцю Avro з'яўляецца надзейная падтрымка схемаў дадзеных, якія змяняюцца з цягам часу, гэта значыць эвалюцыянуюць. Avro разумее змены схемы – выдаленне, даданне ці змена палёў.

Avro падтрымлівае розныя структуры дадзеных. Напрыклад, можна стварыць запіс, які змяшчае масіў, пералічальны тып і падзапіс.

Гэты фармат ідэальна падыходзіць для запісу ў пасадачную (пераходную) зону возера дадзеных (возера дадзеных, або data lake - калекцыя інстансаў для захоўвання розных тыпаў дадзеных у дадатак непасрэдна да крыніц дадзеных).

Дык вось, для запісу ў пасадачную зону возера дадзеных такі фармат лепш за ўсё падыходзіць па наступных прычынах:

1. Дадзеныя з гэтай зоны звычайна счытваюцца цалкам для далейшай апрацоўкі ніжэйстаячымі сістэмамі - і фармат на аснове радкоў у гэтым выпадку больш эфектыўны.
2. Ніжэйстаячыя сістэмы могуць лёгка здабываць табліцы схем з файлаў - не трэба захоўваць схемы асобна ў вонкавым мета-сховішча.
3. Любая змена зыходнай схемы лёгка апрацоўваецца (эвалюцыя схемы).

Фармат файлаў Parquet

Parquet - апенсорсны фармат файлаў для Hadoop, які захоўвае укладзеныя структуры дадзеных у плоскім столбчатым фармаце.

У параўнанні з традыцыйным малым падыходам, Parquet больш эфектыўны з пункту гледжання захоўвання і прадукцыйнасці.

Гэта асабліва карысна для запытаў, якія счытваюць вызначаныя слупкі з шырокай (са шматлікімі слупкамі) табліцы. Дзякуючы фармату файлаў чытаюцца толькі неабходныя слупкі, так што ўвод-вывад зводзіцца да мінімуму.

Невялікі адступ-тлумачэнне: каб лепш зразумець фармат файла Parquet у Hadoop, давайце паглядзім, што такое заснаваны на слупках - гэта значыць слупковы - фармат. У такім фармаце разам захоўваюцца аднатыпныя значэнні кожнага слупка.

Напрыклад, запіс уключае палі ID, Name і Department. У гэтым выпадку ўсе значэнні слупка ID будуць захоўвацца разам, як і значэнні слупка Name і гэтак далей. Табліца атрымае прыкладна такі выгляд:

ID
Імя
аддзел

1
emp1
d1

2
emp2
d2

3
emp3
d3

У радковым фармаце дадзеныя захаваюцца наступным чынам:

1
emp1
d1
2
emp2
d2
3
emp3
d3

У столбчатом фармаце файлаў тыя ж дадзеныя захаваюцца так:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Стаўчаты фармат больш эфектыўны, калі вам трэба запытаць з табліцы некалькі слупкоў. Ён прачытае толькі неабходныя слупкі, таму што яны знаходзяцца па суседстве. Такім чынам, аперацыі ўводу-вываду зводзяцца да мінімуму.

Напрыклад, вам патрэбен толькі слупок NAME. У радковым фармаце кожны запіс у наборы дадзеных трэба загрузіць, разабраць па палях, а затым атрымаць дадзеныя NAME. Стаўчаты фармат дазваляе перайсці непасрэдна да слупка Name, бо ўсе значэнні для гэтага слупка захоўваюцца разам. Не давядзецца сканаваць увесь запіс.

Такім чынам, столбчатый фармат павялічвае прадукцыйнасць запытаў, паколькі для пераходу да патрабаваных слупкоў патрабуецца менш чакай пошуку і скарачаецца колькасць аперацый уводу-высновы, бо адбываецца чытанне толькі патрэбных слупкоў.

Адна з унікальных асаблівасцяў Паркет заключаецца ў тым, што ў такім фармаце ён можа захоўваць дадзеныя з укладзенымі структурамі. Гэта азначае, што ў файле Parquet нават укладзеныя палі можна чытаць па асобнасці без неабходнасці чытаць усе палі ва ўкладзенай структуры. Для захоўвання ўкладзеных структур Parquet выкарыстоўвае алгарытм драбнення і зборкі (shredding and assembly).

Каб зразумець фармат файла Parquet у Hadoop, неабходна ведаць наступныя тэрміны:

1. Група радкоў (row group): лагічнае гарызантальнае разбіццё дадзеных на радкі. Група радкоў складаецца з фрагмента кожнага слупка ў наборы даных.
2. Фрагмент слупка (column chunk): фрагмент канкрэтнага слупка. Гэтыя фрагменты слупкоў жывуць у вызначанай групе радкоў і гарантавана будуць сумежнымі ў файле.
3. Старонка (page): фрагменты слупкоў дзеляцца на старонкі, запісаныя адзін за адным. У старонак агульны загаловак, так што пры чытанні можна прапусціць непатрэбныя.

Тут загаловак проста змяшчае чароўны лік PAR1 (4 байта), якое ідэнтыфікуе файл як файл фармату Parquet.

У футары запісана наступнае:

1. Метададзеныя файла, якія змяшчаюць стартавыя каардынаты метададзеных кожнага слупка. Пры чытанні трэба спачатку прачытаць метададзеныя файла, каб знайсці ўсе цікавыя фрагменты слупкоў. Затым фрагменты слупкоў варта чытаць паслядоўна. Яшчэ метададзеныя ўключаюць версію фармату, схему і любыя дадатковыя пары ключ-значэнне.
2. Даўжыня метададзеных (4 байта).
3. Чароўны лік PAR1 (4 байта).

Фармат файлаў ORC

Аптымізаваны радкова-слупковы фармат файлаў (Optimized Row Columnar, ОРК) прапануе вельмі эфектыўны спосаб захоўвання дадзеных і быў распрацаваны, каб пераадолець абмежаванні іншых фарматаў. Захоўвае дадзеныя ў ідэальна кампактным выглядзе, дазваляючы прапускаць непатрэбныя дэталі - пры гэтым не патрабуе пабудовы вялікіх, складаных або абслугоўваюцца ўручную індэксаў.

Перавагі фармату ORC:

1. Адзін файл на выхадзе кожнай задачы, што памяншае нагрузку на NameNode (вузел імёнаў).
2. Падтрымка тыпаў дадзеных Hive, у тым ліку DateTime, дзесятковыя і складаныя тыпы дадзеных (struct, list, map і union).
3. Адначасовае счытванне аднаго і таго ж файла рознымі працэсамі RecordReader.
4. Магчымасць падзелу файлаў без сканавання на наяўнасць маркераў.
5. Ацэнка максімальна магчымага вылучэння памяці кучы на ​​працэсы чытання/запісы па інфармацыі ў футары файла.
6. Метададзеныя захоўваюцца ў бінарным фармаце серыялізацыі Protocol Buffers, які дазваляе дадаваць і выдаляць палі.

ORC захоўвае калекцыі радкоў у адным файле, а ўсярэдзіне калекцый малыя дадзеныя захоўваюцца ў столбчатом фармаце.

Файл ORC захоўвае групы радкоў, якія завуцца палосамі (stripes) і дапаможную інфармацыю ў футары файла. Postscript у канцы файла змяшчае параметры сціску і памер сціснутага футара.

Па змаўчанні памер паласы складае 250 МБ. За рахунак палос такога вялікага памеру чытанне з HDFS выконваецца больш эфектыўна: вялікімі бесперапыннымі блокамі.

У футары файла запісаны спіс палос у файле, колькасць радкоў на паласу і тып дадзеных кожнага слупка. Тамака жа запісана выніковае значэнне count, min, max і sum па кожным слупку.

Футэр паласы змяшчае каталог месцазнаходжання патоку.

Малыя дадзеныя выкарыстоўваюцца пры сканаванні табліц.

Індэксныя дадзеныя ўключаюць мінімальныя і максімальныя значэнні для кожнага слупка і пазіцыі радкоў у кожным слупку. Індэксы ORC выкарыстоўваюцца толькі для выбару палос і груп радкоў, а не для адказу на запыты.

Параўнанне розных фарматаў файлаў

Avro у параўнанні з Parquet

1. Avro – фармат захоўвання па радках, тады як Parquet захоўвае дадзеныя па слупках.
2. Parquet лепш падыходзіць для аналітычных запытаў, гэта значыць аперацыі чытання і запыт даных значна больш эфектыўна, чым запіс.
3. Аперацыі запісу ў Avro выконваюцца больш эфектыўна, чым у Parquet.
4. Avro больш спела працуе з эвалюцыяй схем. Parquet падтрымлівае толькі даданне схемы, а ў Avro рэалізаваная шматфункцыянальная эвалюцыя, гэта значыць даданне ці змена слупкоў.
5. Parquet ідэальна падыходзіць для запыту падмноства слупкоў у шматкалонкавай табліцы. Avro падыходзіць для аперацый ETL, дзе мы запытваем усе слупкі.

ORC у параўнанні з Parquet

1. Parquet лепш захоўвае ўкладзеныя дадзеныя.
2. ORC лепш прыстасаваны да праштурхоўвання прэдыкатаў (predicate pushdown).
3. ORC падтрымлівае ўласцівасці ACID.
4. ORC лепш сціскае дадзеныя.

Што яшчэ пачытаць па тэме:

1. Аналіз вялікіх дадзеных у воблаку: як кампаніі стаць дата-арыентаванай.
2. Сціплае кіраўніцтва па схемах баз дадзеных.
3. Наш тэлеграм-канал аб лічбавай трансфармацыі.

Крыніца: habr.com