فرمت های فایل در داده های بزرگ: یک برنامه آموزشی مختصر

Weather Deity توسط Remarin

تیم Mail.ru Cloud Solutions پیشنهادات ترجمه مقاله مهندس Rahul Bhatia از Clairvoyant در مورد اینکه چه فرمت های فایلی در داده های بزرگ وجود دارد، رایج ترین ویژگی های فرمت های Hadoop چیست و از کدام فرمت بهتر است استفاده شود.

چرا فرمت های مختلف فایل مورد نیاز است؟

یک گلوگاه عملکرد اصلی برای برنامه های کاربردی دارای HDFS مانند MapReduce و Spark زمان جستجو، خواندن و نوشتن داده ها است. این مشکلات با مشکل در مدیریت مجموعه داده های بزرگ در صورتی که یک طرحواره در حال تکامل به جای ثابت داشته باشیم، یا اگر برخی محدودیت های ذخیره سازی وجود داشته باشد، تشدید می شود.

پردازش داده های بزرگ بار روی زیرسیستم ذخیره سازی را افزایش می دهد - Hadoop داده ها را به صورت اضافی ذخیره می کند تا به تحمل خطا دست یابد. علاوه بر دیسک ها، پردازنده، شبکه، سیستم ورودی/خروجی و غیره بارگذاری می شوند. با افزایش حجم داده ها، هزینه پردازش و ذخیره سازی آن نیز افزایش می یابد.

فرمت های مختلف فایل در هادوپ اختراع شده تا دقیقاً این مشکلات را حل کند. انتخاب فرمت فایل مناسب می تواند مزایای قابل توجهی داشته باشد:

1. زمان خواندن سریعتر
2. زمان ضبط سریعتر
3. فایل های به اشتراک گذاشته شده
4. پشتیبانی از تکامل طرحواره
5. پشتیبانی فشرده سازی گسترده

برخی از فرمت‌های فایل برای استفاده عمومی در نظر گرفته شده‌اند، برخی دیگر برای کاربردهای خاص‌تر، و برخی برای برآوردن ویژگی‌های داده خاص طراحی شده‌اند. بنابراین انتخاب واقعاً بسیار بزرگ است.

فرمت فایل Avro

برای سریال سازی داده ها Avro به طور گسترده ای استفاده می شود - آن بر اساس رشته، یعنی یک فرمت ذخیره سازی داده رشته ای در Hadoop. این طرحواره را در قالب JSON ذخیره می کند و خواندن و تفسیر آن توسط هر برنامه ای را آسان می کند. خود داده ها در قالب باینری، فشرده و کارآمد هستند.

سیستم سریال سازی Avro زبانی خنثی است. فایل‌ها را می‌توان به زبان‌های مختلفی پردازش کرد، در حال حاضر C، C++، C#، Java، Python و Ruby.

یکی از ویژگی های کلیدی Avro پشتیبانی قوی آن از طرحواره های داده ای است که در طول زمان تغییر می کنند، یعنی تکامل می یابند. Avro تغییرات طرحواره را درک می کند - حذف، افزودن یا تغییر فیلدها.

Avro از انواع ساختارهای داده پشتیبانی می کند. به عنوان مثال، می توانید رکوردی ایجاد کنید که حاوی یک آرایه، یک نوع شمارش شده و یک زیر رکورد باشد.

این قالب برای نوشتن در منطقه فرود (انتقال) دریاچه داده ایده آل است (دریاچه داده، یا دریاچه داده - مجموعه ای از نمونه هایی برای ذخیره انواع مختلف داده ها علاوه بر منابع داده به طور مستقیم).

بنابراین، این فرمت برای نوشتن در منطقه فرود دریاچه داده به دلایل زیر مناسب است:

1. داده‌های این منطقه معمولاً برای پردازش بیشتر توسط سیستم‌های پایین دستی به‌طور کامل خوانده می‌شوند - و یک قالب مبتنی بر ردیف در این مورد کارآمدتر است.
2. سیستم‌های پایین‌دستی می‌توانند به راحتی جداول طرحواره را از فایل‌ها بازیابی کنند—نیازی به ذخیره طرح‌واره‌ها به طور جداگانه در حافظه خارجی متا نیست.
3. هر گونه تغییر در طرحواره اصلی به راحتی پردازش می شود (تکامل طرحواره).

فرمت فایل پارکت

Parquet یک فرمت فایل منبع باز برای Hadoop است که ذخیره می کند ساختارهای داده تو در تو در قالب ستونی مسطح.

در مقایسه با روش سنتی ردیفی، پارکت از نظر ذخیره سازی و عملکرد کارآمدتر است.

این به ویژه برای پرس و جوهایی که ستون های خاصی را از یک جدول عریض (ستون های متعدد) می خوانند مفید است. به لطف فرمت فایل، تنها ستون های لازم خوانده می شوند، بنابراین I/O به حداقل می رسد.

یک انحراف و توضیح کوچک: برای درک بهتر فرمت فایل Parquet در Hadoop، بیایید ببینیم فرمت مبتنی بر ستون - یعنی ستونی - چیست. این قالب مقادیر مشابهی را برای هر ستون با هم ذخیره می کند.

مثلا، رکورد شامل فیلدهای شناسه، نام و بخش می باشد. در این حالت، تمام مقادیر ستون 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

قالب ستونی زمانی کارآمدتر است که شما نیاز به پرس و جو چند ستون از یک جدول دارید. این فقط ستون های مورد نیاز را می خواند زیرا آنها در مجاورت یکدیگر هستند. به این ترتیب، عملیات I/O به حداقل ممکن می رسد.

به عنوان مثال، شما فقط به ستون NAME نیاز دارید. که در قالب رشته هر رکورد در مجموعه داده باید بارگیری شود، توسط فیلد تجزیه شود و سپس داده های NAME استخراج شود. قالب ستون به شما امکان می دهد مستقیماً به ستون Name بروید زیرا تمام مقادیر آن ستون با هم ذخیره می شوند. لازم نیست کل ضبط را اسکن کنید.

بنابراین، قالب ستونی عملکرد پرس و جو را بهبود می بخشد زیرا به زمان جستجوی کمتری برای رسیدن به ستون های مورد نیاز نیاز دارد و تعداد عملیات I/O را کاهش می دهد زیرا فقط ستون های مورد نظر خوانده می شوند.

یکی از ویژگی های منحصر به فرد با چوب فرش کردن این است که در این قالب می تواند ذخیره داده ها با ساختارهای تودرتو. این بدان معنی است که در یک فایل Parquet، حتی فیلدهای تودرتو را نیز می توان به صورت جداگانه خواند بدون نیاز به خواندن تمام فیلدهای ساختار تودرتو. پارکت از الگوریتم خرد کردن و مونتاژ برای ذخیره سازه های تو در تو استفاده می کند.

برای درک فرمت فایل پارکت در Hadoop، باید اصطلاحات زیر را بدانید:

1. گروه ردیف (گروه ردیف): تقسیم افقی منطقی داده ها به ردیف. یک گروه ردیف از یک قطعه از هر ستون در مجموعه داده تشکیل شده است.
2. قطعه ستون (تکه ستون): قطعه ای از یک ستون خاص. این قطعات ستون در یک گروه خاص از ردیف ها زندگی می کنند و تضمین شده است که در فایل به هم پیوسته هستند.
3. صفحه (صفحه): قطعات ستون به صفحاتی که پشت سر هم نوشته می شوند تقسیم می شوند. صفحات دارای عنوان مشترکی هستند، بنابراین می توانید از موارد غیر ضروری هنگام خواندن صرف نظر کنید.

در اینجا عنوان فقط حاوی عدد جادویی است PAR1 (4 بایت) که فایل را به عنوان فایل پارکت شناسایی می کند.

پاورقی چنین می گوید:

1. فراداده فایلی که حاوی مختصات ابتدایی ابرداده هر ستون است. هنگام خواندن، ابتدا باید ابرداده فایل را بخوانید تا تمام قطعات ستون مورد علاقه را پیدا کنید. سپس بخش های ستون باید به صورت متوالی خوانده شوند. سایر ابرداده ها شامل نسخه قالب، طرحواره و هر جفت کلید-مقدار اضافی است.
2. طول ابرداده (4 بایت).
3. عدد جادویی PAR1 (4 بایت).

فرمت فایل ORC

