Я планую використовувати один із форматів файлів hadoop для свого проекту, пов’язаного з hadoop. Я розумію, що паркет ефективний для запитів на основі стовпців, а avro для повного сканування або коли нам потрібні всі дані стовпців!
Перш ніж продовжити і вибрати один із форматів файлів, я хочу зрозуміти, у чому недоліки / недоліки одного над іншим. Хто-небудь може пояснити мені це простими словами?
Відповіді:
Якщо ви ще не вирішили, я піду і напишу схеми Avro для ваших даних. Після цього вибір між файлами контейнерів Avro та файлами паркету буде настільки ж простим, як і обмін, наприклад,
job.setOutputFormatClass(AvroKeyOutputFormat.class);
AvroJob.setOutputKeySchema(MyAvroType.getClassSchema());
для
job.setOutputFormatClass(AvroParquetOutputFormat.class);
AvroParquetOutputFormat.setSchema(job, MyAvroType.getClassSchema());
Формат Parquet, здається, дещо обчислювально більший на стороні запису - наприклад, вимагає оперативної пам’яті для буферизації та процесора для впорядкування даних тощо, але він повинен зменшити витрати на введення-виведення, зберігання та передачу, а також забезпечити ефективність читає особливо з SQL-подібними (наприклад, Hive або SparkSQL) запитами, які адресують лише частину стовпців.
В одному проекті я в підсумку повернувся з паркету на контейнери Avro, оскільки схема була занадто обширна і вкладена (похідна з деяких досить ієрархічних об’єктно-орієнтованих класів) і призвела до 1000 стовпців паркету. У свою чергу, наші групи рядків були дійсно широкими та дрібними, що означало, що знадобилося вічно, перш ніж ми змогли обробити невелику кількість рядків в останньому стовпці кожної групи.
У мене ще не було великих шансів використовувати Parquet для більш нормалізованих / розумних даних, але я розумію, що якщо він використовується добре, це дозволяє значно покращити продуктивність.
Avro - це формат, заснований на рядках. Якщо ви хочете отримати дані в цілому, ви можете використовувати Avro
Паркет - це формат на основі стовпців. Якщо ваші дані складаються з великої кількості стовпців, але вас цікавить підмножина стовпців, тоді ви можете використовувати паркет
HBase корисна, коли потрібно часто оновлювати дані. Avro швидкий у пошуку, паркет набагато швидший.
Авро
Паркет
Від вибору формату зберігання даних HDFS - Avro проти Parquet та багато іншого
Як Avro, так і Parquet мають "самоописувані" формати зберігання, що означає, що обидва вбудовують дані, інформацію про метадані та схему при зберіганні даних у файлі. Використання будь-якого з форматів зберігання залежить від випадку використання. Три аспекти складають основу, на якій ви можете вибрати, який формат буде оптимальним у вашому випадку:
Операція читання / запису : паркет - це формат файлу на основі стовпців. Він підтримує індексацію. Через це він підходить для одноразового запису та інтенсивного читання, складних або аналітичних запитів, запитів даних із низькою затримкою. Зазвичай цим користуються кінцеві користувачі / науковці даних.
Тим часом Avro, будучи рядковим форматом файлу, найкраще використовувати для інтенсивної роботи. Зазвичай цим користуються інженери даних. Обидва підтримують формати серіалізації та стиснення, хоча вони роблять це по-різному.
Інструменти : Паркет добре підходить для Impala. (Impala - це механізм масової паралельної обробки (MPP) RDBM SQL-запит, який знає, як працювати з даними, що знаходяться в одному або кількох зовнішніх механізмах зберігання даних.) Знову ж таки, Parquet добре підходить для складних / інтерактивних запитів та швидких (низька затримка) ) виводить дані в HDFS. Це підтримується CDH (Cloudera Distribution Hadoop). Hadoop підтримує формати оптимізованого рядка Apache (ORC) (вибір залежить від розподілу Hadoop), тоді як Avro найкраще підходить для обробки іскр.
Еволюція схеми : Розробка схеми БД означає зміну структури БД, отже, її даних, а отже, і обробки запитів.
І Parquet, і Avro підтримують еволюцію схеми, але в різному ступені.
Паркет хороший для операцій "додавання", наприклад, додавання стовпців, але не для перейменування стовпців, якщо "читання" не виконується індексом.
Avro краще підходить для додавання, видалення та взагалі мутації стовпців, ніж паркет. Історично Avro надав багатший набір можливостей еволюції схеми, ніж Parquet, і хоча їх можливості еволюції схеми, як правило, розмиваються, Avro все ще блищить у цій області, порівняно з Parquet.
Ваше розуміння правильне. Насправді ми потрапили в подібну ситуацію під час міграції даних у нашому DWH. Ми вибрали Parquet замість Avro, оскільки економія диска була майже вдвічі більшою, ніж у AVro. Крім того, час обробки запитів був набагато кращим, ніж Avro. Але так, наші запити базувались на агрегуванні, операціях на основі стовпців тощо, отже, паркет, як можна було очікувати, був явним переможцем.
Ми використовуємо Hive 0,12 від дистрибутиву CDH. Ви згадали, що стикаєтесь із проблемами з Вуликом + Паркет, що це? Ми не зустрічали жодного.
Silver Blaze красиво описав опис із прикладом використання та описав, як Parquet був найкращим вибором для нього. Є сенс розглядати одне над іншим залежно від ваших вимог. Я також подаю короткий опис різних інших форматів файлів, а також порівняння складності часового простору. Сподіваюся, що це допомагає.
Існує купа форматів файлів, які ви можете використовувати в Hive. Примітні згадки про AVRO, паркет. RCFile & ORC. В Інтернеті є кілька хороших документів, на які ви можете звернутися, якщо хочете порівняти продуктивність та використання простору цих форматів файлів. Переходить за деякими корисними посиланнями, які допоможуть вам розпочати роботу.
Це посилання від MapR [Хоча паркет вони не обговорюють]
Наведені вище посилання змусять вас працювати. Сподіваюся, це відповість на ваш запит.
Дякую!
Лише для опису паркету ви можете звернутися тут: http://bigdata.devcodenote.com/2015/04/parquet-file-format.html
Я маю намір писати дуже скоро про Avro та порівняння між 2. Опублікую це тут, коли це буде зроблено.