Какой формат файла будет самым компактным занимать меньше места на диске при одинаковом содержании
Копия ахивного файла RAR, сделанная с жесткого диска на новый съемный носитель micro SDHC CARD, занимает немного больше места. Т.е. копия файла имеет размер такой же, что и оригинал, но места занимает больше. Это допустимо? И почему так бывает?
- На винчестере включено сжатие файлов. Соответственно, сам файл на NTFS партиции будет занимать немного меньше места, чем на другом носителе и при копировании он разжимается самой ОС на лету.
- Присутствие вируса, который добавляет свое тело в файл при его копировании, тем самым, увеличивая его размер.
системное сжатие самой ОС работает по другому принципу, чем сжатие по архивным технологиям (rar, zip и т.п.) и может сэкономить еще до 15% места даже на rar файлах. — 7 лет назад
Место, занимаемое файлом на носителе, зависит не только от его размера, но и от носителя, файловой системы его и размера кластеров на нём. В нежурналируемых файловых системах, например FAT и NTFS, размер кластера зависит от размера раздела. Если размер кластера, например, 1 Mb, то именно это место и займёт файл длиной хоть в и 1 Kb. Файлы пишутся в кластеры, и в последнем из таких остаётся пустое место, которое уже не используется.
В журналируемых файловых системах (Ext3, Ext4, ReiserFS, Reiser4, JFS, XFS, HFS) дело обстоит по другому - там кластеры различной длины и файлы пишутся изначально в самые длинные кластеры, в которые помещаются не целиком, а потом всё в меньшие и меньшие, а хвостик - в самых короткий из них. Там пространство носителя используется намного эффективнее. Но эти файловые системы понимают не все ОС, в том числе и Windows. Linux, Solaris, FreeBSD, MacOS понимают их все или почти все. Моя ОС понимает все.
Поэтому хорошей идеей переносные носители иметь отформатированными в формате FAT32. Это гарантирует то, что информация будет доступна в любой ОС. Но это очень старая система и менее эффективно использует пространство носителя даже, чем NTFS, с которой, обычно, работает Windows. Как следствие, файл, переписанный с носителя с любой из других файловых систем, особенно, журналируемых, на носителе с файловой системой FAT будет занимать больше места.
Открываете Ваше фото в стандартной программе Paint. Жмете ФАЙЛ - СОХРАНИТЬ КАК.. . и пишите новое имя (что бы не портить основное фото) . Можно просто в конце названия ставить букву R (будете знать что фото для рамки) . Закройте программу Paint. Посмотрите размер основного фото и пересохраненного. Потерю качества на глаз Вы и не увидите .
jpg и так уже упакованный формат.. . куда уже меньше-то ?
ну, размер самой картинки уменьши: ширину-высоту
открой с помощью point, там есть опция количество точек, там и выбери нужный формат (объем) , ТАК ДЕЛАЛ НЕДАВНО НА ЗАГРАНПАСПОРТ
В тот же, но можно увеличить сжатие. Есть два способа, либо сжать больше сразу (например, через Фотошоп) или много раз пересохранить. Размер уменьшится, но и качество упадёт существенно.
Подгони размер в пикселях под разрешение фоторамки, ну и сжать сильнее, чтобы артефактами любоваться по самое не могу.
Есть предложение:
Пересылаете мне одну из картинок, пересылаете название фоторамки, я нахожу её параметры, преобразовываю Ваш файл, описываю, что я сделал и пересылаю Вам. Вы делаете то-же самое с остальными картинками.
Уважаемый, джипег и так уже формат из категории "хуже некуда".
У нас дома на двух совершенно разных рамках все прекрасно шло без преобразований. Но если будете уменьшать фото, портите хотя бы копии. Ибо вернуть качество назад будет уже нельзя.
варианты порчи:
- тот же джипег но качеством ниже (выбор при сохранении)
- тот же джипег но разрешением ниже
- тот же джипег но размером меньше
Формат менять не надо. Надо поменять разрешение фотографии. Например 640х480. Это умеют делать многие фоторедакторы.
откройте фото в фотошопе, а потом сохраните с помощью команды меню Сохранить для веб и устройств
там имеется возможность одновременного просмотра нескольких вариантов изображения и изменения их настроек оптимизации для выбора наилучшего сочетания параметров в соответствии с требованиями
например фото размером 5мб можно ужать таким образом до 1мб и на фоторамке вы особых изменений не увидите.
ты хочешь сделать свои фотки говнофотками, на которых трудно что-то разобрать? ?
Пути два
1) уменьшить разрешение фотки. Она тогда будет квадратиками. Если уменьшить достаточно сильно. Квадратики будут лучше заметны при увеличении (а потом выставишь их в интеренет, и нас будут спрашивать как сделать эффект квадратиов)
2) усилить сжатие. что бы вокруг объектов появилась грязь
Прежде всего скажем, что речь здесь пойдет о файловых системах FAT и NTFS, как наиболее распространенных, и ничего не будет сказано о файловых системах, используемых в не-Windows системах, поскольку такие системы лежат вне сферы интересов автора. А теперь – к делу.
Казалось бы, какая неоднозначность может быть, если говорить о размере файла. Сколько в него данных записали, такой и размер (или длина). Сколько в нем есть байтов от начала до конца (и это число записано в файловой системе в качестве размера файла), такой и размер, не так ли? Как говорил Шельменко-денщик, так то оно так, да только трошечки не так.
Проведите эксперимент. Возьмите любой исполняемый файл и выполните его копирование командой
copy что-то.exe что-то-другое.exe
Если вы раньше с этим сталкивались, то уже знаете, что результирующий файл получится намного короче исходного и не будет копией. Причина простая: программа copy, запущенная без параметра /b, копирует файл до тех пор, пока не встретит байт с кодом 27h, этот символ называется «конец файла».
Итак, у нас уже есть два разных признака конца файла – по числу, записанному в файловой системе, и по специальному байту в теле файла. Правда, стоит отметить, что второй признак остался с тех времен, когда файлы были преимущественно текстовыми и сейчас практически не применяется.
В файловых системах, использующих кластеры, а FAT и NTFS относятся именно к таким ФС, есть еще третий размер – размер файла на диске, то есть суммарный размер кластеров, отведенных этому файлу. В файловых системах FAT этот размер больше размера собственно файла или равен ему. Разница между размерами, если она есть, – так называемый хвост файла – это напрасно пропадающее место на диске, плата за размещение файлов по кластерам, а не встык друг за другом, хотя файловые системы с таким размещением файлов тоже существуют.
Впрочем, иногда это место используется. В частности, во времена дискет существовали программы, которые позволяли записывать данные в хвосты файлов, чтобы скрытно передать на таких дискетах информацию. Ведь стандартными средствами получить доступ к хвостам файлов нельзя.
Если включить в рассмотрение NTFS, то картина дополнится новыми штрихами.
Прежде всего, размер файла на диске может оказаться меньше собственно размера файла.
Если тело файла помещается в свободную область файловой записи MFT, то этот файл не занимает на диске ни одного кластера.
Максимальный размер такого файла зависит от размера записи и составляет примерно 600 байтов для записи мелкого размера (1 Кб) и 3600 – для записи крупного размера (4 Кб). Следует, впрочем, отметить, что до недавнего времени Windows показывала размер такого файла на диске равным одному кластеру, хотя фактически ни одного кластера файлу не выделено.
Если файл сжат, то его размер на диске может быть заметно меньше собственно длины файла (количества данных в нем).
Дополнительно усложняют картину так называемые разреженные файлы. В них полезные данные содержаться только в определенных участках файла, а остальная часть файла не используется вовсе. Возьмем в качестве примера файл журнала изменений \$Extend\$UsnJrnl, имеющийся почти на каждом компьютере (не пытайтесь увидеть его в проводнике или других диспетчерах файлов, не получится).
Он может иметь длину несколько гигабайт, но значимых данных содержит при этом обычно только 32 мегабайта в самом конце. А остальная часть вообще никаких данных не содержит, места на диске не занимает, и при попытке прочитать данные из этой части система выдаст набор нулей, даже не обращаясь к диску.
Если у читателя возникнет желание поэкспериментировать с разреженными файлами, такой файл можно создать с помощью команды fsutil sparse. А на досуге можно обдумать, какова же настоящая длина файла, если система записала в соответствующую графу число 4 Гб, а реальных данных в файле только 32 Мб и на диске он занимает тоже 32 Мб.
И, наконец, расскажем еще об одной длине: длине действительных данных (valid data). Эта длина и устанавливающие ее функции представляют интерес почти исключительно для программистов, тем не менее изредка с ней могут столкнуться и обычные пользователи.
В файловых системах FAT такого понятия не существует, и функции, которые используют эту величину, записывают в тело файла на соответствующих местах нули. В NTFS эта длина является характеристикой файла.
Попробуем пояснить, о чем идет речь, на примере. Возьмите флешку (флешка используется для наглядности, поскольку она медленнее жесткого диска работает с большими объемами данных) размером от гигабайта, отформатированную в FAT32, и создайте на ней большой файл командой
fsutil file createnew k:\пробный.txt 900000000
Теперь отформатируйте флешку в NTFS, для чистоты эксперимента лучше взять ту же самую, и повторите создание файла. На этот раз операция пройдет практически моментально. Записывать нули в тело файла уже не надо, достаточно распределить место под файл и установить для него длину действительных данных равной нулю. В теле файла останется «мусор», который был записан в этих секторах, но при чтении данных обращения к этим данным не произойдет – обнаружив, что длина действительных данных равна нулю, все, что дальше этого нуля, система читать не станет – ведь эти данные недействительны. Их можно сделать действительными, если изменить значение длины действительных данных.
Рассмотрим это на примере. Создайте новый файл на одном из рабочих дисков, отформатированном в NTFS. Сотни мегабайт совершенно не обязательны, десятка-другого килобайт будет вполне достаточно:
fsutil file createnew C:\пробный.txt 10000
Теперь откройте его с помощью любого просмотрщика файлов, например FAR.
Как видим, в файле действительно нули. Но если посмотреть на этот файл с помощью какого-либо редактора дисков, обращающегося к секторам напрямую, например dmde, то картина будет другая.
Если мы откроем том С как логическое устройство и посмотрим на содержимое файла, то увидим те же самые нули.
Но если открыть диск как физическое устройство, то в том же самом секторе (обратите внимание на номера LBA – разница в 63 возникла из-за того, что начало раздела сдвинуто относительно начала диска) увидим данные, которые ранее были записаны в какой-то позже удаленный файл.
И если мы увеличим длину действительных данных, то увидим эти данные в файле. Установим эту длину равной 300 байт:
fsutil file setvaliddata C:\пробный.txt 300
Обратите внимание что параметр в этой команде нельзя задавать произвольно, но должен быть не меньше текущего значения длины действительных данных и не больше размера файла. Уменьшить длину действительных данных этой командой нельзя.
Теперь снова посмотри на содержимое файла. Заметьте, что никаких данных мы в него не записывали!
Чисто случайно получилось, что в этом файле довольно много осмысленного текста, что делает картину более наглядной. 300 десятичных байтов – это 12c шестнадцатиричных, и как раз на этом байте обрывается текст и начинаются нули. Если сдвинуть границу действительных данных еще дальше, то «проявятся» и следующие строки.
Подведем итоги
Имеется две физических длины файла – это размер файла, записанный в файловой системе и место, занимаемое на диске. Также имеется две логических длины файла – это признак конца файла (байт EOF – 27h) и длина действительных данных. Как составную часть логической длины можно рассматривать и пустые области в разреженных файлах – вспомните \$Extend\$UsnJrnl, где большой массив отсутствующих данных завершается тридцатью двумя мегабайтами действительных.
Итак, обычно, когда говорят о длине файла, имеют в виду число, хранящееся в файловой системе. Но, как видите, возможны варианты!
Формат файлов Avro
Для сериализации данных широко используют Avro — это основанный на строках, то есть строковый, формат хранения данных в Hadoop. Он хранит схему в формате JSON, облегчая ее чтение и интерпретацию любой программой. Сами данные лежат в двоичном формате, компактно и эффективно.
Ключевой особенностью Avro является надежная поддержка схем данных, которые изменяются с течением времени, то есть эволюционируют. Avro понимает изменения схемы — удаление, добавление или изменение полей.
Avro поддерживает разнообразные структуры данных. Например, можно создать запись, которая содержит массив, перечислимый тип и подзапись.
Этот формат идеально подходит для записи в посадочную (переходную) зону озера данных (озеро данных, или data lake — коллекция инстансов для хранения различных типов данных в дополнение непосредственно к источникам данных).
Так вот, для записи в посадочную зону озера данных такой формат лучше всего подходит по следующим причинам:
- Данные из этой зоны обычно считываются целиком для дальнейшей обработки нижестоящими системами — и формат на основе строк в этом случае более эффективен.
- Нижестоящие системы могут легко извлекать таблицы схем из файлов — не нужно хранить схемы отдельно во внешнем мета-хранилище.
- Любое изменение исходной схемы легко обрабатывается (эволюция схемы).
Формат файлов ORC
Оптимизированный строково-столбчатый формат файлов (Optimized Row Columnar, ORC) предлагает очень эффективный способ хранения данных и был разработан, чтобы преодолеть ограничения других форматов. Хранит данные в идеально компактном виде, позволяя пропускать ненужные детали — при этом не требует построения больших, сложных или обслуживаемых вручную индексов.
Преимущества формата ORC:
- Один файл на выходе каждой задачи, что уменьшает нагрузку на NameNode (узел имен).
- Поддержка типов данных Hive, включая DateTime, десятичные и сложные типы данных (struct, list, map и union).
- Одновременное считывание одного и того же файла разными процессами RecordReader.
- Возможность разделения файлов без сканирования на наличие маркеров.
- Оценка максимально возможного выделения памяти кучи на процессы чтения/записи по информации в футере файла.
- Метаданные сохраняются в бинарном формате сериализации Protocol Buffers, который позволяет добавлять и удалять поля.
ORC хранит коллекции строк в одном файле, а внутри коллекции строчные данные хранятся в столбчатом формате.
Файл ORC хранит группы строк, которые называются полосами (stripes) и вспомогательную информацию в футере файла. Postscript в конце файла содержит параметры сжатия и размер сжатого футера.
По умолчанию размер полосы составляет 250 МБ. За счет полос такого большого размера чтение из HDFS выполняется более эффективно: большими непрерывными блоками.
В футере файла записан список полос в файле, количество строк на полосу и тип данных каждого столбца. Там же записано результирующее значение count, min, max и sum по каждому столбцу.
Футер полосы содержит каталог местоположений потока.
Строчные данные используются при сканировании таблиц.
Индексные данные включают минимальные и максимальные значения для каждого столбца и позиции строк в каждом столбце. Индексы ORC используются только для выбора полос и групп строк, а не для ответа на запросы.
Пишет разные размеры в свойстве диска и в свойствах всех папок на диске.
Включил показ скрытых файлов и папок - ничего нету.
Почему тогда такое расхождение не понимаю? Как удалить лишние файлы (есть большое подозрение, что при удалении каких-то файлов с диска они не удалились до конца).
1) Снимите галочку
"Разрешить индексацию файлов. ", и примените. Вам придётся долго ждать несколько часов. Если диск старый.
2) Возможно на этом диске включена защита. Создание точек восстановления. Выключите её. Там могут быть гигабайты файлов.
3) Сколько у вас оперативной памяти, столько же может создаваться файл сна, если вы часто работаете на этом диске. Тоже самое относится к виртуальной памяти. Если у вас, к примеру 8 ГБ памяти, то "мусора" может быть 16.
4) Если на диске "С" включена опция "Восстановления системы", то на диске "D" куча мусора от этих бэкапов.
5) Если какая-то программа использует свою временную папку, и она расположена на диске "D", там в ней гигабайты мусора.
6) "Оглавление" диска, где записано расположение файлов, нередко занимает одну треть диска. Доступ туда пользователю запрещён, и оно невидимое.
Все описанные выше папки скрытые, во многие доступ запрещён или только на уровне "Системы". В лучшем случае на уровне "Администратора". Не путайте "На уровне и с правами".
7) Система записи на диске в разбивке NTFS, организована методом разбивки и форматирования Виндовс. Один логический сектор, даже имея 1 байт, занимает место 4096 байт. Огромное количество мелких файлов, занимают место в 5 - 10 раз больше своего объёма.
Если вы давно не делали очистку диска - сделайте её. Только не доверяйте всяким программам. Сделайте её с помощью рук и в основном головы. А затем обязательно запустите дефрагментацию.
Не будьте рабом винды, станьте её Хозяином. Сделайте полный показ всех файлов и папок и чистите, чистите. Если уроните винду - я с себя всю вину снимаю.
Зачем нужны разные форматы файлов
Серьезное узкое место в производительности приложений с поддержкой HDFS, таких как MapReduce и Spark — время поиска, чтения, а также записи данных. Эти проблемы усугубляются трудностями в управлении большими наборами данных, если у нас не фиксированная, а эволюционирующая схема, или присутствуют некие ограничения на хранение.
Обработка больших данных увеличивает нагрузку на подсистему хранения — Hadoop хранит данные избыточно для достижения отказоустойчивости. Кроме дисков, нагружаются процессор, сеть, система ввода-вывода и так далее. По мере роста объема данных увеличивается и стоимость их обработки и хранения.
Различные форматы файлов в Hadoop придуманы для решения именно этих проблем. Выбор подходящего формата файла может дать некоторые существенные преимущества:
- Более быстрое время чтения.
- Более быстрое время записи.
- Разделяемые файлы.
- Поддержка эволюции схем.
- Расширенная поддержка сжатия.
Формат файлов Parquet
Parquet — опенсорсный формат файлов для Hadoop, который хранит вложенные структуры данных в плоском столбчатом формате.
По сравнению с традиционным строчным подходом, Parquet более эффективен с точки зрения хранения и производительности.
Это особенно полезно для запросов, которые считывают определенные столбцы из широкой (со многими столбцами) таблицы. Благодаря формату файлов читаются только необходимые столбцы, так что ввод-вывод сводится к минимуму.
Небольшое отступление-пояснение: чтобы лучше понять формат файла Parquet в Hadoop, давайте посмотрим, что такое основанный на столбцах — то есть столбчатый — формат. В таком формате вместе хранятся однотипные значения каждого столбца.
Например, запись включает поля ID, Name и Department. В этом случае все значения столбца ID будут храниться вместе, как и значения столбца Name и так далее. Таблица получит примерно такой вид:
ID | Name | Department |
1 | emp1 | d1 |
2 | emp2 | d2 |
3 | emp3 | d3 |
Столбчатый формат более эффективен, когда вам нужно запросить из таблицы несколько столбцов. Он прочитает только необходимые столбцы, потому что они находятся по соседству. Таким образом, операции ввода-вывода сводятся к минимуму.
Например, вам нужен только столбец NAME. В строковом формате каждую запись в наборе данных нужно загрузить, разобрать по полям, а затем извлечь данные NAME. Столбчатый формат позволяет перейти непосредственно к столбцу Name, так как все значения для этого столбца хранятся вместе. Не придется сканировать всю запись.
Таким образом, столбчатый формат повышает производительность запросов, поскольку для перехода к требуемым столбцам требуется меньше времени поиска и сокращается количество операций ввода-вывода, ведь происходит чтение только нужных столбцов.
Одна из уникальных особенностей Parquet заключается в том, что в таком формате он может хранить данные с вложенными структурами. Это означает, что в файле Parquet даже вложенные поля можно читать по отдельности без необходимости читать все поля во вложенной структуре. Для хранения вложенных структур Parquet использует алгоритм измельчения и сборки (shredding and assembly).
Чтобы понять формат файла Parquet в Hadoop, необходимо знать следующие термины:
Здесь заголовок просто содержит волшебное число PAR1 (4 байта), которое идентифицирует файл как файл формата Parquet.
В футере записано следующее:
- Метаданные файла, которые содержат стартовые координаты метаданных каждого столбца. При чтении нужно сначала прочитать метаданные файла, чтобы найти все интересующие фрагменты столбцов. Затем фрагменты столбцов следует читать последовательно. Еще метаданные включают версию формата, схему и любые дополнительные пары ключ-значение.
- Длина метаданных (4 байта).
- Волшебное число PAR1 (4 байта).
Читайте также: