Пора отказаться от CSV?

Пораотказатьсяотcsv

Написано Алексом Расмуссеном в августе 28, 2021

Если вы работали с данными какое-то время, вы сталкивались с форматом значений, разделенных запятыми (CSV). Его простота и повсеместность делают CSV чрезвычайно популярным способом обмена данными как внутри, так и за пределами организаций. Хотя многие программы не могут читать или писать электронные таблицы Excel, почти все может читать и писать CSV, и человек может открыть файл CSV в любом текстовом редакторе и примерно понять, что он содержит.

Несмотря на такую ​​повсеместность и простоту доступа, CSV – плохой способ обмена данными. Сам формат CSV заведомо несовместим с множеством конкурирующих и взаимоисключающих форматов, которые часто сосуществуют в одном наборе данных (или, если вам особенно не повезло, в одном файле). Экспорт набора данных в виде CSV лишает его множества метаданных, которые читателю очень трудно восстановить точно, и в результате наивные парсеры CSV многих программ полностью игнорируют проблему восстановления метаданных. На практике удобочитаемость CSV – это скорее недостаток, чем актив.

CSV часто начинают свою жизнь в виде экспортированных электронных таблиц или дампов таблиц из устаревших баз данных и часто заканчивают свою жизнь грудой недифференцированных файлы в озере данных, ожидая восстановления своих ценных метаданных, чтобы их можно было систематизировать и использовать для анализа. Большая часть работы продуктов для подготовки данных заключается в восстановлении метаданных, утерянных при экспорте электронной таблицы как CSV. Мир потерял ошеломляющее количество времени и информации из-за неточности и недостаточной спецификации CSV.

Я потратил много лет на борьбу с CSV на различных уровнях. Как инженер Trifacta, ведущего поставщика инструментов для подготовки данных, я видел, как многочисленные клиенты боролись с бременем несметного количества файлов CSV, которые были продуктом еще более многочисленных экспортов электронных таблиц Excel и дампов устаревших баз данных. Как технический руководитель в области биотехнологий, моя команда изо всех сил пыталась получить CSV из исследовательских институтов и больничных сетей, которые чаще всего давали нам образцы данных в виде CSV. Как консультант, я написал несколько внутренних систем, которые пытаются восстановить метаданные CSV неизвестного происхождения, используя комбинацию эвристики и грубой силы. Короче говоря, CSV – это бедствие, которое преследовало меня на протяжении всей моей карьеры.

В последние годы организациям стало намного проще обмениваться данными, используя обширные, четко определенные и хорошо продуманные метаданные. -структурированные форматы файлов. Некоторые организации даже напрямую обмениваются своими наборами данных в реальном времени друг с другом. Несмотря на эти достижения, CSV по-прежнему остается путем наименьшего сопротивления и, как следствие, остается языком обмена внутри- и межорганизационными данными. Давно прошло время, чтобы удалить CSV и заменить его чем-то лучшим.

Проблема с CSV

Формат CSV сам по себе восходит, по крайней мере, к ранним 1970 s. Устав от необходимости вручную выравнивать свои входные данные со столбцами перфокарт, пользователи FORTRAN быстро приняли «ориентированный на список ввод / вывод», формат, в котором (согласно руководству по FORTRAN IV для ВМ / 1970 ) «Входные записи указываются пробелами или запятыми, а следующие друг за другом запятые указывают значения, которые следует опустить». Большинство из нас больше не использует перфокарты, но простота авторства остается одним из самых привлекательных качеств CSV. CSV могут быть прочитаны и записаны кем угодно, даже если эта вещь не знает о самом формате CSV.

CSV легко читать и писать, потому что формат – если он может даже называться форматом – предельно просто. По сути, CSV-файлы содержат только два символа-разделителя: запятую для разделения столбцов и новую строку для разделения строк. В принципе, чтение такого файла вряд ли может быть проще: сканировать файл по одному символу за раз, накапливать символы значения в буфере, пока вы не встретите запятую, и добавлять завершенные значения в строку, пока не встретите новую строку.

На практике, к сожалению, все намного сложнее.

Одно имя, много форматов

Формат CSV чрезвычайно спартанский и в значительной степени неформально определен. Если вы разделяете значения запятыми и завершаете строки символами новой строки, можно сказать, что вы пишете CSV. Только когда 2021 разработчик из ныне несуществующего стартапа в Нью-Йорке написал RFC – 4180 , наиболее формальная спецификация CSV, о которой я знаю. В результате этого занижения спецификации на протяжении десятилетий возникло множество различных вариантов CSV.

