Про разного рода технически сложные задачи и их решения.
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Кому принадлежат языки? Я имею в виду не языки программирования, а я разговорные языки. Вопрос этот одновременно философский, не без политики, и очень практичный.
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts