Том өгөгдөл дэх файлын формат: товч боловсролын хөтөлбөр

Ремарины "Цаг агаарын бурхан"

баг Mail.ru үүлэн шийдэл санал болгодог нийтлэлийн орчуулга Clairvoyant-ын инженер Рахул Бхатиа том өгөгдөлд ямар файлын формат байдаг, Hadoop форматын хамгийн түгээмэл шинж чанарууд юу вэ, аль форматыг ашиглах нь илүү дээр вэ.

Яагаад өөр файлын формат хэрэгтэй байна вэ?

MapReduce болон Spark зэрэг HDFS-ийг дэмждэг програмуудын гүйцэтгэлийн гол бэрхшээл бол өгөгдөл хайх, унших, бичихэд зарцуулдаг хугацаа юм. Хэрэв бид тогтмол биш харин хөгжиж буй схемтэй эсвэл хадгалалтын зарим хязгаарлалттай бол том өгөгдлийн багцыг удирдахад бэрхшээлтэй байдаг тул эдгээр асуудлууд улам бүр нэмэгддэг.

Том өгөгдлийг боловсруулах нь хадгалах дэд системийн ачааллыг нэмэгдүүлдэг - Hadoop нь алдааг тэсвэрлэхийн тулд өгөгдлийг дахин хадгалдаг. Дискүүдээс гадна процессор, сүлжээ, оролт/гаралтын систем гэх мэт ачаалагддаг. Өгөгдлийн хэмжээ өсөхийн хэрээр түүнийг боловсруулах, хадгалах зардал нэмэгддэг.

Төрөл бүрийн файлын формат Hadoop Эдгээр асуудлыг яг таг шийдэхийн тулд зохион бүтээсэн. Тохиромжтой файлын форматыг сонгох нь хэд хэдэн чухал ач холбогдолтой:

1. Илүү хурдан унших хугацаа.
2. Илүү хурдан бичлэг хийх хугацаа.
3. Хуваалцсан файлууд.
4. Схемийн хувьслыг дэмжих.
5. Өргөтгөсөн шахалтын дэмжлэг.

Зарим файлын формат нь ерөнхий хэрэглээнд зориулагдсан, бусад нь илүү тодорхой хэрэглээнд зориулагдсан, зарим нь тодорхой өгөгдлийн шинж чанарыг хангахад зориулагдсан байдаг. Тиймээс сонголт нь үнэхээр том юм.

Avro файлын формат

Хэрэгтэй өгөгдлийг цуваа болгох Авро өргөн хэрэглэгддэг - энэ нь мөрөнд суурилсан, өөрөөр хэлбэл Hadoop дахь мөрийн өгөгдөл хадгалах формат. Энэ нь схемийг JSON форматаар хадгалдаг бөгөөд үүнийг ямар ч програмаар уншиж, тайлбарлахад хялбар болгодог. Өгөгдөл нь өөрөө хоёртын форматтай, авсаархан, үр дүнтэй байдаг.

Avro-ийн цуваа систем нь хэлний төвийг сахисан байдаг. Файлуудыг C, C++, C#, Java, Python болон Ruby зэрэг янз бүрийн хэлээр боловсруулах боломжтой.

Avro-ийн гол онцлог нь цаг хугацааны явцад өөрчлөгддөг, өөрөөр хэлбэл өөрчлөгддөг өгөгдлийн схемийг найдвартай дэмждэг. Avro нь схемийн өөрчлөлтийг ойлгодог - талбаруудыг устгах, нэмэх эсвэл өөрчлөх.

Avro нь олон төрлийн өгөгдлийн бүтцийг дэмждэг. Жишээлбэл, та массив, тоологдсон төрөл, дэд бичлэг агуулсан бичлэг үүсгэж болно.

Энэ формат нь дата нуурын буух (шилжилтийн) бүсэд бичихэд тохиромжтой.мэдээллийн нуур, эсвэл өгөгдлийн нуур - мэдээллийн эх үүсвэрээс гадна янз бүрийн төрлийн өгөгдлийг хадгалах жишээнүүдийн цуглуулга).

Иймд энэ формат нь дараах шалтгааны улмаас дата нуурын буух бүсэд бичихэд хамгийн тохиромжтой.

1. Энэ бүсийн өгөгдлийг ихэвчлэн доод урсгалын системүүд боловсруулахын тулд бүхэлд нь уншдаг бөгөөд энэ тохиолдолд эгнээнд суурилсан формат нь илүү үр дүнтэй байдаг.
2. Доод урсгалын системүүд нь схемийн хүснэгтийг файлуудаас хялбархан татаж авах боломжтой - схемүүдийг гадаад мета санд тусад нь хадгалах шаардлагагүй.
3. Анхны схемийн аливаа өөрчлөлтийг хялбархан боловсруулдаг (схемийн хувьсал).

Паркетан файлын формат

Паркет бол хадгалдаг Hadoop-д зориулсан нээлттэй эхийн файлын формат юм Хавтгай багана хэлбэрээр үүрлэсэн өгөгдлийн бүтэц.

Уламжлалт эгнээний аргатай харьцуулахад Паркет нь хадгалалт, гүйцэтгэлийн хувьд илүү үр дүнтэй байдаг.

Энэ нь ялангуяа өргөн (олон багана) хүснэгтээс тодорхой баганыг уншдаг асуулгад хэрэгтэй. Файлын форматын ачаар зөвхөн шаардлагатай багануудыг уншдаг тул I/O-ийг хамгийн бага хэмжээнд байлгадаг.

Жижиг тойм, тайлбар: Hadoop дахь Паркетын файлын форматыг илүү сайн ойлгохын тулд баганад суурилсан, өөрөөр хэлбэл, багана хэлбэрийн формат гэж юу болохыг харцгаая. Энэ формат нь багана бүрийн ижил утгыг хамтад нь хадгалдаг.

Жишээ нь, бичлэг нь ID, Нэр, Хэлтсийн талбаруудыг агуулна. Энэ тохиолдолд бүх ID баганын утгууд Нэр баганын утгууд гэх мэт хамт хадгалагдах болно. Хүснэгт нь иймэрхүү харагдах болно.

ID
нэр
газар

1
Эмп1
d1

2
Эмп2
d2

3
Эмп3
d3

Мөр форматаар өгөгдөл дараах байдлаар хадгалагдана.

1
Эмп1
d1
2
Эмп2
d2
3
Эмп3
d3

Багана файлын форматаар ижил өгөгдөл дараах байдлаар хадгалагдана:

1
2
3
Эмп1
Эмп2
Эмп3
d1
d2
d3

Хүснэгтээс олон баганыг асуух шаардлагатай үед багана хэлбэр нь илүү үр дүнтэй байдаг. Энэ нь зэргэлдээ байгаа тул зөвхөн шаардлагатай багануудыг унших болно. Ийм байдлаар оролт гаралтын ажиллагааг хамгийн бага хэмжээнд байлгадаг.

Жишээлбэл, танд зөвхөн NAME багана хэрэгтэй. IN мөр формат Өгөгдлийн багц дахь бичлэг бүрийг ачаалж, талбараар задлан шинжилж, дараа нь NAME өгөгдлийг задлах шаардлагатай. Баганын формат нь тухайн баганын бүх утгыг хамтад нь хадгалдаг тул Нэр багана руу шууд орох боломжийг олгодог. Та бүх бичлэгийг сканнердах шаардлагагүй.

Тиймээс, багана хэлбэр нь шаардлагатай баганууд руу ороход хайх хугацаа бага шаардагдах тул асуулгын гүйцэтгэлийг сайжруулж, зөвхөн хүссэн багануудыг уншдаг тул I/O үйлдлийн тоог багасгадаг.

Өвөрмөц шинж чанаруудын нэг Паркет Энэ форматтай байж болно үүрлэсэн бүтэцтэй өгөгдлийг хадгалах. Энэ нь Паркет файлын доторх бүх талбарыг унших шаардлагагүйгээр үүрлэсэн талбаруудыг тусад нь унших боломжтой гэсэн үг юм. Паркет нь үүрлэсэн бүтцийг хадгалахын тулд хэрчиж, угсрах алгоритмыг ашигладаг.

Hadoop дахь паркет файлын форматыг ойлгохын тулд та дараах нэр томъёог мэдэх хэрэгтэй.

1. Мөрийн бүлэг (мөрний бүлэг): өгөгдлийг эгнээ болгон логик хэвтээ хуваах. Мөрийн бүлэг нь өгөгдлийн багц дахь багана бүрийн фрагментээс бүрдэнэ.
2. Баганын фрагмент (баганын хэсэг): Тодорхой баганын фрагмент. Эдгээр баганын хэсгүүд нь тодорхой бүлэг эгнээнд амьдардаг бөгөөд файлд залгаа байх нь баталгаатай.
3. Хуудас (хуудас): Баганын хэсгүүд нь ар араасаа бичигдсэн хуудсанд хуваагдана. Хуудсууд нь нийтлэг гарчигтай тул уншихдаа шаардлагагүй зүйлсийг алгасаж болно.

Энд гарчиг нь зөвхөн шидэт тоог агуулдаг PAR1 (4 байт) нь файлыг Паркет файл гэж тодорхойлдог.

Хөлийн хэсэг нь дараахь зүйлийг хэлнэ.

1. Багана бүрийн мета өгөгдлийн эхлэлийн координатыг агуулсан файлын мета өгөгдөл. Уншихдаа та эхлээд сонирхож буй бүх баганын хэсгүүдийг олохын тулд файлын мета өгөгдлийг унших ёстой. Дараа нь баганын хэсгүүдийг дараалан унших хэрэгтэй. Бусад мета өгөгдөлд форматын хувилбар, схем болон нэмэлт түлхүүр-утга хосууд орно.
2. Мета өгөгдлийн урт (4 байт).
3. Шидэт тоо PAR1 (4 байт).

ORC файлын формат

Мөр баганын файлын форматыг оновчтой болгосон (Оновчилсон мөр багана, CRO) нь өгөгдөл хадгалах маш үр дүнтэй аргыг санал болгодог бөгөөд бусад форматын хязгаарлалтыг даван туулах зорилготой юм. Өгөгдлийг маш нягт хэлбэрээр хадгалдаг бөгөөд энэ нь танд шаардлагагүй нарийн ширийн зүйлийг алгасах боломжийг олгодог - том, нарийн төвөгтэй эсвэл гараар хөтлөх индексийг бүтээх шаардлагагүй.

ORC форматын давуу талууд:

1. Нэг файл нь ажил бүрийн гаралт бөгөөд NameNode (нэрийн зангилаа) дээрх ачааллыг бууруулдаг.
2. DateTime, аравтын болон нарийн төвөгтэй өгөгдлийн төрлүүд (бүтэц, жагсаалт, газрын зураг, нэгдэл) зэрэг Hive өгөгдлийн төрлүүдийн дэмжлэг.
3. Өөр өөр RecordReader процессоор нэг файлыг нэгэн зэрэг унших.
4. Тэмдэглэгч хайхгүйгээр файлуудыг хуваах чадвар.
5. Файлын хөл хэсэгт байгаа мэдээлэлд үндэслэн унших/бичих процессуудад зориулсан хамгийн их санах ойн хуваарилалтын тооцоо.
6. Мета өгөгдөл нь Protocol Buffers хоёртын цуваа форматаар хадгалагддаг бөгөөд энэ нь талбаруудыг нэмэх, устгах боломжийг олгодог.

ORC нь мөрийн цуглуулгыг нэг файлд хадгалдаг бөгөөд цуглуулгын дотор мөрийн өгөгдлийг багана хэлбэрээр хадгалдаг.

ORC файл нь судал гэж нэрлэгддэг шугамын бүлгүүд болон файлын доод хэсэгт туслах мэдээллийг хадгалдаг. Файлын төгсгөлд байгаа Postscript нь шахалтын параметрүүд болон шахсан хөлийн хэмжээг агуулна.

Анхдагч зурвасын хэмжээ нь 250 MB байна. Ийм том судалтай тул HDFS-ээс унших нь илүү үр дүнтэй байдаг: том зэргэлдээ блокуудад.

Файлын хөл хэсэгт файлын эгнээний жагсаалт, эгнээ тус бүрийн мөрийн тоо, багана бүрийн өгөгдлийн төрлийг бүртгэдэг. Багана тус бүрийн тоо, мин, макс, нийлбэрийн үр дүнгийн утгыг мөн тэнд бичнэ.

Туузны доод хэсэг нь урсгалын байршлын лавлахыг агуулна.

Хүснэгтийг сканнердахдаа мөрийн өгөгдлийг ашигладаг.

Индекс өгөгдөл нь багана бүрийн хамгийн бага ба хамгийн их утгууд, багана тус бүрийн мөрүүдийн байрлалыг агуулдаг. ORC индексийг зөвхөн судлууд болон мөрийн бүлгүүдийг сонгоход ашигладаг бөгөөд асуулгад хариулдаггүй.

Төрөл бүрийн файлын форматыг харьцуулах

Паркетантай харьцуулахад Авро

1. Avro нь мөр хадгалах формат бөгөөд Паркет нь өгөгдлийг баганад хадгалдаг.
2. Паркет нь аналитик асуулгад илүү тохиромжтой, өөрөөр хэлбэл унших үйлдлүүд болон асуулга нь бичихээс хамаагүй илүү үр дүнтэй байдаг.
3. Avro дээр бичих үйлдлүүд нь Паркетанаас илүү үр дүнтэй байдаг.
4. Avro хэлхээний хувьслыг илүү боловсронгуй байдлаар авч үздэг. Паркет нь зөвхөн схем нэмэхийг дэмждэг бол Avro нь олон үйлдэлт хувьсал, өөрөөр хэлбэл багана нэмэх эсвэл өөрчлөхийг дэмждэг.
5. Паркет нь олон баганатай хүснэгтийн баганын дэд багцыг асуухад тохиромжтой. Avro нь бүх баганыг асуудаг ETL үйл ажиллагаанд тохиромжтой.

ORC эсрэг Паркетан

1. Паркет нь үүрлэсэн өгөгдлийг илүү сайн хадгалдаг.
2. ORC нь түлхэц өгөхөд илүү тохиромжтой.
3. ORC нь ACID шинж чанарыг дэмждэг.
4. ORC нь өгөгдлийг илүү сайн шахдаг.

Энэ сэдвээр өөр юу унших вэ:

1. Үүлэн дэх том өгөгдлийн шинжилгээ: компани хэрхэн өгөгдөлд чиглэсэн болох вэ.
2. Өгөгдлийн сангийн схемд зориулсан даруухан гарын авлага.
3. Дижитал өөрчлөлтийн тухай манай телеграм суваг.

Эх сурвалж: www.habr.com