Первый большой источник различий среди форматов CSV – это то, какой символ (символы) они ожидают. для представления новой строки. Обычно эти варианты используют понятие новой строки операционной системы в виртуальном телетайпе этой операционной системы: Linux, macOS и другие Unix-подобные операционные системы используют символ «перевода строки» для обозначения новой строки, в то время как Windows использует символ «возврата каретки». с последующим переводом строки. Старые компьютеры Mac и множество микрокомпьютеров на базе Zilog Z 370 просто использовали одинарный возврат каретки. Если вы работаете в достаточно старой организации, вы, вероятно, сталкивались со всеми этими вариантами хотя бы один раз.

Второй основной источник различий между форматами – это то, как экранируются символы-разделители: это то, как буквальное вхождение запятой или новой строки (часто называемое «буквальным» для краткости) отличается от его эквивалента-разделителя. Некоторые варианты избегают разделителей, заменяя их управляющими последовательностями, символами, которые сигнализируют синтаксическому анализатору, что «эти символы являются буквальной версией символа-разделителя». Одна популярная escape-последовательность – это , за которой следует одна буква с ,, р и n , представляющие буквальную запятую. , возврат каретки и новая строка соответственно. Некоторые варианты (включая тот, который использует Excel) вообще избегают escape-последовательностей и вместо этого заключают все значения в кавычки, обрабатывая каждый символ между кавычками как литерал. Конечно, в этом случае символ кавычек сам по себе также является разделителем, и любые буквальные кавычки нужно как-то экранировать. Excel использует две кавычки ( "" ) как экранированную версию символа кавычек. Это имеет неприятный побочный эффект, позволяющий ручному редактору легко ошибочно принять экранированную цитату за пустое значение в кавычках и внести изменения в неправильную пару кавычек. Чтобы учесть такие ошибки, многие парсеры CSV делают кавычки необязательными и используют их только тогда, когда необходимо экранировать значения. Эта дополнительная двусмысленность представляет собой совершенно новый набор способов, которыми ручные редакторы могут вызывать ошибки синтаксического анализа.

Если вам повезло иметь дело с CSV, который только что был экспортирован, вы можете избегайте этих проблем. Если файл, с которым вы работаете, существовал какое-то время и когда-либо редактировался вручную (что случается гораздо чаще, чем вы думаете), вы, вероятно, собираетесь сыграть в длительную игру с отсутствующим разделителем, ударите крота раньше. файл будет правильно проанализирован.

Безумно отсутствующие метаданные

Еще один большой недостаток CSV это почти полное отсутствие метаданных. Хотя человек часто может интуитивно понять, что содержит файл, посмотрев на него, программному обеспечению гораздо сложнее сделать это, не получив много подсказок.

