В поиска крипто-датасетов по блокчейну, биткоину, Ethereum и тд. Вот наглядный пример поиска в Google Dataset Search, в Perplexity, в AI помощнике Quora и в Dateno при поиске по слову "Ethereum".
ИИ помощники выдают неплохие результаты, но очень ограниченные основными первоисточниками. Google Dataset Search выдаёт разное, делая акцент на Kaggle и свои продукты, но сразу после первой страницы идут разного рода коммерческие и недоступные источники.
В Dateno сейчас всего 34 результата по слову "Ethereum" и часть ссылок уже не работает, удалены в первоисточнике.
Это один из примеров запросов и тем где требуется больше усилий чем просто собрать метаданные откуда попало.
Я на днях анализировал почему датасетов по крипте в Dateno мало и следующие выводы:
1. Открытые датасеты по крипте чаще всего большие и чаще встречаются в каталогах данных для машинного обучения. Их будет сильно больше после индексирования Kaggle, Hugging Face и др.
2. Многие крипто данные доступны только как открытые и коммерческие API, надо индексировать их описание.
3. Криптодатасеты есть в маркетплейсах данных Amazon, Google BigQuery, Azure и тд. Там не так много датасетов всего, но объёмы датасетов и востребованность велики.
Собирать данные по криптодатасетам не похоже на многие другие, но мы вскоре начнём их загружать в Dateno.
#opendata #crypto #cryptodata
ИИ помощники выдают неплохие результаты, но очень ограниченные основными первоисточниками. Google Dataset Search выдаёт разное, делая акцент на Kaggle и свои продукты, но сразу после первой страницы идут разного рода коммерческие и недоступные источники.
В Dateno сейчас всего 34 результата по слову "Ethereum" и часть ссылок уже не работает, удалены в первоисточнике.
Это один из примеров запросов и тем где требуется больше усилий чем просто собрать метаданные откуда попало.
Я на днях анализировал почему датасетов по крипте в Dateno мало и следующие выводы:
1. Открытые датасеты по крипте чаще всего большие и чаще встречаются в каталогах данных для машинного обучения. Их будет сильно больше после индексирования Kaggle, Hugging Face и др.
2. Многие крипто данные доступны только как открытые и коммерческие API, надо индексировать их описание.
3. Криптодатасеты есть в маркетплейсах данных Amazon, Google BigQuery, Azure и тд. Там не так много датасетов всего, но объёмы датасетов и востребованность велики.
Собирать данные по криптодатасетам не похоже на многие другие, но мы вскоре начнём их загружать в Dateno.
#opendata #crypto #cryptodata
В рубрике закрытых и открытых данных в России
❌ Росстат перестал публиковать ежемесячную статистику по миграции и по общей численности населения России.[1] - об этом пишет демограф Алексей Ракша со ссылками на последние публикации на сайте ведомства. Эти данные никогда не были открытыми в смысле машиночитаемости, но были открыты в форме текста/картинок/таблиц в докладе.
❌ Роскосмосу разрешили продавать снимки ДЗЗ [2] хотя он и раньше их продавал, но теперь может продавать их и госорганам. Это очень противоположная тенденция тому что происходит в мире, там наоборот, в геопространственных проектах ЕС и США всё больше общедоступных спутниковых снимков охватывающих весь мир.
❌ В России приготовились засекретить работу правительства в случае военного положения [3] Минюст РФ предложил закрывать часть общедоступных сведений об органах власти в случае военного положения. Ну, хотя бы не предложили интернет отключать, но в остальном без комментариев.
✅ ФНС России опубликовали новый набор открытых данных, сведения о специальных налоговых режимах [4]. На сегодняшний день это чуть ли не единственный российский ФОИВ публикующий регулярно и обновляющий осмысленные наборы данных.
Ссылки:
[1] https://t.iss.one/RakshaDemography/3911
[2] https://www.pnp.ru/social/a-iz-nashego-okna-zemlya-v-illyuminatore-vidna.html
[3] https://www.moscowtimes.ru/2024/10/22/yuzhnaya-koreya-zadumalas-opostavkah-letalnogo-vooruzheniya-ukraine-iz-za-privlecheniya-rossiei-soldat-kndr-a145553
[4] https://t.iss.one/nalog_gov_ru/1529
#opendata #closeddata #russia
Ссылки:
[1] https://t.iss.one/RakshaDemography/3911
[2] https://www.pnp.ru/social/a-iz-nashego-okna-zemlya-v-illyuminatore-vidna.html
[3] https://www.moscowtimes.ru/2024/10/22/yuzhnaya-koreya-zadumalas-opostavkah-letalnogo-vooruzheniya-ukraine-iz-za-privlecheniya-rossiei-soldat-kndr-a145553
[4] https://t.iss.one/nalog_gov_ru/1529
#opendata #closeddata #russia
Please open Telegram to view this post
VIEW IN TELEGRAM
Написал краткий обзор новых возможностей [1] в Dateno, включая открытую статистику, расширенный поисковый индексы, фасеты и API.
Лонгриды буду и далее разворачивать на Substack на русском языке, а на английском языке на Medium [2]
Ссылки:
[1] https://open.substack.com/pub/begtin/p/dateno?r=7f8e7&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
[2] https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829
#opendata #datasearch #dateno #datadiscovery
Лонгриды буду и далее разворачивать на Substack на русском языке, а на английском языке на Medium [2]
Ссылки:
[1] https://open.substack.com/pub/begtin/p/dateno?r=7f8e7&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
[2] https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829
#opendata #datasearch #dateno #datadiscovery
Ivan’s Begtin Newsletter on digital, open and preserved government
Обновления в Dateno
Статистика, API, новые фасеты и ещё больше данных.
В рубрике как это устроено у них один из крупнейших научных репозиториев данных в мире ScienceBase.gov [1] поддерживается Геологической службой США (USGS) и содержит более чем 18.7 миллионов записей включающих наборы данных, точки подключения к API, файлы данных тайлов и многие другие относящиеся к геологии, геодезии, географии и другим гео наукам в США.
Большая часть записей там это разрезанные по регионам очень крупные базы данных такие как: National Elevation Dataset (NED) - 7.4 миллиона записей и
3D Elevation Program (3DEP) - 6.1 миллион записей и так далее.
Многие датасеты в этом репозитории - это описания физических объектов и содержан они, как машиночитаемое представление, так и многочисленные фотографии. Почти у всех датасетов есть геопривязка в форме точки на карте или полигон где находится множество точек/объектов.
Этот каталог по масштабам можно сравнить с Data.one и Pangaea, но по объёму и числу датасетов он гораздо больше.
При этом у него, как и у многих предметно тематических научных репозиториев, собственные API для доступа и форматы публикации метаданных. Это и собственная схема описания данных, и стандарт FGDC используемый в США, и стандарт ISO TC 211.
Важно и то что USGS требует от исследователей публиковать данные в этом репозитории и он непрерывно наполняется результатами профинансированных ими проектами, данных геофондов на уровне штатов и результатами работ научных институтов.
А с точки зрения поиска, это довольно хорошо структурированный репозиторий, с возможностью фасетного поиска. Из видимых недостатков у него нет bulk выгрузки метаданных, так чтобы была возможность выгрузить все записи целиком, да и некоторые датасеты тоже. Это кажется очень логичным, изучая практики публикации геномных данных, с одной стороны, с другой стороны в геологии нет такой всеобъемлющей широты использования онтологий и бесконечного числа идентификаторов. Датасеты менее гомогенны, но и в этом направлении явно идёт постепенная работа.
Ссылки:
[1] https://www.sciencebase.gov
#opendata #datasets #datacatalogs #geology #geography #geodata
Большая часть записей там это разрезанные по регионам очень крупные базы данных такие как: National Elevation Dataset (NED) - 7.4 миллиона записей и
3D Elevation Program (3DEP) - 6.1 миллион записей и так далее.
Многие датасеты в этом репозитории - это описания физических объектов и содержан они, как машиночитаемое представление, так и многочисленные фотографии. Почти у всех датасетов есть геопривязка в форме точки на карте или полигон где находится множество точек/объектов.
Этот каталог по масштабам можно сравнить с Data.one и Pangaea, но по объёму и числу датасетов он гораздо больше.
При этом у него, как и у многих предметно тематических научных репозиториев, собственные API для доступа и форматы публикации метаданных. Это и собственная схема описания данных, и стандарт FGDC используемый в США, и стандарт ISO TC 211.
Важно и то что USGS требует от исследователей публиковать данные в этом репозитории и он непрерывно наполняется результатами профинансированных ими проектами, данных геофондов на уровне штатов и результатами работ научных институтов.
А с точки зрения поиска, это довольно хорошо структурированный репозиторий, с возможностью фасетного поиска. Из видимых недостатков у него нет bulk выгрузки метаданных, так чтобы была возможность выгрузить все записи целиком, да и некоторые датасеты тоже. Это кажется очень логичным, изучая практики публикации геномных данных, с одной стороны, с другой стороны в геологии нет такой всеобъемлющей широты использования онтологий и бесконечного числа идентификаторов. Датасеты менее гомогенны, но и в этом направлении явно идёт постепенная работа.
Ссылки:
[1] https://www.sciencebase.gov
#opendata #datasets #datacatalogs #geology #geography #geodata
Кстати, в качестве регулярного напоминания, кроме всего прочего какое-то время назад я занимался разработкой утилиты metacrafter, она довольно умело умеет идентифицировать семантические типы данных. При этом в ней нет нейросетей, ИИ, а лишь очень много правил в виде регулярных выражений и их аналога в синтаксисе pyparsing с помощью которых можно быстро сканировать базы данных и файлы для выявления смысловых полей данных.
Чтобы собрать те правила я тогда перелопатил около 10 порталов открытых данных и кучу других собранных датасетов для выявления повторяющихся типов данных. И то типов данных собрал больше чем потом сделал правил, реестр типов, при этом вполне живой.
Так вот одна из интересных особенностей Dateno - это бесконечный источник данных для обучения чего-либо. Например, у меня сейчас для экспериментальных целей уже собрано около 5TB CSV файлов из ресурсов Dateno, а также несколько миллионов мелких CSV файлов из потенциальных каталогов данных, ещё в Dateno не подключённых. А это гигантская база для обучения алгоритмов на выявление типовых паттернов и атрибутов.
Вообще в планах было подключить к Dateno возможность фильтрации по распознанным семантическим типам данных, правда уже сейчас понятно что самым распространённым атрибутом из CSV файлов будет геометрия объекта, атрибут the_geom который есть в каждом экспорте слоя карт из Geoserver.
В любом случае Dateno оказывается совершенно уникальным ресурсом для тех кто хочет поделать себе обучающих подборок данных на разных языках, в разных форматах, из разных стран и заранее обладающим множеством метаданных позволяющих упростить задачи классификации распознавания содержимого.
Я уже общался недавно с группой исследователей которые так вот запрашивали подборки CSV файлов именно на разных языках: английском, испанском, арабском и тд. и желательно из разных источников, чтобы были и примеры с ошибками, с разными разделителями и тд.
Впрочем в Dateno проиндексированы не только CSV файлы, но и многие JSON, NetCDF, Excel, XML, KML, GeoTIFF, GML, DBF и других. Можно собирать уникальные коллекции именно для обучения.
А какие файлы для каких задач для обучения нужны вам?
#opendata #thougths #dateno #algorithms
Чтобы собрать те правила я тогда перелопатил около 10 порталов открытых данных и кучу других собранных датасетов для выявления повторяющихся типов данных. И то типов данных собрал больше чем потом сделал правил, реестр типов, при этом вполне живой.
Так вот одна из интересных особенностей Dateno - это бесконечный источник данных для обучения чего-либо. Например, у меня сейчас для экспериментальных целей уже собрано около 5TB CSV файлов из ресурсов Dateno, а также несколько миллионов мелких CSV файлов из потенциальных каталогов данных, ещё в Dateno не подключённых. А это гигантская база для обучения алгоритмов на выявление типовых паттернов и атрибутов.
Вообще в планах было подключить к Dateno возможность фильтрации по распознанным семантическим типам данных, правда уже сейчас понятно что самым распространённым атрибутом из CSV файлов будет геометрия объекта, атрибут the_geom который есть в каждом экспорте слоя карт из Geoserver.
В любом случае Dateno оказывается совершенно уникальным ресурсом для тех кто хочет поделать себе обучающих подборок данных на разных языках, в разных форматах, из разных стран и заранее обладающим множеством метаданных позволяющих упростить задачи классификации распознавания содержимого.
Я уже общался недавно с группой исследователей которые так вот запрашивали подборки CSV файлов именно на разных языках: английском, испанском, арабском и тд. и желательно из разных источников, чтобы были и примеры с ошибками, с разными разделителями и тд.
Впрочем в Dateno проиндексированы не только CSV файлы, но и многие JSON, NetCDF, Excel, XML, KML, GeoTIFF, GML, DBF и других. Можно собирать уникальные коллекции именно для обучения.
А какие файлы для каких задач для обучения нужны вам?
#opendata #thougths #dateno #algorithms
GitHub
GitHub - apicrafter/metacrafter: Metadata and data identification tool and Python library. Identifies PII, common identifiers,…
Metadata and data identification tool and Python library. Identifies PII, common identifiers, language specific identifiers. Fully customizable and flexible rules - apicrafter/metacrafter
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в 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
Лично я постоянно ищу какие есть поисковики по данным, глобальные и национальные, а недавно обнаружил что оказывается такой поисковик есть у правительства Шотландии find.data.gov.scot и по многим параметрам он напоминает Dateno, что хорошо😜, но тысячу раз меньше поэтому не конкурент😂.
Итак, в Шотландии пр-во достаточно давно планирует осуществить открытие портала открытых данных data.gov.scot, но пока они этого не сделали они пошли по австралийскому пути создания национального поисковика по данным.
Всего на портале на главной странице декларируется что присутствует 17 тысяч датасетов, а на странице поиска только 11 тысяч. Метаданные о них собираются из примерно 60 источников данных (data hosts) через парсеры нескольких видов API.
Что мне нравится, ребята явно идут нашим путём и проанализировали не меньше пары сотен источников данных, систематизировали их API, идентифицировали ПО некоторых каталогов данных о которых я не знал (MetadataWorks, USmart и др.), но при этом про наш каталог Dateno registry явно не знали. Плюс у них в источниках данных многое что каталогами данных назвать нельзя, публикации файлов отдельными ведомствами, но для сбора датасетов на региональном уровне явно полезно..
В итоге поисковик у них получается, на самом деле, не совсем поисковик, поскольку у каждого датасета есть веб страница с метаданными.
Из всего что я видел - это, пока, наибольшее приближение к подходу в Dateno, за исключением, масштаба, конечно.
Если делать внутристрановой поисковик по данным то на их проект стоит обратить внимание. Они явно писали HTML парсеры под разделы статистики на многих сайтах и значительная часть датасетов там - это PDF файлы статистики нескольких инспекций.
В любом случае любопытно, в том числе как референсные оценки числа датасетов в Шотландии. В Dateno их сейчас около 8 тысяч, в этом местном поисковике их около 11 тысяч. Есть куда стремиться 🛠
#opendata #scotland #datasets #data #datasearch #dateno
Итак, в Шотландии пр-во достаточно давно планирует осуществить открытие портала открытых данных data.gov.scot, но пока они этого не сделали они пошли по австралийскому пути создания национального поисковика по данным.
Всего на портале на главной странице декларируется что присутствует 17 тысяч датасетов, а на странице поиска только 11 тысяч. Метаданные о них собираются из примерно 60 источников данных (data hosts) через парсеры нескольких видов API.
Что мне нравится, ребята явно идут нашим путём и проанализировали не меньше пары сотен источников данных, систематизировали их API, идентифицировали ПО некоторых каталогов данных о которых я не знал (MetadataWorks, USmart и др.), но при этом про наш каталог Dateno registry явно не знали. Плюс у них в источниках данных многое что каталогами данных назвать нельзя, публикации файлов отдельными ведомствами, но для сбора датасетов на региональном уровне явно полезно..
В итоге поисковик у них получается, на самом деле, не совсем поисковик, поскольку у каждого датасета есть веб страница с метаданными.
Из всего что я видел - это, пока, наибольшее приближение к подходу в Dateno, за исключением, масштаба, конечно.
Если делать внутристрановой поисковик по данным то на их проект стоит обратить внимание. Они явно писали HTML парсеры под разделы статистики на многих сайтах и значительная часть датасетов там - это PDF файлы статистики нескольких инспекций.
В любом случае любопытно, в том числе как референсные оценки числа датасетов в Шотландии. В Dateno их сейчас около 8 тысяч, в этом местном поисковике их около 11 тысяч. Есть куда стремиться 🛠
#opendata #scotland #datasets #data #datasearch #dateno
Документы бюджета Великобритании Autumn Budget 2024 [1] интересно смотреть сразу с нескольких точек зрения. Во первых они публикуют документ бюджета в виде книги [2], с графиками и очень понятными таблицами и сразу с присвоением ISBN и хорошо отформатированной веб версией [3].
А во вторых, и это интереснее, отдельным приложением идёт документ с упоминанием всех источников данных [4]. Буквально в стиле "в таком то разделе, таком то параграфе приведены данные ссылка на которых вот тут".
А также множество сопровождающих документов.
После чтения бюджетов многих стран, в разных форматах, читать этот значительно легче и понятнее. Хотя лично я жду когда же когда-нибудь появится моделирование бюджетов и госполитики интерактивными и машинными инструментами.
Ссылки:
[1] https://www.gov.uk/government/publications/autumn-budget-2024
[2] https://assets.publishing.service.gov.uk/media/672232d010b0d582ee8c4905/Autumn_Budget_2024__web_accessible_.pdf
[3] https://www.gov.uk/government/publications/autumn-budget-2024/autumn-budget-2024-html
[4] https://assets.publishing.service.gov.uk/media/6722236e4da1c0d41942a986/Autumn_Budget_2024_-_Data_Sources__1_.pdf
#openbudgets #data #opendata #uk #readings
А во вторых, и это интереснее, отдельным приложением идёт документ с упоминанием всех источников данных [4]. Буквально в стиле "в таком то разделе, таком то параграфе приведены данные ссылка на которых вот тут".
А также множество сопровождающих документов.
После чтения бюджетов многих стран, в разных форматах, читать этот значительно легче и понятнее. Хотя лично я жду когда же когда-нибудь появится моделирование бюджетов и госполитики интерактивными и машинными инструментами.
Ссылки:
[1] https://www.gov.uk/government/publications/autumn-budget-2024
[2] https://assets.publishing.service.gov.uk/media/672232d010b0d582ee8c4905/Autumn_Budget_2024__web_accessible_.pdf
[3] https://www.gov.uk/government/publications/autumn-budget-2024/autumn-budget-2024-html
[4] https://assets.publishing.service.gov.uk/media/6722236e4da1c0d41942a986/Autumn_Budget_2024_-_Data_Sources__1_.pdf
#openbudgets #data #opendata #uk #readings
Я довольно давно думаю о разных возможностях и подходах в удешевлении создания машиночитаемых/структурированных данных из неструктурированных потому что задача создания качественных датасетов из всякого мусора неструктурированных присутствует давно и до конца никем не решена, но есть некоторые приближения.
И здесь можно вспомнить как создавались первые порталы открытых данных в мире. В основном путём закачки на них большого объёма статистики и табличных файлов из банков документов госорганов.
Почему так? Потому что переводя смысл существования государственных порталов данных на современный язык - он заключается в том чтобы обеспечивать доступ к дата продуктам госорганов для профессионалов и общественности. Дата продукты бывают проработанные, изначально с машиночитаемыми данными или API, а бывают, скажем так не осознаваемые как дата продукты. И вот последние являются, чаще всего, частью публикационной активности, они выкладываются как документы, в лучшей форме как Excel, в худшей как сканы.
Между этими крайностями есть много промежуточных вариантов: в виде файлов MS Word, в PDF документах и так далее.
При этом из Excel файлов таблицы выделяются естественным образом, из MS Word с небольшими усилиями, из PDF уже сложнее, нужна человеческая валидация, но всё это возможно и всё это автоматизируемо.
Так вот, как можно было бы создать быстро портал открытых данных из таких продуктов? Давайте я приведу в пример Минфин России. На его сайте в разделе Документы размещено 29 594 документов. Из которых только 45% 12 349 - это PDF файлы,а всё остальное - это XLS, XLSX, DOC, DOCX и ZIP файлы. При этом в ZIP файлах, как правило, десятки DOC/DOCX/XLSX файлов (не PDF).
Весь этот банк документов буквально за короткий срок превращается в банк открытых данных. Не идеальных, не самых востребованных, но куда более полезных чем даже публиковалось на портале data.gov.ru до его исчезновения.
Разумеется это только один из примеров. Точно также можно превратить в банк данных документы Минфина Казахстана или Минфина Армении.
И так справедливо в отношении большей части госорганов. Особенно в отношении статистических служб, министерств финансов и налоговых служб. Для таких задач я когда-то делал простую утилитку по извлечению таблиц из .docx файлов - docx2csv.
Можно ли сейчас создать таким образом десятки и сотни тысяч датасетов? Конечно же можно
#opendata #opengov #datasets #data
И здесь можно вспомнить как создавались первые порталы открытых данных в мире. В основном путём закачки на них большого объёма статистики и табличных файлов из банков документов госорганов.
Почему так? Потому что переводя смысл существования государственных порталов данных на современный язык - он заключается в том чтобы обеспечивать доступ к дата продуктам госорганов для профессионалов и общественности. Дата продукты бывают проработанные, изначально с машиночитаемыми данными или API, а бывают, скажем так не осознаваемые как дата продукты. И вот последние являются, чаще всего, частью публикационной активности, они выкладываются как документы, в лучшей форме как Excel, в худшей как сканы.
Между этими крайностями есть много промежуточных вариантов: в виде файлов MS Word, в PDF документах и так далее.
При этом из Excel файлов таблицы выделяются естественным образом, из MS Word с небольшими усилиями, из PDF уже сложнее, нужна человеческая валидация, но всё это возможно и всё это автоматизируемо.
Так вот, как можно было бы создать быстро портал открытых данных из таких продуктов? Давайте я приведу в пример Минфин России. На его сайте в разделе Документы размещено 29 594 документов. Из которых только 45% 12 349 - это PDF файлы,а всё остальное - это XLS, XLSX, DOC, DOCX и ZIP файлы. При этом в ZIP файлах, как правило, десятки DOC/DOCX/XLSX файлов (не PDF).
Весь этот банк документов буквально за короткий срок превращается в банк открытых данных. Не идеальных, не самых востребованных, но куда более полезных чем даже публиковалось на портале data.gov.ru до его исчезновения.
Разумеется это только один из примеров. Точно также можно превратить в банк данных документы Минфина Казахстана или Минфина Армении.
И так справедливо в отношении большей части госорганов. Особенно в отношении статистических служб, министерств финансов и налоговых служб. Для таких задач я когда-то делал простую утилитку по извлечению таблиц из .docx файлов - docx2csv.
Можно ли сейчас создать таким образом десятки и сотни тысяч датасетов? Конечно же можно
#opendata #opengov #datasets #data
К вопросу о дата-инженерии и 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
Какие дата профессии наиболее уязвимы к ИИ? (можно несколько ответов
Anonymous Poll
26%
Дата аналитики
8%
Дата инженеры
5%
ML инженеры
11%
Дата сайентисты
19%
BI инженеры
59%
Просто хочу ответы посмотреть
Пока я рассуждал о том что новые инструменты data wrangling'а (манипуляция и трансформация данных) появятся уже на базе движков вроде DuckDB или Clickhouse, они начали появляться. Свежее видео выступления Hannes Mühleisen - Data Wrangling [for Python or R] Like a Boss With DuckDB [1] ровно про это и слайды к нему же [2].
Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.
Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.
Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.
Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.
Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.
P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.
Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython
#opensource #data #datatools #rdbms #duckdb #dataengineering
Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.
Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.
Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.
Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.
Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.
P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.
Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython
#opensource #data #datatools #rdbms #duckdb #dataengineering
В виде одного очень редкого исключения оффтопика от основных тем моего канала. Я тут думал на что повлияет избрание Трампа в Президенты США. С довольно специфического угла зрения.
1. Могут исчезнуть некоторые сайты/цифровые ресурсы и данные. Если Илон Маск реально войдет в его кабинет, то неизбежна реформа и ликвидация ряда федеральных агентств в США. Не так рисковано как в других странах, но не безболезнено. Надо ли нам их архивировать? Почти наверняка местные группы/команды активистов всё сохранят.
2. Крипто рынок получит легализацию в США и, с какой-то вероятностью, большую легализацию в мире. Что для всех легальных пользователей крипты хорошая новость.
3. Военные конфликты прекратятся? Вот в это я не особо верю, во всяком случае прекращение боевых действий никак не отменит ни санкции, ни снизит военные расходы, ни многое другое. Впрочем гадать об этом - это уже уходить в сторону политических прогнозов, а у меня их нет. По прежнему нанимать россиян в международные проекты, а иностранцев в российские будет сложно.
Лично я пока не понимаю отразится ли происходящее на ИТ рынок и рынок стартапов/данных и тд. Похоже что не отразится, по крайней мере в части того что я вижу.
#offtopic #trump
1. Могут исчезнуть некоторые сайты/цифровые ресурсы и данные. Если Илон Маск реально войдет в его кабинет, то неизбежна реформа и ликвидация ряда федеральных агентств в США. Не так рисковано как в других странах, но не безболезнено. Надо ли нам их архивировать? Почти наверняка местные группы/команды активистов всё сохранят.
2. Крипто рынок получит легализацию в США и, с какой-то вероятностью, большую легализацию в мире. Что для всех легальных пользователей крипты хорошая новость.
3. Военные конфликты прекратятся? Вот в это я не особо верю, во всяком случае прекращение боевых действий никак не отменит ни санкции, ни снизит военные расходы, ни многое другое. Впрочем гадать об этом - это уже уходить в сторону политических прогнозов, а у меня их нет. По прежнему нанимать россиян в международные проекты, а иностранцев в российские будет сложно.
Лично я пока не понимаю отразится ли происходящее на ИТ рынок и рынок стартапов/данных и тд. Похоже что не отразится, по крайней мере в части того что я вижу.
#offtopic #trump
Я тут наблюдаю время от времени как публикуют открытые данные некоторые команды, в том числе с хорошей мировой репутацией, но с небольшими знаниями по современной дата инженерии и уже какое-то бесконечное время смотрю как многие открытые и не только открытые данные опубликованы. И прихожу к мысли о том что уже классическое определение открытых данных с точки зрения 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
В рубрике полезных инструментов с открытым кодом docling [1] от IBM Open Source и конкретнее их команды Deep Search. Утилита и библиотека для Python по преобразованию условно любых документов в Markdown. Умеет работать с (PDF, DOCX, PPTX, Images, HTML, AsciiDoc, Markdown и преобразует их в Markdown или JSON.
При этом распознает сканированные документы, извлекает таблицы и поддерживает множество движков распознавания. Интегрируется с LangChain и LllamaIndex, значительно быстрее работает при наличии CUDA.
Я проверял без графического процессора, поэтому было небыстро, но результирующий Markdown текст вполне приличный.
Можно за короткий срок извлечь таблицы из огромного числа документов, при наличии вычислительных ресурсов, конечно.
Ссылки:
[1] https://ds4sd.github.io/docling/
#opensource #pdf #dataengineering
При этом распознает сканированные документы, извлекает таблицы и поддерживает множество движков распознавания. Интегрируется с LangChain и LllamaIndex, значительно быстрее работает при наличии CUDA.
Я проверял без графического процессора, поэтому было небыстро, но результирующий Markdown текст вполне приличный.
Можно за короткий срок извлечь таблицы из огромного числа документов, при наличии вычислительных ресурсов, конечно.
Ссылки:
[1] https://ds4sd.github.io/docling/
#opensource #pdf #dataengineering
Написал короткий лонгрид в продолжение размышлений о качестве открытых данных и дата продуктах
#opendata #thoughts #datasets
#opendata #thoughts #datasets
Ivan’s Begtin Newsletter on digital, open and preserved government
Открытые данные как дата продукт
Почему продвижение открытых данных не означает понимания их аудитории