Симпатичный жанр NO SLIDES, выступления без презентаций и одноимённая конференция [1] где нет презентаций в виде слайдов, только прямая речь и демонстрация экрана. А также таблица с выступлениями прошедшей конференции со ссылками на видеозаписи на Youtube [2]. Почти всё про данные и про аналитику, есть немало интересного что посмотреть.
Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.
Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0
#thoughts #presentations #conferences
Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.
Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0
#thoughts #presentations #conferences
noslides.wtf
NOSLIDES | Conference
NOSLIDES Conference
Хорошая статья в Системном блоке про судьбу ABBYY, их продукта Compreno и научного подхода в переводе текстов [1]. Если вкратце, то судьба печально, LLM ИИ пожирают мир. Я помню в 2010-х разговоры про Compreno как люди вовлеченные в этот проект его расхваливали, но вживую его так и не успел попробовать, а теперь уже и непонятно зачем.
А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только прогибель трансформацию компьютерной лингвистики, это и про будущее онтологического моделирования, это про судьбу проектов вроде Wolfram Alpha (похоже недолгую уже), это про применение LLM в моделировании и систематизации данных.
Вот я вам приведу пример, у нас в Dateno десятки миллионов карточек датасетов и далеко не у всех есть привязка к категориям, не у всех есть теги, не у всех есть геометки и тд.. Можно вложить усилия и категоризировать их вручную, а можно натравить одну или несколько LLM и проделать эту работу. Можно ещё на несколько задач LLM натравить и будет ещё больший эффект, вопрос лишь в цене запросов или развертывания open source LLM.
А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".
Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/
#thoughts #readings #ai
А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только про
Вот я вам приведу пример, у нас в Dateno десятки миллионов карточек датасетов и далеко не у всех есть привязка к категориям, не у всех есть теги, не у всех есть геометки и тд.. Можно вложить усилия и категоризировать их вручную, а можно натравить одну или несколько LLM и проделать эту работу. Можно ещё на несколько задач LLM натравить и будет ещё больший эффект, вопрос лишь в цене запросов или развертывания open source LLM.
А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".
Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/
#thoughts #readings #ai
Системный Блокъ
Горький урок ABBYY: как лингвисты проиграли последнюю битву за NLP - Системный Блокъ
Недавно СМИ облетела новость об увольнении всех российских программистов из компании ABBYY (тоже в прошлом российской, а теперь уже совсем нет). Теперь, когда страсти вокруг обсуждения дискриминации сотрудников по паспорту улеглись, хочется поговорить о более…
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
К вопросу о дата-инженерии и Dateno, одна из особенностей проекта в том что практически вся работа с данными построена на собственных инструментах с открытым кодом, что имеет кучу преимуществ при старте, и накапливающиеся ограничения в будущем которые уже хочется избежать.
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
Не успела появится профессия BI Engineer как её скоро заменит AI [1]. Полезная статья в блоге Rill о применении AI для корпоративной аналитики.
Это, кстати, вполне реалистичное применение технологий. Вместо построения дашбордов использование естественного языка для получения аналитики. Правда аналитики останутся без работы даже быстрее чем многие другие профессии. Потому что ничто не мешает членам совета директоров хотья прямо на совещании делать промпты на естественном языке к языковой модели которая имеет доступ к корпоративному хранилищу и получать почти моментальные ответы.
Ссылки:
[1] https://www.rilldata.com/blog/bi-as-code-and-the-new-era-of-genbi
#bi #analytics #ai #thoughts
Это, кстати, вполне реалистичное применение технологий. Вместо построения дашбордов использование естественного языка для получения аналитики. Правда аналитики останутся без работы даже быстрее чем многие другие профессии. Потому что ничто не мешает членам совета директоров хотья прямо на совещании делать промпты на естественном языке к языковой модели которая имеет доступ к корпоративному хранилищу и получать почти моментальные ответы.
Ссылки:
[1] https://www.rilldata.com/blog/bi-as-code-and-the-new-era-of-genbi
#bi #analytics #ai #thoughts
Я тут наблюдаю время от времени как публикуют открытые данные некоторые команды, в том числе с хорошей мировой репутацией, но с небольшими знаниями по современной дата инженерии и уже какое-то бесконечное время смотрю как многие открытые и не только открытые данные опубликованы. И прихожу к мысли о том что уже классическое определение открытых данных с точки зрения 5 звезд которое формулировал Тим-Бернерс Ли [1] [2] не то чтобы устарело, но требует актуализации.
Напомню как это было сформулировано:
- 1 звезда - данные доступны онлайн в любом формате ⭐️
- 2 звезды - данные доступны хотя бы в структурированном формате, например, Excel таблица ⭐️⭐️
- 3 звезды - данные доступны в структурированном непроприетарном формате, например, CSV, KML, JSON и др. ⭐️⭐️⭐️
- 4 звезды - данные доступны по прямой ссылке и в форматах а ля RDF (RDF, Turtle, JSON-LD и тд.). То есть их не надо получать динамически через какой-нибудь экспорт из графика или системы, а можно напрямую скачать.⭐️⭐️⭐️⭐️
- 5 звезд - данные доступны как Linked data, их можно связывать с другими датасетами. ⭐️⭐️⭐️⭐️⭐️
Концепция изначально хорошая и правильная, но она неизбежно столкнулась с тем что прижилась и, то частично, только в академической среде. В первую очередь потому что Linked Data плохо связывается с большими данными в общем случае, и с тем что работа над схематическим описанием в Linked Data - это серьёзный барьер с отсутствием прямой экономической выгоды. Это не значит что связанных данных нигде нет, это лишь значит что их мало и доля не растёт. Увы.
Если посмотреть по прошествии более 10 лет с момента формулировки и с точки зрения стремительного развитие работы с данными, я бы, навскидку, описал это так. Не по звёздам, а по уровням качества данных.
- 1 уровень - данные доступны в любом виде
- 2 уровень - данные доступны и к ним есть сопровождающие их базовые метаданные
- 3 уровень - данные доступны, к ним есть метаданные и они опубликованы в машиночитаемой форме
- 4 уровень - данные доступны, к ним есть метаданные, они машиночитаемы и к ним есть документация и/или схема
- 5 уровень - данные доступны, к ним есть метаданные, они машиночитаемы, к ним есть документация и они опубликованы в современных форматах для дата инженерии (parquet) или также доступны через API или как связанные данные Linked Data
- 6 уровень - данные оформлены как дата продукт, они доступны, к ним есть метаданные, они машиночитаемы, есть документация и несколько способов/форматов их получения: простые форматы CSV/JSON, современные вроде parquet, API и SDK. Пример: датасет с данными стран доступный как CSV, как JSON, как parquet, и в виде библиотеки на Python.
Это пока что мысли навскидку, если ещё чуть-чуть подумать то можно сформулировать точнее, но основное думаю очевидно. Linked Data - это хорошо, но воспринимать это как единственно эволюционную доступность данных нельзя. Точно так же с проприетарными форматами. Когда-то Microsoft был объектом публичной атаки буквально всех кто был за открытость. Сейчас проприетарность опубликованного формата, скажем так, вторична при практическом использовании. Проблема форматов XLS/XLSX и, кстати, ODS тоже не в проприетарности, а в чрезмерной гибкости приводящей к проблемам при конвертации.
В то же время про доступность данных для дата инженеров более 10 лет назад никто особо не думал, когда обсуждали вот эту концепцию 5 звезд. Сейчас всё иначе и качество данных определяется, в том числе, тем понимаем ли мы пользователей.
Чуть позже я ещё вернусь к этой теме.
Ссылки:
[1] https://5stardata.info/en/
[2] https://dvcs.w3.org/hg/gld/raw-file/default/glossary/index.html#linked-open-data
#opendata #thoughts #data
Напомню как это было сформулировано:
- 1 звезда - данные доступны онлайн в любом формате ⭐️
- 2 звезды - данные доступны хотя бы в структурированном формате, например, Excel таблица ⭐️⭐️
- 3 звезды - данные доступны в структурированном непроприетарном формате, например, CSV, KML, JSON и др. ⭐️⭐️⭐️
- 4 звезды - данные доступны по прямой ссылке и в форматах а ля RDF (RDF, Turtle, JSON-LD и тд.). То есть их не надо получать динамически через какой-нибудь экспорт из графика или системы, а можно напрямую скачать.⭐️⭐️⭐️⭐️
- 5 звезд - данные доступны как Linked data, их можно связывать с другими датасетами. ⭐️⭐️⭐️⭐️⭐️
Концепция изначально хорошая и правильная, но она неизбежно столкнулась с тем что прижилась и, то частично, только в академической среде. В первую очередь потому что Linked Data плохо связывается с большими данными в общем случае, и с тем что работа над схематическим описанием в Linked Data - это серьёзный барьер с отсутствием прямой экономической выгоды. Это не значит что связанных данных нигде нет, это лишь значит что их мало и доля не растёт. Увы.
Если посмотреть по прошествии более 10 лет с момента формулировки и с точки зрения стремительного развитие работы с данными, я бы, навскидку, описал это так. Не по звёздам, а по уровням качества данных.
- 1 уровень - данные доступны в любом виде
- 2 уровень - данные доступны и к ним есть сопровождающие их базовые метаданные
- 3 уровень - данные доступны, к ним есть метаданные и они опубликованы в машиночитаемой форме
- 4 уровень - данные доступны, к ним есть метаданные, они машиночитаемы и к ним есть документация и/или схема
- 5 уровень - данные доступны, к ним есть метаданные, они машиночитаемы, к ним есть документация и они опубликованы в современных форматах для дата инженерии (parquet) или также доступны через API или как связанные данные Linked Data
- 6 уровень - данные оформлены как дата продукт, они доступны, к ним есть метаданные, они машиночитаемы, есть документация и несколько способов/форматов их получения: простые форматы CSV/JSON, современные вроде parquet, API и SDK. Пример: датасет с данными стран доступный как CSV, как JSON, как parquet, и в виде библиотеки на Python.
Это пока что мысли навскидку, если ещё чуть-чуть подумать то можно сформулировать точнее, но основное думаю очевидно. Linked Data - это хорошо, но воспринимать это как единственно эволюционную доступность данных нельзя. Точно так же с проприетарными форматами. Когда-то Microsoft был объектом публичной атаки буквально всех кто был за открытость. Сейчас проприетарность опубликованного формата, скажем так, вторична при практическом использовании. Проблема форматов XLS/XLSX и, кстати, ODS тоже не в проприетарности, а в чрезмерной гибкости приводящей к проблемам при конвертации.
В то же время про доступность данных для дата инженеров более 10 лет назад никто особо не думал, когда обсуждали вот эту концепцию 5 звезд. Сейчас всё иначе и качество данных определяется, в том числе, тем понимаем ли мы пользователей.
Чуть позже я ещё вернусь к этой теме.
Ссылки:
[1] https://5stardata.info/en/
[2] https://dvcs.w3.org/hg/gld/raw-file/default/glossary/index.html#linked-open-data
#opendata #thoughts #data
Написал короткий лонгрид в продолжение размышлений о качестве открытых данных и дата продуктах
#opendata #thoughts #datasets
#opendata #thoughts #datasets
Ivan’s Begtin Newsletter on digital, open and preserved government
Открытые данные как дата продукт
Почему продвижение открытых данных не означает понимания их аудитории
Кстати, не могу не поделиться мыслью что в мире сейчас большой явный кризис в сообществе открытости данных и вызван он развитием ИИ. Я уже не в первый раз слышу разговоры в стиле зачем нам публиковать хорошие открытые данные и работать над их качеством если ИИ всё сожрёт. Это прям большое ментальное давление на очень многие проекты Wikipedia, OpenStreetMap, сообщество OKF и десятки других.
Если это не отменяет повестку открытости для гос-ва, то ограничивает и сильно повестку сообщества. Для многих это большое ограничение в том как готовить хорошие открытые данные и про усиление неравенства в мире.
Все кто создают что-либо общедоступное сталкиваются с тем что они создают лишь топливо для ИИ и что они работают не на преумножение знаний и блага людям, а на обогащение OpenAI.
#opendata #thoughts #community
Если это не отменяет повестку открытости для гос-ва, то ограничивает и сильно повестку сообщества. Для многих это большое ограничение в том как готовить хорошие открытые данные и про усиление неравенства в мире.
Все кто создают что-либо общедоступное сталкиваются с тем что они создают лишь топливо для ИИ и что они работают не на преумножение знаний и блага людям, а на обогащение OpenAI.
#opendata #thoughts #community
К вопросу о том что есть и чего нет в Dateno в контексте того доступно через наше API и того что исследователи уже искали по наукометрии. Есть специфика данных в Dateno в том что пока ещё исследовательских данных в нём маловато и по очень объективным причинам.
В реестре каталогов данных Dateno сейчас 874 репозитория научных данных из которых проиндексировано пока только 99 репозиториев, а это чуть более 11% источников метаданных такого типа. И даже эти 874 репозитория - это не все репозитории научных данных в мире, а наиболее очевидные. Точное число, скорее всего, никто не знает потому что реестры вроде Re3Data и Fairsharing более широко трактуют научные дата-ресурсы и включают туда не только каталоги данных, но и базы данных.
Возвращаясь к источникам, в чём с ними сложность:
1. Коммерческие каталоги научных данных вроде облачных продуктов Elsevier и Figshare значительно ограничивают возможности их индексирования. Проиндексировать их можно, но высока вероятность блокировок с их стороны. это примерно 34% каталогов научных данных в реестре Dateno.
2. Каталоги результатов научной деятельности на DSpace легко индексируются, но устроены так что невозможно отдельно индексировать только датасеты. Чтобы проиндексировать их надо скачать все метаданные всех объектов и далее уже фильтровать датасеты. Причем последних будет не более 5% от всего общего числа материалов
3. Некоторые каталоги научных данных вроде тех что основаны Thredds или Galaxy имеют очень скудный набор метаданных, по сути они выглядят как большие научные файлохранилища. Правда и области применения у них узкие: метеорология и биоинформатика, поэтому они пока отложены
4. Для научных репозиториев данных главное API до сих пор это OAI-PMH 2.0. Очень унаследованное, очень неудобное по многим критериям, очень стандартизированное и обладающее критическим недостатком: оно не отдаёт ссылки на файлы в метаданных. Иначе говоря карточку датасета получить можно с базовыми полями метаданных, но метаданных связанных с ним файлов нельзя. Это решается, но тем не менее.
5. Есть очень крупные источники научных наборов данных в OpenAIRE, ScienceDB, ScienceBase, DataCite, BASE и ещё ряде других. Проиндексировав даже парочку из них можно добавить сразу +10-20 миллионов записей, но..., качество датасетов будет посредственное. Честно говоря я тяну с их подключением так долго как могу не потому что это сложно, а потому что качество содержания поискового индекса снизится, у этих источников нет ссылок на ресурсы. Потому что все они агрегируют через OAI-PMH 2.0 Если бы единственным критерием качества в Dateno было бы только число записей, то вопросов бы не было.
Итого это развёрнутый ответ на невысказанный вопрос "Почему в Dateno так мало научных данных, всего 488 тысяч датасетов?" Краткий ответ: из-за качества данных, а более полный ответ выше.
В любом случае крайне важно что ключевой продукт Dateno, резко отличающий его от Google Dataset Search, - это открытый индекс. Помимо открытого API к поиску это ещё и открытый реестр каталогов данных и открытая статистика.
При этом открытый индекс - это большая ответственность потому что все косяки вылезают наружу достаточно быстро, ошибки находятся, также очень быстро.
Открытый индекс - это, также, дата-продукт и у него куча метрик качества о которых я когда-нибудь расскажу в подробностях, но скорее это будет в форме выступления на конференции чем короткая заметка.
А пока покажу некоторые существенные отличия и сравнение GDS (Google Dataset Search) и Dateno.
#opendata #dateno #thoughts #datacatalogs #datasets
В реестре каталогов данных Dateno сейчас 874 репозитория научных данных из которых проиндексировано пока только 99 репозиториев, а это чуть более 11% источников метаданных такого типа. И даже эти 874 репозитория - это не все репозитории научных данных в мире, а наиболее очевидные. Точное число, скорее всего, никто не знает потому что реестры вроде Re3Data и Fairsharing более широко трактуют научные дата-ресурсы и включают туда не только каталоги данных, но и базы данных.
Возвращаясь к источникам, в чём с ними сложность:
1. Коммерческие каталоги научных данных вроде облачных продуктов Elsevier и Figshare значительно ограничивают возможности их индексирования. Проиндексировать их можно, но высока вероятность блокировок с их стороны. это примерно 34% каталогов научных данных в реестре Dateno.
2. Каталоги результатов научной деятельности на DSpace легко индексируются, но устроены так что невозможно отдельно индексировать только датасеты. Чтобы проиндексировать их надо скачать все метаданные всех объектов и далее уже фильтровать датасеты. Причем последних будет не более 5% от всего общего числа материалов
3. Некоторые каталоги научных данных вроде тех что основаны Thredds или Galaxy имеют очень скудный набор метаданных, по сути они выглядят как большие научные файлохранилища. Правда и области применения у них узкие: метеорология и биоинформатика, поэтому они пока отложены
4. Для научных репозиториев данных главное API до сих пор это OAI-PMH 2.0. Очень унаследованное, очень неудобное по многим критериям, очень стандартизированное и обладающее критическим недостатком: оно не отдаёт ссылки на файлы в метаданных. Иначе говоря карточку датасета получить можно с базовыми полями метаданных, но метаданных связанных с ним файлов нельзя. Это решается, но тем не менее.
5. Есть очень крупные источники научных наборов данных в OpenAIRE, ScienceDB, ScienceBase, DataCite, BASE и ещё ряде других. Проиндексировав даже парочку из них можно добавить сразу +10-20 миллионов записей, но..., качество датасетов будет посредственное. Честно говоря я тяну с их подключением так долго как могу не потому что это сложно, а потому что качество содержания поискового индекса снизится, у этих источников нет ссылок на ресурсы. Потому что все они агрегируют через OAI-PMH 2.0 Если бы единственным критерием качества в Dateno было бы только число записей, то вопросов бы не было.
Итого это развёрнутый ответ на невысказанный вопрос "Почему в Dateno так мало научных данных, всего 488 тысяч датасетов?" Краткий ответ: из-за качества данных, а более полный ответ выше.
В любом случае крайне важно что ключевой продукт Dateno, резко отличающий его от Google Dataset Search, - это открытый индекс. Помимо открытого API к поиску это ещё и открытый реестр каталогов данных и открытая статистика.
При этом открытый индекс - это большая ответственность потому что все косяки вылезают наружу достаточно быстро, ошибки находятся, также очень быстро.
Открытый индекс - это, также, дата-продукт и у него куча метрик качества о которых я когда-нибудь расскажу в подробностях, но скорее это будет в форме выступления на конференции чем короткая заметка.
А пока покажу некоторые существенные отличия и сравнение GDS (Google Dataset Search) и Dateno.
#opendata #dateno #thoughts #datacatalogs #datasets
Telegram
Ivan Begtin
Dateno: первые опыты
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search…
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search…
К вопросу, во многом философскому, но с практическим умыслом, о том что считать данными, а что нет приведу пример в временными рядами. Не для всех, но для многих пользователей данные имеют географическую привязку и работая даже с большой данных стат наблюдений интересуют конкретные страны/страна и временной ряд получаемый из этой большой базы также имеет привязку к одной или двум странам. Но есть и задачи когда надо работать с базой целиком.
На некоторых порталах открытых данных, таких как портал данных ЕЦБ или Банка международных расчётов есть понятие набора данных, их мало и они велики, и есть понятие как раз временного ряда у каждого из которых есть пермалинк. Потребители есть у обоих типов данных. В Dateno эти данные уже частично агрегируются, около 30% карточек в Dateno - это агрегированные временные ряды и это оправдано поскольку пользователи, напомню, ищут чаще в привязке к территории. Но это выходит что отдельный тип данных, который может быть, а может не быть отдельным датасетом. Потому что ещё бывает так что временные ряды публикуют как-то ещё, а не в базе статистики. Что с этим делать для большей понятности? По хорошему разделять наборы данных и временные ряды, дать возможность фильтровать в поиске только их.
Аналогичным образом с геоданными/слоями карт. Слои карт - это чаще всего не файлы, а ссылки на точки подключения к API - ArcGIS или OGC. Их можно рассматривать как наборы данных, и иногда и часто так рассматривают, но, по хорошему, это некоторое отдельное явление, которое так и надо называть "Map layer".
Таких видов данных есть ещё некоторое количество, я же добавлю ещё что кроме них есть и более сложные случаи. Например, фиды новостей RSS и ATOM. Они данные или нет? ATOM фидов довольно много, только на европейском портале данных их более 141 тысячи, поскольку они являются одним из способов экспорта и доступа к геоданным на платформах на базе Geonetwork и ряда других.
ATOM Feed'ы также используются в каталогах данных на базе Thredds для доступа к метеорологическим данным.
Но, также их условно бесконечное число разбросано по интернету, как для доступа к новостям на сайтах, так и ко многим другим типам контента.
Можно ли выделять ATOM/RSS как отдельную категорию API и рассматривать их как данные и индексировать, например, нам в Dateno?
Ответ на этот вопрос содержится в контрвопросах - А зачем? А кому это нужно?
Один из важнейших критериев отнесения цифровых объектов/артефактов в к данным - это их востребованность целевой аудиторией тех кто с данными работает: дата инженеров, дата сайентистов, дата аналитиков, геоаналитиков, статистиков, экономистов, бизнес аналитиков и так далее.
И таких примеров очень много и всё больше возникает в процесс обнаружения новых, потенциально интересных источников данных.
P.S. Мне давно уже пора завести рубрику #whatisdata, пожалуй, буду помечать будущие размышления на эту тему именно ей
#whatisdata #thoughts #dateno #data
На некоторых порталах открытых данных, таких как портал данных ЕЦБ или Банка международных расчётов есть понятие набора данных, их мало и они велики, и есть понятие как раз временного ряда у каждого из которых есть пермалинк. Потребители есть у обоих типов данных. В Dateno эти данные уже частично агрегируются, около 30% карточек в Dateno - это агрегированные временные ряды и это оправдано поскольку пользователи, напомню, ищут чаще в привязке к территории. Но это выходит что отдельный тип данных, который может быть, а может не быть отдельным датасетом. Потому что ещё бывает так что временные ряды публикуют как-то ещё, а не в базе статистики. Что с этим делать для большей понятности? По хорошему разделять наборы данных и временные ряды, дать возможность фильтровать в поиске только их.
Аналогичным образом с геоданными/слоями карт. Слои карт - это чаще всего не файлы, а ссылки на точки подключения к API - ArcGIS или OGC. Их можно рассматривать как наборы данных, и иногда и часто так рассматривают, но, по хорошему, это некоторое отдельное явление, которое так и надо называть "Map layer".
Таких видов данных есть ещё некоторое количество, я же добавлю ещё что кроме них есть и более сложные случаи. Например, фиды новостей RSS и ATOM. Они данные или нет? ATOM фидов довольно много, только на европейском портале данных их более 141 тысячи, поскольку они являются одним из способов экспорта и доступа к геоданным на платформах на базе Geonetwork и ряда других.
ATOM Feed'ы также используются в каталогах данных на базе Thredds для доступа к метеорологическим данным.
Но, также их условно бесконечное число разбросано по интернету, как для доступа к новостям на сайтах, так и ко многим другим типам контента.
Можно ли выделять ATOM/RSS как отдельную категорию API и рассматривать их как данные и индексировать, например, нам в Dateno?
Ответ на этот вопрос содержится в контрвопросах - А зачем? А кому это нужно?
Один из важнейших критериев отнесения цифровых объектов/артефактов в к данным - это их востребованность целевой аудиторией тех кто с данными работает: дата инженеров, дата сайентистов, дата аналитиков, геоаналитиков, статистиков, экономистов, бизнес аналитиков и так далее.
И таких примеров очень много и всё больше возникает в процесс обнаружения новых, потенциально интересных источников данных.
P.S. Мне давно уже пора завести рубрику #whatisdata, пожалуй, буду помечать будущие размышления на эту тему именно ей
#whatisdata #thoughts #dateno #data
И, вдогонку, признаки хорошо организованной статистической системы:
1. Данные на первом месте (data-first). Это основной тип продуктов, вся остальная деятельность статслужбы должна быть вторичны.
2. Данные доступны в современных статистических (JSON-Stat, SDMX) или аналитических (Parquet) форматах. Или, как минимум, в CSV, JSON, XML с документацией схемы данных.
3. Все метаданных используемые в статбазах и публикациях систематизированы и ведутся в системе управления метаданными, с регулярными обновлениями.
4. Данные доступны с максимально возможной глубиной, с момента ведения переписей, сбора официальной статистики.
5. Доступ ко всем статданным и базам данных возможен через API
6. Все данные доступны для массовой выгрузки, без необходимости запрашивать по API тысячи индикаторов, но с возможностью скачать их целиком.
7. Исторические статистические сборники оцифрованы, доступны
8. Абсолютно все статистические сборники вначале публикуются онлайн и печатаются только в режиме печати по требованию
9. Статистические сборники для публикации в вебе создаются как интерактивные истории в модели data storytelling
10. Статистические отчеты, если они создаются как PDF файлы, являются книгами и публикуются только в случае значимых смысловых документов, но не для печати таблиц имеющихся в статистических базах данных
11. Статистику имеющую геопространственную привязку должна быть возможность увидеть на интерактивной карте.
12. Вся геопространственная статистика должна быть доступна как открытые данные и открытые OGC совместимые точки подключения к API WFS, WMS
13. Доступ к статистике осуществляется через каталог или поисковую систему по данным, включая таблицы, визуализацию, методологию и публикации.
14. Должна быть информационная политика дефрагментации данных. В рамках конкретной темы или отрасли должна быть возможность посмотреть или найти данные за любой период времени в любой форме, без необходимости искать в десятках статистических и ведомственных информационных системах.
#statistics #thoughts
1. Данные на первом месте (data-first). Это основной тип продуктов, вся остальная деятельность статслужбы должна быть вторичны.
2. Данные доступны в современных статистических (JSON-Stat, SDMX) или аналитических (Parquet) форматах. Или, как минимум, в CSV, JSON, XML с документацией схемы данных.
3. Все метаданных используемые в статбазах и публикациях систематизированы и ведутся в системе управления метаданными, с регулярными обновлениями.
4. Данные доступны с максимально возможной глубиной, с момента ведения переписей, сбора официальной статистики.
5. Доступ ко всем статданным и базам данных возможен через API
6. Все данные доступны для массовой выгрузки, без необходимости запрашивать по API тысячи индикаторов, но с возможностью скачать их целиком.
7. Исторические статистические сборники оцифрованы, доступны
8. Абсолютно все статистические сборники вначале публикуются онлайн и печатаются только в режиме печати по требованию
9. Статистические сборники для публикации в вебе создаются как интерактивные истории в модели data storytelling
10. Статистические отчеты, если они создаются как PDF файлы, являются книгами и публикуются только в случае значимых смысловых документов, но не для печати таблиц имеющихся в статистических базах данных
11. Статистику имеющую геопространственную привязку должна быть возможность увидеть на интерактивной карте.
12. Вся геопространственная статистика должна быть доступна как открытые данные и открытые OGC совместимые точки подключения к API WFS, WMS
13. Доступ к статистике осуществляется через каталог или поисковую систему по данным, включая таблицы, визуализацию, методологию и публикации.
14. Должна быть информационная политика дефрагментации данных. В рамках конкретной темы или отрасли должна быть возможность посмотреть или найти данные за любой период времени в любой форме, без необходимости искать в десятках статистических и ведомственных информационных системах.
#statistics #thoughts
Я тут задумался над тем какие практические инструменты с LLM внутри я использую в работе и для чего хотелось бы использовать ещё. Хотелось бы, для многого конечно, но не всё ещё существует
Самое очевидное это переписывание текстов с помощью DeepL Write. Очень удобно для переписке и публикаций не на родном языке, поскольку сильно выправляет текст. Похоже на Grammarly, но ощущение что итоговый текст гораздо лучше и поддерживается не только английский язык. Главный минус пока только в том что поддерживаются только 8 языков. В любом случае очень удобно для публикации в англоязычных и других соцсетях
Совсем не такое очевидное, но важное для меня это сбор информации о дата каталогах. Это довольно специфическая лично моя задача по обновлению реестра каталогов данных в Dateno. Этот процесс на текущей стадии ручной, поскольку автоматизированный ранее собранных каталогов уже выполнен и оставшаяся часть работы - это ручная разметка. В частности вручную проставляется инфа по каталогу данных:
- название
- описание
- название владельца
- тип владельца (гос-во, муниципалитет, ученые и тд.)
- тематики
- теги
А также простановка геопривязки для тех ресурсов у которых её нет или если выясняется что они уровня регионов.
Это много ручной работы напрямую влияющей на качество данных в Dateno, поскольку тип владельца, геопривязки и тематики идут в фасеты поиска, а остальные поля отображаются в карточках датасетов.
Оказалось что Perplexity отлично выдаёт ответы на такие вопросы как:
- Who owns <> website ?
- About what this website is <> ?
А также, что очень практически удобно, Perplexity умеет точно отвечать на такие вопросы как "What is ISO3166-2 code of the Magallanes and Chilean Antarctica ?" и выдавать точный код.
Скорее всего Perplexity можно заменить на другую модель, но и текущие результаты вполне полезны.
Сейчас в Dateno около 18% (3.4 миллиона) наборов данных не имеют пометки типа владельца данных, а 2.4 миллиона не имеют привязки к стране/территории.
Это, в любом случае лучше чем у Google Dataset Search, но всё ещё недостаточно хорошо.
Применение LLM в повышении качества метаданных кажется очень реалистичной задачей.
#ai #thoughts #dateno #datasets #data
Самое очевидное это переписывание текстов с помощью DeepL Write. Очень удобно для переписке и публикаций не на родном языке, поскольку сильно выправляет текст. Похоже на Grammarly, но ощущение что итоговый текст гораздо лучше и поддерживается не только английский язык. Главный минус пока только в том что поддерживаются только 8 языков. В любом случае очень удобно для публикации в англоязычных и других соцсетях
Совсем не такое очевидное, но важное для меня это сбор информации о дата каталогах. Это довольно специфическая лично моя задача по обновлению реестра каталогов данных в Dateno. Этот процесс на текущей стадии ручной, поскольку автоматизированный ранее собранных каталогов уже выполнен и оставшаяся часть работы - это ручная разметка. В частности вручную проставляется инфа по каталогу данных:
- название
- описание
- название владельца
- тип владельца (гос-во, муниципалитет, ученые и тд.)
- тематики
- теги
А также простановка геопривязки для тех ресурсов у которых её нет или если выясняется что они уровня регионов.
Это много ручной работы напрямую влияющей на качество данных в Dateno, поскольку тип владельца, геопривязки и тематики идут в фасеты поиска, а остальные поля отображаются в карточках датасетов.
Оказалось что Perplexity отлично выдаёт ответы на такие вопросы как:
- Who owns <> website ?
- About what this website is <> ?
А также, что очень практически удобно, Perplexity умеет точно отвечать на такие вопросы как "What is ISO3166-2 code of the Magallanes and Chilean Antarctica ?" и выдавать точный код.
Скорее всего Perplexity можно заменить на другую модель, но и текущие результаты вполне полезны.
Сейчас в Dateno около 18% (3.4 миллиона) наборов данных не имеют пометки типа владельца данных, а 2.4 миллиона не имеют привязки к стране/территории.
Это, в любом случае лучше чем у Google Dataset Search, но всё ещё недостаточно хорошо.
Применение LLM в повышении качества метаданных кажется очень реалистичной задачей.
#ai #thoughts #dateno #datasets #data
Какой хороший инструмент, но без открытого кода.
Я эту фразу в последние годы повторяю чаще чем хотелось бы. Применительно почти ко всем инструментам, кроме тех где отсутствие кода оправдано. Например, выбираю инструмент для создания резервных копий и это сводится в итоге к Borg или Restic, хотя есть коммерческие альтернативы и неплохие. Но зачем они нужны если есть не хуже, а иногда и лучше с открытым кодом?
Или инструменты обработки и очистки данных. Да, их много, но чаще всего достаточно OpenRefine, или инструментов вроде pandas, polars, duckdb и др. для работы с датафреймами.
Или для ведения заметок, зачем нужны другие если есть Obsidian ? Конечно много хороших инструментов, но реально Obsidian закрывает большую часть задач.
Я не единственный кто так рассуждает. Достаточно подсчитать ежемесячные/ежегодные расходы на ПО и сервисы по подписке чтобы понимать реальную нагрузку на свой кошелёк или кошелёк компании.
Всё это про ниши продуктов и про то какие их свойства и характеристики подталкивают к тому чтобы их купить и какие приводят к поиску бесплатных альтернатив. Главный критерий - это то сколько усилий нужно приложить и насколько продуктовые характеристики реально создают качество жизни, удобство работы и тд.
Я бы распределил эти фичи следующим образом:
1. AI powered. Там где это уместно, там где это логично, там где это необходимо, там где есть для этого потребность - это реально повышает качество продукта. У нас в Dateno такое давно назрело и мы всё ещё планируем и ищем человека под fulltime работу на эти задачи с учётом и оговоркой что у нас международный проект и у него есть своя специфика. Но AI powered для данных я вижу много где, в первую очередь в многочисленных аналитических сервисах которые на основе пользовательских данных генерируют разного рода дашборды. То на что аналитик может потратить несколько недель делается за несколько часов.
2. Интеграция с облаками. То что является маст-хэв фичами для почти всех инструментов для работы с данными. Так чтобы напрямую подключаться к S3 совместимому хранилищу, но с оговоркой что такие возможности стали уже по умолчанию у много каких открытых инструментов и зачем платить за коммерческую фичу.
3. Множество устройств. Особенно в части перехода с небольшого числа личных устройств на устройства для небольшой команды. У меня перед глазами есть как минимум такой инструмент и сервис как Tailscale, но это распространяется и на другие подобного рода zero-config сервисы.
Список не исчерпывающий, но важный в том что наиболее востребована комбинация стоимости воспроизведения сервиса или продукта и пользы которую он приносит.
А вот, к примеру, сейчас сложно сделать сервис ETL/ELT которому нет замены с открытым кодом
Поэтому работая над текущими продуктами всегда нужен ответ как минимум на 2 вопроса:
1) Есть ли у продукта открытая альтернатива?
2) Можно ли то же самое сделать с помощью ChatGPT ?
#thoughts #products
Я эту фразу в последние годы повторяю чаще чем хотелось бы. Применительно почти ко всем инструментам, кроме тех где отсутствие кода оправдано. Например, выбираю инструмент для создания резервных копий и это сводится в итоге к Borg или Restic, хотя есть коммерческие альтернативы и неплохие. Но зачем они нужны если есть не хуже, а иногда и лучше с открытым кодом?
Или инструменты обработки и очистки данных. Да, их много, но чаще всего достаточно OpenRefine, или инструментов вроде pandas, polars, duckdb и др. для работы с датафреймами.
Или для ведения заметок, зачем нужны другие если есть Obsidian ? Конечно много хороших инструментов, но реально Obsidian закрывает большую часть задач.
Я не единственный кто так рассуждает. Достаточно подсчитать ежемесячные/ежегодные расходы на ПО и сервисы по подписке чтобы понимать реальную нагрузку на свой кошелёк или кошелёк компании.
Всё это про ниши продуктов и про то какие их свойства и характеристики подталкивают к тому чтобы их купить и какие приводят к поиску бесплатных альтернатив. Главный критерий - это то сколько усилий нужно приложить и насколько продуктовые характеристики реально создают качество жизни, удобство работы и тд.
Я бы распределил эти фичи следующим образом:
1. AI powered. Там где это уместно, там где это логично, там где это необходимо, там где есть для этого потребность - это реально повышает качество продукта. У нас в Dateno такое давно назрело и мы всё ещё планируем и ищем человека под fulltime работу на эти задачи с учётом и оговоркой что у нас международный проект и у него есть своя специфика. Но AI powered для данных я вижу много где, в первую очередь в многочисленных аналитических сервисах которые на основе пользовательских данных генерируют разного рода дашборды. То на что аналитик может потратить несколько недель делается за несколько часов.
2. Интеграция с облаками. То что является маст-хэв фичами для почти всех инструментов для работы с данными. Так чтобы напрямую подключаться к S3 совместимому хранилищу, но с оговоркой что такие возможности стали уже по умолчанию у много каких открытых инструментов и зачем платить за коммерческую фичу.
3. Множество устройств. Особенно в части перехода с небольшого числа личных устройств на устройства для небольшой команды. У меня перед глазами есть как минимум такой инструмент и сервис как Tailscale, но это распространяется и на другие подобного рода zero-config сервисы.
Список не исчерпывающий, но важный в том что наиболее востребована комбинация стоимости воспроизведения сервиса или продукта и пользы которую он приносит.
А вот, к примеру, сейчас сложно сделать сервис ETL/ELT которому нет замены с открытым кодом
Поэтому работая над текущими продуктами всегда нужен ответ как минимум на 2 вопроса:
1) Есть ли у продукта открытая альтернатива?
2) Можно ли то же самое сделать с помощью ChatGPT ?
#thoughts #products
А что есть наборы данных?
Мысли к которым я регулярно возвращаюсь - это размышления о том что есть данные, чем они не являются и то по каким критериям считать что цифровой объект это дата файл или датасет.
Вот несколько примеров для размышления. Репозитории данных TextGRID [1], Virtual Language Observatory [2] и ряда других репозиториев связанных с компьютерной лингвистикой содержат множество цифровых объектов которые, в целом, можно относить к данным, но одновременно с этим там огромное число мультимедиа объектов: аудио, изображений и видео, а также множество текстов.
С точки зрения компьютерных лингвистов это, наверняка, данные, но для всех остальных они немашиночитаемы. Можно ли считать их датасетами? Когда эти же цифровые объекты представлены как наборы данных для машинного обучения, то это точно датасеты, без сомнений. Почему? Потому что у них потребители дата сайентисты. А чем хуже компьютерные лингвисты тогда? Вот, в том то и вопрос.
Другой пример, обязательные к раскрытию документы публичных компаний. В США публикуют файлы через систему SEC, в других странах есть аналогичное, а также сайты бирж. Среди их документов много Excel файлов и табличек внутри файлов PDF и MS Word. Можно ли рассматривать их как датасеты? С точки зрения финансовых аналитиков это, как минимум, файлы с данными. А финансовые аналитики это тоже пользователи данных, и одни из самых активных. Так как, можно ли трактовать их как датасеты?
Или, к примеру, документы прайс листов которые компании публикуют у себя на сайтах и некоторых площадках. Это ни в какой форме не public domain, тут вероятно и авторское право присутствует. С другой стороны, никто же на него не покушается, если индексировать их поисковиком, то просто в условиях использования устанавливать что права защищены. Но можно ли такие файлы считать наборами данных? По моему скорее нет, чем да, но есть сомнения.
Главные отличия датасета от любого просто лежащего в интернете файла с данными - это наличие карточки метаданных, контент машиночитаем и наличествует квалифицированный потребитель. Но очень и очень много случаев когда потребитель не так квалифицирован, данные не совсем машиночитаемы, а карточка с метаданными минимальна.
Ссылки:
[1] https://textgridrep.org
[2] https://vlo.clarin.eu
#opendata #datasets #thoughts
Мысли к которым я регулярно возвращаюсь - это размышления о том что есть данные, чем они не являются и то по каким критериям считать что цифровой объект это дата файл или датасет.
Вот несколько примеров для размышления. Репозитории данных TextGRID [1], Virtual Language Observatory [2] и ряда других репозиториев связанных с компьютерной лингвистикой содержат множество цифровых объектов которые, в целом, можно относить к данным, но одновременно с этим там огромное число мультимедиа объектов: аудио, изображений и видео, а также множество текстов.
С точки зрения компьютерных лингвистов это, наверняка, данные, но для всех остальных они немашиночитаемы. Можно ли считать их датасетами? Когда эти же цифровые объекты представлены как наборы данных для машинного обучения, то это точно датасеты, без сомнений. Почему? Потому что у них потребители дата сайентисты. А чем хуже компьютерные лингвисты тогда? Вот, в том то и вопрос.
Другой пример, обязательные к раскрытию документы публичных компаний. В США публикуют файлы через систему SEC, в других странах есть аналогичное, а также сайты бирж. Среди их документов много Excel файлов и табличек внутри файлов PDF и MS Word. Можно ли рассматривать их как датасеты? С точки зрения финансовых аналитиков это, как минимум, файлы с данными. А финансовые аналитики это тоже пользователи данных, и одни из самых активных. Так как, можно ли трактовать их как датасеты?
Или, к примеру, документы прайс листов которые компании публикуют у себя на сайтах и некоторых площадках. Это ни в какой форме не public domain, тут вероятно и авторское право присутствует. С другой стороны, никто же на него не покушается, если индексировать их поисковиком, то просто в условиях использования устанавливать что права защищены. Но можно ли такие файлы считать наборами данных? По моему скорее нет, чем да, но есть сомнения.
Главные отличия датасета от любого просто лежащего в интернете файла с данными - это наличие карточки метаданных, контент машиночитаем и наличествует квалифицированный потребитель. Но очень и очень много случаев когда потребитель не так квалифицирован, данные не совсем машиночитаемы, а карточка с метаданными минимальна.
Ссылки:
[1] https://textgridrep.org
[2] https://vlo.clarin.eu
#opendata #datasets #thoughts
Скоро надо будет подводить итоги этого года. Личные, профессиональные и всякие. У меня не получится изложить их в один текст/пост, начну с того что пришлось отложить и что пока не сделано. Всё это, идёт не первым приоритетом потому что first things first.
Вот наиболее технические отложенные задачи:
- Новый интерфейс для Ruarxive. Уже давно откладываемая задача на которую нет ресурсов это перезагрузка Национального цифрового архива ruarxive.org так чтобы сделать нормальный поиск по архивам, индексирование WARC файлов и удобный поиск по ним. Это оказалось не то чтобы сложной задачей, но требующей времени и концентрации хотя бы по написанию ТЗ чтобы к ней кого-то привлечь.
- Архивация госсайтов в РФ. Надо провести повторную архивацию всех ключевых российских госресурсов, в особенности всех цифровых ресурсов Росстата, сохранность их вызывает большие опасения. Но это стало сильно сложнее, многие российские госсайты теперь активно блокируют внешние краулеры, особенно из других стран
- Автоматизация документирования датасетов и баз данных. Нарастающая по важности задача поскольку данных всё больше, документировать их вручную всё более болезненно. Есть наработки в виде инструмента metacrafter'а и рассеяного кода, но надо всё свести конкретную модель и архитектуру. Скорее всего это постепенно сдвигается в сторону повышения качества Dateno и нового качества поиска.
- Много неопубликованных датасетов. По многим странам, не только по РФ. Например, база всего законодательства Казахстана в структурированном виде. Данные готовы, но не оформлены, не описаны, недостаточно ещё задокументированы.
- Библиотека универсального доступа к каталогам данных. Очень давно об этом думаю о том как сделать универсальный инструмент для поиска и доступа к данным в типовых каталогах, CKAN, DKAN, DataVerse, GeoNode и десятку других. Потому что в этом есть необходимость и довольно актуальная. Возможно наиболее логично перенести это в Dateno и сдвинуть в сторону сбора метаданных.
- Перезапустить оценку понятности языка PlainRussian. Возможно отложенное надолго поскольку LLM'ки типа GPT умеют это лучше. Конкурировать с ними сложно и непонятно зачем. Туда же относится создание оценки понятности языка для других языков, таких как армянский язык. Ничего сложного в этом нет, но опять же LLM дают лучший результат.
- Незавершённые проекты в Open Data Armenia. Многое всё ещё существует в полусобранных проектах, надо собраться с мыслями и силами довести их до продуктового состояния и продолжать развивать сообщество не только конкурсами, но и общей инфраструктурой данных.
- Неопубликованные курсы. По веб архивации, по digital humanities, по data discovery и по автоматизации каталогизации данных и их извлечению. И про обработку данных новыми инструментами.
- Недописанные книги/тексты/мануалы. Их как-то очень много, про личные тексты написать отдельно надо, а про рабочие - это тексты/книга про то как устроены данные и, что даже важнее, метаданные.
Про более приоритетное, особенно про Dateno, я ещё напишу позже.
Передаю эстафету всем тем кто думает о несделанном и думает о грузе несделанного о за прошлый год и как это сделать в следующем году.
#endofyear #thoughts #thinking #plans
Вот наиболее технические отложенные задачи:
- Новый интерфейс для Ruarxive. Уже давно откладываемая задача на которую нет ресурсов это перезагрузка Национального цифрового архива ruarxive.org так чтобы сделать нормальный поиск по архивам, индексирование WARC файлов и удобный поиск по ним. Это оказалось не то чтобы сложной задачей, но требующей времени и концентрации хотя бы по написанию ТЗ чтобы к ней кого-то привлечь.
- Архивация госсайтов в РФ. Надо провести повторную архивацию всех ключевых российских госресурсов, в особенности всех цифровых ресурсов Росстата, сохранность их вызывает большие опасения. Но это стало сильно сложнее, многие российские госсайты теперь активно блокируют внешние краулеры, особенно из других стран
- Автоматизация документирования датасетов и баз данных. Нарастающая по важности задача поскольку данных всё больше, документировать их вручную всё более болезненно. Есть наработки в виде инструмента metacrafter'а и рассеяного кода, но надо всё свести конкретную модель и архитектуру. Скорее всего это постепенно сдвигается в сторону повышения качества Dateno и нового качества поиска.
- Много неопубликованных датасетов. По многим странам, не только по РФ. Например, база всего законодательства Казахстана в структурированном виде. Данные готовы, но не оформлены, не описаны, недостаточно ещё задокументированы.
- Библиотека универсального доступа к каталогам данных. Очень давно об этом думаю о том как сделать универсальный инструмент для поиска и доступа к данным в типовых каталогах, CKAN, DKAN, DataVerse, GeoNode и десятку других. Потому что в этом есть необходимость и довольно актуальная. Возможно наиболее логично перенести это в Dateno и сдвинуть в сторону сбора метаданных.
- Перезапустить оценку понятности языка PlainRussian. Возможно отложенное надолго поскольку LLM'ки типа GPT умеют это лучше. Конкурировать с ними сложно и непонятно зачем. Туда же относится создание оценки понятности языка для других языков, таких как армянский язык. Ничего сложного в этом нет, но опять же LLM дают лучший результат.
- Незавершённые проекты в Open Data Armenia. Многое всё ещё существует в полусобранных проектах, надо собраться с мыслями и силами довести их до продуктового состояния и продолжать развивать сообщество не только конкурсами, но и общей инфраструктурой данных.
- Неопубликованные курсы. По веб архивации, по digital humanities, по data discovery и по автоматизации каталогизации данных и их извлечению. И про обработку данных новыми инструментами.
- Недописанные книги/тексты/мануалы. Их как-то очень много, про личные тексты написать отдельно надо, а про рабочие - это тексты/книга про то как устроены данные и, что даже важнее, метаданные.
Про более приоритетное, особенно про Dateno, я ещё напишу позже.
Передаю эстафету всем тем кто думает о несделанном и думает о грузе несделанного о за прошлый год и как это сделать в следующем году.
#endofyear #thoughts #thinking #plans
Немного отвлекаясь от сугубо технических тем и возвращаясь к сбору геотреков граждан государством в РФ, а ранее историям про госозеро и про огосударствление биометрических данных.
Помимо шуток и не шуток про тотальную слежку тут важно понимать что сама ситуация абсолютно уникальная. Я лично не знаю ни одну страну где государство де-факто национализировало бы данные бизнеса в таких количествах. Обычно всё происходит иначе и взаимоотношения гос-ва и дата-корпораций состоит из 3-х частей:
1) Корпорации и общественность лоббируют доступность тех или иных госданных которые предоставляются по разным моделям: открытые данные, доверенные операторы, покупка и продажа и тд.
2) Власти принуждают корпорации отдавать свои данные рынку, через антимонопольное давление, через программы по обмену данными (data sharing), через иные формы поощрения использования и предоставления данных
3) Спецслужбы/разведки разными непубличными способами взаимодействуют с крупнейшими сборщиками и операторами данных для решения госзадач в их ведении.
Собственно первые два типа взаимоотношений мы регулярно наблюдаем, про третий тип иногда происходят утечки, но в целом это то как мир развивается.
В России всё происходит иначе. Государство в лице фед. пр-ва шаг за шагом национализирует даже не просто базы данных, а целые блоки общественной жизни которые находятся у разного рода владельцев, дата корпораций и тд. и далее может раздавать эти данные кому надо. Скорее всего тем кто окажется ближе к лицам принимающающим решения.
Данные дата-корпораций становятся из их актива в государственный ресурс сдачи и раздачи. Мне это напоминает описанное в книгах Симона Гдальевича Кордонского, но перенесённое из физического пространства, в цифровое. Цифровые компании превращаются в цифровых бояр (или помещиков), оказываются во всё большей зависимости от федеральной власти, должны жить по определённым правилам игры не все из которых изложены нормативно.
Усиливаться эти цифровые бояре могут только путём приобретения адм. ресурса и укрупнением. Собственно подобное развитие отношений государство-бизнес, вместе с другими факторами, естественно ведёт к чеболизации всей этой сферы.
Честно говоря у меня каких-либо выводов нет, современный цифровой государственный патернализм стремительно набирает обороты, и пока какой-то большой цифровой катастрофы не произойдёт, то и шансов на то что этот процесс остановится или замедлится, нет.
P.S. Хочется добавить что такими темпами цифровая катастрофа неизбежна как один из чёрных лебедей который поломает цифровую инфраструктуру и что всё это выглядит довольно хрупко, но, думаю, что это и так очевидно.
#thoughts #russia #privacy
Помимо шуток и не шуток про тотальную слежку тут важно понимать что сама ситуация абсолютно уникальная. Я лично не знаю ни одну страну где государство де-факто национализировало бы данные бизнеса в таких количествах. Обычно всё происходит иначе и взаимоотношения гос-ва и дата-корпораций состоит из 3-х частей:
1) Корпорации и общественность лоббируют доступность тех или иных госданных которые предоставляются по разным моделям: открытые данные, доверенные операторы, покупка и продажа и тд.
2) Власти принуждают корпорации отдавать свои данные рынку, через антимонопольное давление, через программы по обмену данными (data sharing), через иные формы поощрения использования и предоставления данных
3) Спецслужбы/разведки разными непубличными способами взаимодействуют с крупнейшими сборщиками и операторами данных для решения госзадач в их ведении.
Собственно первые два типа взаимоотношений мы регулярно наблюдаем, про третий тип иногда происходят утечки, но в целом это то как мир развивается.
В России всё происходит иначе. Государство в лице фед. пр-ва шаг за шагом национализирует даже не просто базы данных, а целые блоки общественной жизни которые находятся у разного рода владельцев, дата корпораций и тд. и далее может раздавать эти данные кому надо. Скорее всего тем кто окажется ближе к лицам принимающающим решения.
Данные дата-корпораций становятся из их актива в государственный ресурс сдачи и раздачи. Мне это напоминает описанное в книгах Симона Гдальевича Кордонского, но перенесённое из физического пространства, в цифровое. Цифровые компании превращаются в цифровых бояр (или помещиков), оказываются во всё большей зависимости от федеральной власти, должны жить по определённым правилам игры не все из которых изложены нормативно.
Усиливаться эти цифровые бояре могут только путём приобретения адм. ресурса и укрупнением. Собственно подобное развитие отношений государство-бизнес, вместе с другими факторами, естественно ведёт к чеболизации всей этой сферы.
Честно говоря у меня каких-либо выводов нет, современный цифровой государственный патернализм стремительно набирает обороты, и пока какой-то большой цифровой катастрофы не произойдёт, то и шансов на то что этот процесс остановится или замедлится, нет.
P.S. Хочется добавить что такими темпами цифровая катастрофа неизбежна как один из чёрных лебедей который поломает цифровую инфраструктуру и что всё это выглядит довольно хрупко, но, думаю, что это и так очевидно.
#thoughts #russia #privacy
И ещё про итоги года, самое время вспомнить про тренды открытости и доступности данных в мире.
1. Больше международных данных. Совершенно точно общедоступных данных становится больше, большая часть новых данных публикуются как открытые (под свободными) лицензиями. Например, на большинстве сайтов активных межгосударственных организаций разделы "Статистика" и "Исследования" переименовали в разделы "Данные" или "Данные и статистика" и "Данные и исследования". Я бы даже сказал что это стало нормой для почти всех структур входящих в ООН, к примеру.
2. Больше данных городов и муниципалитетов. Местные/городские данные один из приоритетов OGP, порталы данных городов появляются во все большем числе стран и наиболее активно создаются порталы геоданных. А также именно в городах чаще используют SaaS решения вроде OpenDataSoft и ArcGIS Hub.
3. Больше данных для машинного обучения. Этот тренд исключительно нарастает, помимо Kaggle и Hugging Face данные публикуют на многочисленных других порталах и сайтах компаний, исследовательских центров и так далее.
4. Постепенное проникновение дата инженерии и дата сайенс в открытые данные. Это происходит медленно но в последние пару лет особенно заметно и то что данные всё чаще доступны для массовой выгрузки (bulk download) и в форматах вроде parquet (данные из порталов OpenDataSoft, данные французского нац портала портала, данные нац портала Малайзии)
5. Больше особенно ценных данных. Инициатива High Value Datasets в Европейском союзе развивается и за его пределами. Появляется всё больше данных имеющих прямую измеренную пользу для экономики и всё более закрепляется политика государств что открытость этих данных несёт больше пользы обществу и бизнесу в частности чем торговля ими.
6. Расширение вклада биг техов в открытость данных. Это касается тех данных которые касаются общей инфраструктуры, данных полученных с помощью ИИ, данных необходимых для обучения LLM моделей. Чаще всего это не собственные данные, а чьи-то ещё переупакованные, обогащённые и тем не менее полезные. Например, данные в рамках Overture Maps.
7. Усиление движения открытого доступа (Open Access). Что выражается не только в том что повышается доступность научных статей, но и в появлении всё большего числа порталов исследовательских данных открытого доступа. Также становится больше специализированных порталов данных привязанных к конкретным научным дисциплинам и их специфике.
8. Сложность восприятия ИИ среди open data активистов. Главными бенефициарами открытости не только данных, но и любых других свободно распространяемых материалов оказываются big tech компании, а теперь ещё и OpenAI и лидеры рынка LLM моделей. На многих волонтеров начинает давить ощущение что именно биг техи, а не общество выигрывают от открытости данных.
#opendata #opengov #data #thoughts
1. Больше международных данных. Совершенно точно общедоступных данных становится больше, большая часть новых данных публикуются как открытые (под свободными) лицензиями. Например, на большинстве сайтов активных межгосударственных организаций разделы "Статистика" и "Исследования" переименовали в разделы "Данные" или "Данные и статистика" и "Данные и исследования". Я бы даже сказал что это стало нормой для почти всех структур входящих в ООН, к примеру.
2. Больше данных городов и муниципалитетов. Местные/городские данные один из приоритетов OGP, порталы данных городов появляются во все большем числе стран и наиболее активно создаются порталы геоданных. А также именно в городах чаще используют SaaS решения вроде OpenDataSoft и ArcGIS Hub.
3. Больше данных для машинного обучения. Этот тренд исключительно нарастает, помимо Kaggle и Hugging Face данные публикуют на многочисленных других порталах и сайтах компаний, исследовательских центров и так далее.
4. Постепенное проникновение дата инженерии и дата сайенс в открытые данные. Это происходит медленно но в последние пару лет особенно заметно и то что данные всё чаще доступны для массовой выгрузки (bulk download) и в форматах вроде parquet (данные из порталов OpenDataSoft, данные французского нац портала портала, данные нац портала Малайзии)
5. Больше особенно ценных данных. Инициатива High Value Datasets в Европейском союзе развивается и за его пределами. Появляется всё больше данных имеющих прямую измеренную пользу для экономики и всё более закрепляется политика государств что открытость этих данных несёт больше пользы обществу и бизнесу в частности чем торговля ими.
6. Расширение вклада биг техов в открытость данных. Это касается тех данных которые касаются общей инфраструктуры, данных полученных с помощью ИИ, данных необходимых для обучения LLM моделей. Чаще всего это не собственные данные, а чьи-то ещё переупакованные, обогащённые и тем не менее полезные. Например, данные в рамках Overture Maps.
7. Усиление движения открытого доступа (Open Access). Что выражается не только в том что повышается доступность научных статей, но и в появлении всё большего числа порталов исследовательских данных открытого доступа. Также становится больше специализированных порталов данных привязанных к конкретным научным дисциплинам и их специфике.
8. Сложность восприятия ИИ среди open data активистов. Главными бенефициарами открытости не только данных, но и любых других свободно распространяемых материалов оказываются big tech компании, а теперь ещё и OpenAI и лидеры рынка LLM моделей. На многих волонтеров начинает давить ощущение что именно биг техи, а не общество выигрывают от открытости данных.
#opendata #opengov #data #thoughts
Очень много архивных данных
За выходные накопилось очень много что написать, но честно говоря я решил немного отдохнуть и отдых этот - это приведение в порядок личных архивов. Вернее они хоть и личные, но более менее рассортированные большие и малые датасеты, архивы веб-сайтов, изображений, медиа, данных замороженных или не стартовавших проектов, действительно личных файлов и много всего другого.
Но, есть время накапливать данные на любых носителях, а есть время приводить всё в порядок, складывать в NAS, резервировать критичное с защищённом облаке и так далее. Уверен что я не единственный кто занимается подобной уборкой когда есть свободное время.
Что из этого стоит записать на будущее:
1. Всячески избегать большого числа множества схожих, но очень малых файлов. Их архивация - это долго, больно и неправильно. Лучше ещё на этапе их получения/извлечения сразу складывать их в контейнеры вроде архивных файлов (zip, tar), баз данных (sqlite, duckdb) или монтируемых файловых систем вроде veracrypt. Потому что при всех рисках битых секторов, архивация множества мелких файлов очень медленный процесс.
2. Все чувствительные файлы всегда хранить в зашифрованных контейнерах (всё тот же veracrypt поможет). На случай повреждения таких файлов, держать несколько их копий. Вся работа с чувствительными данными также всегда должна быть внутри зашифрованных контейнеров.
3. Правило 3-2-1 для резервных копий очень простое и придумали его не дураки. Придерживаясь его можно избежать наиболее неприятных ситуаций с потерей данных.
4. Файлы веб-архивов неэффективны для сжатия. По умолчанию инструменты работы с WARC файлами поддерживают только если файлы не сжаты или сжаты gzip, а сами файлы вне зависимости от типа хранятся вперемешку. WARC устарел как контейнер, но хранение множества мелких файлов гораздо хуже и сопряжено с потерей метаданных.
5. Документация - это главный технический долг в отношении данных и архивов. Особенно когда восстанавливаешь архивы 20 и более летней давности. Иногда остаётся код с помощью которых данные были получены, иногда первичные данные, иногда даже описание из первоисточника, но полная прослеживаемость есть далеко не всегда.
6. Длинные не-латинизированные имена файлов - это зло. При копировании из NTFS в файловые системы Linux слишком часто возникают ошибки из-за длинных названий файлов на кириллице. Решается это переименованием или помещением файла в контейнер, но тем не менее
Впрочем, все выводы кажутся очевидными и касаются не только личных архивов. А многое требует осмысления как архивными данными работать, какие интерфейсы должны быть доступны. И документация, технический долг документации на данные безбрежен. Трудоёмкость её написания зачастую выше трудоёмкость сбора самих данных, но тут какого-то простого решения не наблюдается.
#datahoarding #thoughts #backups #data
За выходные накопилось очень много что написать, но честно говоря я решил немного отдохнуть и отдых этот - это приведение в порядок личных архивов. Вернее они хоть и личные, но более менее рассортированные большие и малые датасеты, архивы веб-сайтов, изображений, медиа, данных замороженных или не стартовавших проектов, действительно личных файлов и много всего другого.
Но, есть время накапливать данные на любых носителях, а есть время приводить всё в порядок, складывать в NAS, резервировать критичное с защищённом облаке и так далее. Уверен что я не единственный кто занимается подобной уборкой когда есть свободное время.
Что из этого стоит записать на будущее:
1. Всячески избегать большого числа множества схожих, но очень малых файлов. Их архивация - это долго, больно и неправильно. Лучше ещё на этапе их получения/извлечения сразу складывать их в контейнеры вроде архивных файлов (zip, tar), баз данных (sqlite, duckdb) или монтируемых файловых систем вроде veracrypt. Потому что при всех рисках битых секторов, архивация множества мелких файлов очень медленный процесс.
2. Все чувствительные файлы всегда хранить в зашифрованных контейнерах (всё тот же veracrypt поможет). На случай повреждения таких файлов, держать несколько их копий. Вся работа с чувствительными данными также всегда должна быть внутри зашифрованных контейнеров.
3. Правило 3-2-1 для резервных копий очень простое и придумали его не дураки. Придерживаясь его можно избежать наиболее неприятных ситуаций с потерей данных.
4. Файлы веб-архивов неэффективны для сжатия. По умолчанию инструменты работы с WARC файлами поддерживают только если файлы не сжаты или сжаты gzip, а сами файлы вне зависимости от типа хранятся вперемешку. WARC устарел как контейнер, но хранение множества мелких файлов гораздо хуже и сопряжено с потерей метаданных.
5. Документация - это главный технический долг в отношении данных и архивов. Особенно когда восстанавливаешь архивы 20 и более летней давности. Иногда остаётся код с помощью которых данные были получены, иногда первичные данные, иногда даже описание из первоисточника, но полная прослеживаемость есть далеко не всегда.
6. Длинные не-латинизированные имена файлов - это зло. При копировании из NTFS в файловые системы Linux слишком часто возникают ошибки из-за длинных названий файлов на кириллице. Решается это переименованием или помещением файла в контейнер, но тем не менее
Впрочем, все выводы кажутся очевидными и касаются не только личных архивов. А многое требует осмысления как архивными данными работать, какие интерфейсы должны быть доступны. И документация, технический долг документации на данные безбрежен. Трудоёмкость её написания зачастую выше трудоёмкость сбора самих данных, но тут какого-то простого решения не наблюдается.
#datahoarding #thoughts #backups #data
Продолжая рассуждения про OpenRefine, я какое-то время довольно быстро сделал движок mongorefine [1] в котором воспроизвёл некоторые ключевые функции OpenRefine в в виде библиотеки поверх MongoDB. Но после тестов выяснилось что хотя это и очень гибкая штука, но безбожно медленная.
К сравнению DuckDB или Polars не такие гибкие, зато работают с данными значительно большего объёма на десктопе.
У OpenRefine есть две ключевые фичи которые наиболее трудоёмки:
1. История всех изменений датасета. Это не так сложно как может показаться, но на большом датасете начинает кушать много дискового пространства.
2. UI для пользователя. Без UI, в виде библиотеки - эта задача проста. С UI - это становится не так просто. Вот я, например, нужными навыками для создания таких сложных пользовательских интерфейсов не обладаю.
Остальные фичи касаются интеграции с внешними сервисами, Wikidata и тд. Тут важнее интерфейс для плагинов, а не сразу сами плагины.
Я для такого рисовал схемку как можно было бы организовать правильно, но, пока забросил эту идею.
#opensource #datatools #thoughts
К сравнению DuckDB или Polars не такие гибкие, зато работают с данными значительно большего объёма на десктопе.
У OpenRefine есть две ключевые фичи которые наиболее трудоёмки:
1. История всех изменений датасета. Это не так сложно как может показаться, но на большом датасете начинает кушать много дискового пространства.
2. UI для пользователя. Без UI, в виде библиотеки - эта задача проста. С UI - это становится не так просто. Вот я, например, нужными навыками для создания таких сложных пользовательских интерфейсов не обладаю.
Остальные фичи касаются интеграции с внешними сервисами, Wikidata и тд. Тут важнее интерфейс для плагинов, а не сразу сами плагины.
Я для такого рисовал схемку как можно было бы организовать правильно, но, пока забросил эту идею.
#opensource #datatools #thoughts