فرمت فایل ردیف-ستون بهینه شده (ستون ردیف بهینه شده، CRO) یک روش بسیار کارآمد برای ذخیره داده ها ارائه می دهد و برای غلبه بر محدودیت های فرمت های دیگر طراحی شده است. داده‌ها را به شکلی کاملا فشرده ذخیره می‌کند و به شما امکان می‌دهد از جزئیات غیرضروری صرفنظر کنید - بدون نیاز به ساخت فهرست‌های بزرگ، پیچیده یا دستی.

مزایای فرمت ORC:

1. یک فایل خروجی هر کار است که بار روی NameNode (گره نام) را کاهش می دهد.
2. پشتیبانی از انواع داده های Hive، از جمله DateTime، اعشاری و انواع داده های پیچیده (struct، لیست، نقشه و اتحادیه).
3. خواندن همزمان یک فایل توسط فرآیندهای RecordReader مختلف.
4. امکان تقسیم فایل ها بدون اسکن برای نشانگرها.
5. تخمین حداکثر تخصیص حافظه هیپ ممکن برای فرآیندهای خواندن/نوشتن بر اساس اطلاعات موجود در فوتر فایل.
6. متادیتا در قالب سریال سازی باینری Protocol Buffers ذخیره می شود که امکان افزودن و حذف فیلدها را فراهم می کند.

ORC مجموعه‌ای از رشته‌ها را در یک فایل ذخیره می‌کند و در داخل مجموعه، داده‌های رشته‌ای در قالب ستونی ذخیره می‌شوند.

یک فایل ORC گروه هایی از خطوط به نام نوار و اطلاعات پشتیبان را در فوتر فایل ذخیره می کند. Postscript در انتهای فایل شامل پارامترهای فشرده سازی و اندازه پاورقی فشرده شده است.

اندازه نوار پیش فرض 250 مگابایت است. با توجه به چنین نوارهای بزرگ، خواندن از HDFS کارآمدتر انجام می شود: در بلوک های بزرگ به هم پیوسته.

پاورقی فایل لیست خطوط در فایل، تعداد سطرها در هر خط و نوع داده هر ستون را ثبت می کند. مقدار حاصل از count، min، max و sum برای هر ستون نیز در آنجا نوشته شده است.

پاورقی نوار حاوی فهرستی از مکان‌های جریان است.

هنگام اسکن جداول از داده های ردیف استفاده می شود.

داده های شاخص شامل حداقل و حداکثر مقادیر برای هر ستون و موقعیت سطرها در هر ستون است. شاخص‌های ORC فقط برای انتخاب نوارها و گروه‌های ردیف استفاده می‌شوند، نه برای پاسخ دادن به پرس و جوها.

مقایسه فرمت های مختلف فایل

Avro در مقایسه با پارکت

1. Avro یک فرمت ذخیره سازی ردیف است، در حالی که Parquet داده ها را در ستون ها ذخیره می کند.
2. پارکت برای پرس و جوهای تحلیلی مناسب تر است، به این معنی که عملیات خواندن و داده های پرس و جو بسیار کارآمدتر از نوشتن هستند.
3. عملیات نوشتن در Avro کارآمدتر از پارکت انجام می شود.
4. Avro با تکامل مدارها به طور بالغ‌تر سروکار دارد. پارکت فقط از افزودن طرحواره پشتیبانی می کند، در حالی که Avro از تکامل چند منظوره، یعنی افزودن یا تغییر ستون ها پشتیبانی می کند.
5. پارکت برای پرس و جو زیر مجموعه ای از ستون ها در جدول چند ستونی ایده آل است. Avro برای عملیات ETL مناسب است که در آن همه ستون ها را پرس و جو می کنیم.

ORC در مقابل پارکت

1. پارکت داده های تودرتو را بهتر ذخیره می کند.
2. ORC برای گزاره pushdown مناسب تر است.
3. ORC از ویژگی های ACID پشتیبانی می کند.
4. ORC داده ها را بهتر فشرده می کند.

چه چیز دیگری در مورد موضوع بخوانید:

1. تجزیه و تحلیل کلان داده در ابر: چگونه یک شرکت می تواند داده گرا شود.
2. راهنمای فروتن برای طرحواره های پایگاه داده.
3. کانال تلگرام ما در مورد تحول دیجیتال.

منبع: www.habr.com