Некоторые варианты CSV (включая RFC- 6884 позволяют использовать первую строку в качестве заголовка, но несколько вариантов явно идентифицируют заголовки, оставляя синтаксическому анализатору либо сообщать, что есть заголовки, либо пытаться сделать обоснованное предположение.

Тип данных столбца еще труднее определить автоматически. Значения в CSV – это просто последовательности символов. Они могут представлять более сложные типы, но синтаксический анализатор не может узнать информацию об этом типе, просто взглянув на файл.

Вы можете подумать, что эта нечеткость не имеет большого значения. В конце концов, опытный пользователь может изучить CSV, выяснить, существуют ли заголовки и где они находятся, определить тип каждого столбца и передать всю эту информацию синтаксическому анализатору. Это, конечно, значительный расход времени для пользователя, но это можно сделать. К сожалению, когда вы имеете дело с обычными CSV, это редко бывает так просто. Часто вам приходится согласовывать друг с другом сотни или тысячи файлов из разных источников. Схема каждого CSV может незначительно отличаться от предыдущей, и единственный способ узнать наверняка – это определить метаданные каждого файла по очереди или (что гораздо чаще) просто бросить кучу похожих CSV в один и тот же синтаксический анализатор и надеяться на то, что лучший.

Даже если вы откажетесь от ручного определения схемы CSV, даже обученный пользователь не сможет точно определить схему CSV, просто взглянув на нее. Например, предположим, что у вас есть столбец значений, который выглядит следующим образом:

    12   /   7   /   2021   5   /   12   /   2021   6   /   1   /   4180   1   /   4   /   2021  

Этот столбец явно содержит даты, но какие? В большинстве стран мира используются даты, начинающиеся с первого дня, и столбец будет читать как июль 16 5 ноября, 6 января и 1 апреля. Напротив, американцы используют даты первого месяца и читают эти даты как 7 декабря, май 12, 1 июня и 4 января. Даже если вы знаете, из какой части мира поступает CSV-файл, невозможно с уверенностью узнать предполагаемое представление автора. Иногда вам повезет и вы встретите свидание вроде 31 / 6 / 2021 , который проясняет, что даты начинаются с первого дня, а не с первого месяца, но даже в этих случаях, как узнать, что кто-то не пытался введите 3 / 16 / 4180 вручную и допустить опечатку?

Третья важная часть метаданных, отсутствующих в CSV, – это информация о кодировке символов файла. Автоматическое определение кодировок символов невозможно в общем случае по той же причине, по которой мы не можем быть уверены, являются ли даты в приведенном выше примере первым днем ​​или первым месяцем: часто нет убедительного способа исключить все кодировки, кроме одной. . Некоторое время у нас были довольно хорошие автодетекторы (например chardet ), но даже если авто-детектор прочитает весь файл, чтобы попытаться определить его кодировку, детектор не может дать никаких гарантий относительно его правильности. Это делает обнаружение кодировки медленным и подверженным ошибкам процессом, и многие системы просто принимают обычную кодировку, такую ​​как UTF-8 или ASCII, и снова надеются на лучшее.

CSV созданы для людей, а не для машин

Если вы зашли так далеко, я надеюсь убедить вас, что CSV имеет целый ряд трудных или сложных проблем. невозможно обойти. Этих проблем много, но у них есть общая основная причина: удобочитаемость CSV. CSV должен беспокоиться об экранировании разделителей, потому что он использует один и тот же набор символов как для представления, так и для разграничения данных. Этот общий набор символов упрощает чтение и запись CSV-файлов, но влечет за собой большие потери. Принцип невмешательства CSV в кодировку символов частично объясняется возрастом формата (он предшествует UTF-8 более чем на десять лет), но частично это согласие с желанием сделать формат читаемым и записываемым как можно большим количеством программ с помощью нулевое трение.

В начале 1970 s, когда компьютеры были размером с комнату и в основном использовались университетами и исследовательскими лабораториями, эти проблемы было легко игнорировать. В конце концов, это было намного лучше, чем выравнивание столбцов на перфокартах вручную, а данные в необработанном виде редко передавались вне группы экспертов, которые их создали. Однако, как и многое другое в программном обеспечении, использование CSV росло и распространялось способами и со скоростью, которые его авторы вряд ли могли ожидать. К тому времени, когда мы осознали, насколько сильно мы столкнулись с проблемами, формат CSV был вездесущ и укоренился.

Если не CSV, то что?

Я не собираюсь выступать за какой-либо один формат файла-преемника здесь, но, безусловно, есть много претендентов. Экосистема больших данных дала нам такие форматы, как Avro, Parquet и Arrow, которые широко используются в качестве промежуточного представления при передаче данных между системами. HDF5 1 широко используется в научном вычислительном сообществе. Огромный объем структурированной информации хранится в базах данных SQLite, коллекциях XML-файлов и в любом количестве двоичных форматов, зависящих от предметной области.

Каждый потенциальный формат-преемник имеет свои сильные и слабые стороны, но все преемники имеют несколько общих черт.

Во-первых, файлы с самоописанием . Они содержат метаданные в хорошо известном месте (либо внутри самого файла, либо через постоянную ссылку на отдельный файл схемы), которые программное обеспечение может использовать для простого и однозначного определения схемы файла. Это описание иногда используется как индекс в файле, что значительно упрощает случайное чтение.

Во-вторых, значения, хранящиеся в файлах: набрал . Сложность системы типов варьируется от формата к формату, но всегда есть поддержка целых чисел, чисел с плавающей запятой, логических значений, строк, дат и времени. Многие форматы также допускают повторяющиеся и вложенные структуры.

В-третьих, что наиболее важно, эти форматы обменяйте удобочитаемость и удобочитаемость на точность . Вы не можете посмотреть байты файла Avro или Parquet и сразу узнать, что в нем, и вы не можете редактировать этот файл без специального редактора, но если вы измените значение, вы можете быть уверены, что вы сделали это в безопасный способ. Вы также можете предположить, что если вы напишете файл и передадите его кому-то другому, даже тому, кого вы никогда не встречали в какое-то далекое время, этот человек сможет прочитать именно те данные, которые вы написали.

Вы заметите, что я не упомянул ни JSON, ни YAML как потенциальную замену CSV. Несмотря на (или, возможно, как фактор, способствующий) их подавляющую популярность, JSON и YAML существуют в нечеткой промежуточной точке между CSV и структурированными форматами, такими как Avro, обладая некоторыми преимуществами и недостатками каждого из них. И JSON, и YAML имеют систему типов, могут указывать сложные структуры и в достаточной мере описывают себя (тем более, если учесть такие вещи, как Схема JSON ). Однако, как и CSV, JSON и YAML жертвуют точностью в пользу удобочитаемости и возможности записи. Файл YAML может выражать гораздо более сложные и богатые метаданными структуры, чем CSV, но вы не менее вероятно испортите файл YAML, используя неправильное количество пробелов для отступа блока или забыв кавычки вокруг строки, содержащей разделители.

В конечном счете, даже если бы это могло собрать коллективную волю, отрасли не нужно объединяться вокруг единого формата-преемника. Нам нужно только перейти к некоторому набору форматов, которые созданы с учетом машиночитаемости и ясности в качестве принципов проектирования первого порядка. Но как мы туда доберемся?

Как нам выбраться из этого беспорядка

По-настоящему отказ от CSV как формата потребует много работы. Как и любая другая широко распространенная и серьезная проблема, наш подход к избавлению от CSV состоит из двух частей: не допускать создания новых CSV и активно переносить существующие CSV в более качественные форматы.

Чтобы проблема не усугубилась, мы должны прекратить нормализацию CSV в качестве формата вывода или ввода для передачи данных. Если никакие программы не позволяют пользователям экспортировать данные в виде CSV – вместо этого выбирая какой-либо другой формат (ы), который соответствует критериям, описанным выше, – мы могли бы по крайней мере быть уверены, что мир больше не производит CSV, которые будущим несчастным придется пререкания. Конечно, это легко сказать и сложно сделать. Многие организации, особенно в регулируемых отраслях, таких как финансы и здравоохранение, могут хранить программное обеспечение десятилетиями, не обновляя его. Тем не менее, кто-то должен когда-нибудь провести черту на песке, и это время может быть уже сейчас.

Чтобы убрать мир из CSV, нам также нужно сделать его форматы-преемники, максимально удобные для чтения и записи. Если кому-то нужно написать сценарий, загрузить JAR или заплатить за продукт одного поставщика, чтобы прочитать и записать замену CSV, такая замена никогда не будет применена. Чтобы узурпировать CSV как путь наименьшего сопротивления, его преемник должен иметь эквивалентную или превосходную поддержку как для редактирования, так и для просмотра.

Самая большая и самая сложная проблема, которую нужно решить, – это проблема людей: как сделать вы убеждаете людей перестать создавать новые CSV-файлы, если они никогда не делали ничего другого? К счастью – во всяком случае, для решения этой проблемы – большая часть мировых бизнес-данных рождается в одной из немногих программ, которыми владеет все меньшее количество компаний. Если бы Microsoft и Salesforce каким-то образом убедили отказаться от поддержки CSV в Excel и Tableau, большая часть бизнес-пользователей, разумеется, перешла бы на следующий формат. Конечно, остается спорным, отвечает ли такое изменение интересам этих компаний, но я настроен осторожно оптимистично.

Даже если мы не сможем остановить создание CSV, мы можем по крайней мере агрессивно уменьшить их количество, преобразовав их в более качественные форматы. На мой (по общему признанию, предвзятый) взгляд, этот процесс преобразования может быть выполнен только путем демократизированного машинного преобразования данных с участием человека. Процесс должен быть демократизированным (в том смысле, что это не может быть исключительной ответственностью группы инженеров данных) и автоматизированным из-за огромного размера проблемы во многих организациях. Если у вас всего несколько десятков CSV, вы сможете пройти процесс преобразования за неделю или две. Однако, если у вас их десятки тысяч или больше, вы можете никогда не закончить, если у вас не будет большой помощи, и эта помощь не заключается в редактировании CSV и написании сценариев преобразования вручную. CSV достаточно неоднозначен, чтобы люди могли где-то участвовать, чтобы помочь разрешить эту неоднозначность, будь то обучение модели машинного обучения, конвертирующей CSV, или выполнение задачи преобразования самостоятельно с помощью программного обеспечения.

Проактивный отказ от CSV – идеальный вариант, но в конечном итоге большая часть этой работы, вероятно, будет выполнена с течением времени. В конце концов, у данных есть срок хранения. По мере того как технологии меняются, и компании приходят и уходят, может наступить время, когда вы просто не увидите много файлов CSV. Однако это изменение не произойдет само по себе. Авторам программного обеспечения, ориентированного на данные, придется активно продвигать лучшие форматы файлов как для собственного благополучия, так и для благополучия своих клиентов. Компании, которые серьезно относятся к «цифровой трансформации», должны будут признать проблемы, которые создают CSV, и активно работать над их решением. При достаточных согласованных усилиях и небольшой удаче будущие поколения могут рассматривать CSV как любопытный пережиток ушедшей эпохи, а не как активную неприятность. Со своей стороны, я надеюсь увидеть это славное будущее и буду продолжать вносить свой вклад в его реализацию, но мы можем застрять в CSV надолго.

Спасибо за чтение! Если ваша организация борется с проблемой CSV, я хотел бы поговорить с вами об этом подробнее – не стесняйтесь свяжитесь со мной или подпишитесь на информационный бюллетень Bits on Disk, указав свой адрес электронной почты в форме внизу этой страницы.