7029
I write about Open Data, Procurement, e-Government, Open Government, Budgets, Privacy and other govtech stuff Chat https://telegram.me/begtinchat Facebook - https://facebook.com/ibegtin Secure contacts ivan@begtin.tech
Dateno: первые опыты
Современная наука во многом построена на больших массивах данных, доступ к которым можно получить через репозитории, однако инструментов, позволяющих осуществлять поиск сразу по нескольким из них не так много. Так, Google Dataset Search выглядит подходящим инструментом, но исследователи, для которых предметом изучения являются сами данные, сталкиваются с ограничениями по автоматизации их получения.
Мы давно обратили внимание на проект Dateno (команда под руководством Ивана Бегтина), о котором упоминали в мартовском дайджесте. На сегодняшний день Dateno содержит информацию о 19 миллионах датасетов, но самое главное - имеет достаточно понятный и удобный API-интерфейс, с которым мы и решили, наконец, попробовать поработать.
Простая инструкция с примером очень хорошо описана в телеграм-канале И. Бегтина: пользователь регистрируется, получает токен, а дальше применение API возможно как напрямую из браузерной строки, так и через консольный инструмент, скрипт Python/R и т.д.
Зарегистрировавшись, мы сразу запросили данные о датасетах, в заголовке которых есть слово "scientometric*". Таких нашлось 92. Всего включено 35 параметров, в том числе данные о самих датасетах (название, ссылка, тематика, описание, формат и др.) и об источниках этих датасетов (название и тип каталога, название и тип его владельца, страна, язык и прочее).
Конкретно по нашей тематике данные размечены не полностью — например, лицензия указана всего для 10 датасетов из 92, тематика — для 16, а макрорегион — для 33. Подавляющее большинство наборов данных (56) принадлежит Европейскому Союзу, а вот в США их всего 17. Самые распространенные форматы .tsv и .txt (по 13). Датасетов в формате .json, к нашему удивлению, всего 2.
В целом, Dateno оказался действительно удобным инструментом, как с точки зрения технической доступности (открытый API есть у немногих репозиториев), так и с точки зрения покрытия данных. Предлагаем поделиться своим опытом использования Dateno в комментариях.
#dateno #датасеты #открытыеданные
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
Примерно с апреля 2024 года Минздрав РФ более не публикует открытые данные на своём официальном сайте [1] и сейчас данные также недоступны.
При этом ещё в марте этот раздел был открыт [2] хотя данные и не обновлялись. Например, данные реестра
лекарственных средств не обновлялись с марта 2017 года [3], как и оставшиеся датасеты, их также прекратили обновлять в 2017 году.
Ссылки:
[1] https://minzdrav.gov.ru/opendata
[2] https://web.archive.org/web/20240328094829/https://minzdrav.gov.ru/opendata
[3] https://web.archive.org/web/20240520083814/https://minzdrav.gov.ru/opendata
#opendata #datasets #data #russia #closeddata
Как интересно, а поиск по датасетам и другим цифровым объектам микроразметки они там предусмотрят или это будет чистый веб индекс?
Читать полностью…
К вопросу о том как развивается открытый код и открытые данные в мире, я как-то уже упоминал про Registry of Digital Public Goods [1], это по сути, пример систематизации открытого кода донорами которые дают финансирование на открытый код, чаще всего, или, социально ориентированным коммерческим компаниям или технологическим НКО. И тех и тех в мире много, открытого кода тоже много вот собственно в этом реестре их начали вносить в привязке к целям устойчивого развития.
Из всех технологических инициатив связанных с ООН эта наиболее понятная, собственно она сама является открытым стандартом описания проектов [2].
А заодно позволяет оценить насколько эффективно создание ПО на грантовые средства и насколько устойчивы создаваемые проекты. Если присмотреться к тому что там опубликовано, то есть немало проектов созданных по принципу "отчитались и ну его". Иначе говоря код выложен однократно, чтобы соответствовать требованиям гранта.
Но есть и серьёзные проекты. В реестре есть FormSG [3] открытый код по генерации форм, созданный Правительством Сингапура. Там есть CKAN [4] наиболее популярный код для создания порталов открытых данных и ещё много всего.
Что характерно там сейчас 176 проектов, но в реальности их гораздо больше. тут лишь те авторы которых явным образом о себе заявили и прошли верификацию. Причём проекты как от НКО, так и от госорганов. Главное что открытый код и соответствие целям развития.
Можно обратить внимание что из РФ, ожидаемо, ни одного проекта нет. Из Армении есть один, созданный явно на грантовые деньги. Пара проектов из Казахстана, тоже, похоже, грантового происхождения. Из Эстонии там есть X-Road, госпроект ПО по обмену данными, в открытом коде.
В целом это всё очень похоже на модели кооперации НКО и гос-ва в западной модели их поддержки. Гранты раздаются многим, лишь некоторые проекты обретают долгую жизнь и те что обретают переводят в режим кооперации.
Ссылки:
[1] https://www.digitalpublicgoods.net/registry
[2] https://www.digitalpublicgoods.net/standard
[3] https://www.digitalpublicgoods.net/r/formsg
[4] https://www.digitalpublicgoods.net/r/ckan
#opensource #opendata #un
Кстати, не могу не поделиться мыслью что в мире сейчас большой явный кризис в сообществе открытости данных и вызван он развитием ИИ. Я уже не в первый раз слышу разговоры в стиле зачем нам публиковать хорошие открытые данные и работать над их качеством если ИИ всё сожрёт. Это прям большое ментальное давление на очень многие проекты Wikipedia, OpenStreetMap, сообщество OKF и десятки других.
Если это не отменяет повестку открытости для гос-ва, то ограничивает и сильно повестку сообщества. Для многих это большое ограничение в том как готовить хорошие открытые данные и про усиление неравенства в мире.
Все кто создают что-либо общедоступное сталкиваются с тем что они создают лишь топливо для ИИ и что они работают не на преумножение знаний и блага людям, а на обогащение OpenAI.
#opendata #thoughts #community
⚡ Creative Commons запускает коалицию TAROCH за открытый доступ к культурному наследию
Creative Commons (CC) с гордостью объявляет о начале работы коалиции TAROCH (Towards a Recommendation on Open Cultural Heritage — пер. «На пути к рекомендации по открытому культурному наследию»). Миссия инициативы заключается в том, чтобы побудить государства-члены ЮНЕСКО разработать и принять Рекомендацию (или другой нормативный документ), поощряющую решения для расширения открытого доступа к культурному наследию.
Конечная цель коалиции TAROCH заключается в том, чтобы культурное наследие было доступно для всех на справедливой основе в соответствии с миссией ЮНЕСКО и ее культурной, информационной политикой, в частности межкультурным диалогом и культурными обменами.
В рубрике полезных инструментов с открытым кодом 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
В виде одного очень редкого исключения оффтопика от основных тем моего канала. Я тут думал на что повлияет избрание Трампа в Президенты США. С довольно специфического угла зрения.
1. Могут исчезнуть некоторые сайты/цифровые ресурсы и данные. Если Илон Маск реально войдет в его кабинет, то неизбежна реформа и ликвидация ряда федеральных агентств в США. Не так рисковано как в других странах, но не безболезнено. Надо ли нам их архивировать? Почти наверняка местные группы/команды активистов всё сохранят.
2. Крипто рынок получит легализацию в США и, с какой-то вероятностью, большую легализацию в мире. Что для всех легальных пользователей крипты хорошая новость.
3. Военные конфликты прекратятся? Вот в это я не особо верю, во всяком случае прекращение боевых действий никак не отменит ни санкции, ни снизит военные расходы, ни многое другое. Впрочем гадать об этом - это уже уходить в сторону политических прогнозов, а у меня их нет. По прежнему нанимать россиян в международные проекты, а иностранцев в российские будет сложно.
Лично я пока не понимаю отразится ли происходящее на ИТ рынок и рынок стартапов/данных и тд. Похоже что не отразится, по крайней мере в части того что я вижу.
#offtopic #trump
Не успела появится профессия 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
Я довольно давно думаю о разных возможностях и подходах в удешевлении создания машиночитаемых/структурированных данных из неструктурированных потому что задача создания качественных датасетов из всякого мусора неструктурированных присутствует давно и до конца никем не решена, но есть некоторые приближения.
И здесь можно вспомнить как создавались первые порталы открытых данных в мире. В основном путём закачки на них большого объёма статистики и табличных файлов из банков документов госорганов.
Почему так? Потому что переводя смысл существования государственных порталов данных на современный язык - он заключается в том чтобы обеспечивать доступ к дата продуктам госорганов для профессионалов и общественности. Дата продукты бывают проработанные, изначально с машиночитаемыми данными или 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
Лично я постоянно ищу какие есть поисковики по данным, глобальные и национальные, а недавно обнаружил что оказывается такой поисковик есть у правительства Шотландии 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
Кстати, в качестве регулярного напоминания, кроме всего прочего какое-то время назад я занимался разработкой утилиты 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
Написал краткий обзор новых возможностей [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] ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829" rel="nofollow">https://medium.com/@ibegtin/just-recently-we-updated-our-dateno-dataset-search-dateno-io-065276450829
#opendata #datasearch #dateno #datadiscovery
В поиска крипто-датасетов по блокчейну, биткоину, 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
Common Corpus [1] свежий дата продукт от Hugging Face с данными для обучения.
Внутри 2 триллиона токенов, а сам он построен на:
📦 OpenCulture: 926 миллиардов токенов из книг в открытом доступе
📦 OpenGovernment: 388 миллиардов токенов из финансовых и юридических документов
📦 OpenSource: 334 миллиарда токенов открытого кода, отфильтрованного по критериям качества
📦 OpenScience: 221 миллиард токенов из репозиториев открытой науки
📦 OpenWeb: 132 миллиарда токенов на контенте из сайтов с пермиссивной лицензией (Википедия и др.)
Можно обратить внимание что открытых данных нет в списке, но там был бы обучающий набор поменьше.
Корпус это огромен, в нём около 40% английского языка и много других язык.
Внутри всё состоит из бесконечно числа parquet файлов.
Ссылки:
[1] https://huggingface.co/blog/Pclanglais/two-trillion-tokens-open
#opendata #ai #datasets
В рубрике полезных инструментов по автоматизации визуализации данных Visprex [1] визуализация CSV файлов сразу в браузере, без передачи куда либо.
Умеет сразу несколько базовых визуализаций что полезно для небольших дата файлов.
Из минусов - это типы данных они угадывают по полям в CSV, а если бы точно также визуализировали Parquet файлы то типы там были бы уже сразу.
Вообще скажу я в вам автоматизация визуализации данных - это та ещё наука. Её активно решают с помощью LLM в последние годы и скорее всего неплохо получится решить.
Ссылки:
[1] https://github.com/visprex/visprex
#opensource #dataviz #autodataviz
CNBC: Европейские конкуренты Google объединятся для создания нового поискового индекса
– Ecosia и Qwant создадут европейский поисковой индекс
– Для проекта они создадут European Search Perspective
– Каждая компания будет владеть 50% этого предприятия
– В начале 2025 проект планируется запустить во Франции
– Поиск от Qwant ориентирован на конфиденциальность
– Поисковая система Ecosia уделяет внимание экологии
– Ecosia сажает по одному дереву за каждые 50 запросов
– Проект стал возможен благодаря новому закону DMA
– Google обязан делиться данными для обучения модели
– Пока альтернативные системы не создают свои индексы
– Например, Ecosia использует результаты Google и Bing
– На ее бизнес влияет повышение цен на Bing Search API
– Новый поисковой индекс ориентирован на безопасность
– Он будет доступен независимым поисковым системам
– Инфраструктура снизит зависимость ЕС от США и др.
– На Google приходится 90% мирового рынка поиска
@ftsec
Полезное чтение про данные, технологии и не только:
- All the data can be yours [1] автор пишет про реверс-инжиниринг API. Ха, подержи моё пиво! Я могу рассказать об этом куда больше, а было бы и время то и книжку написать. Но читать про опыт других всегда полезно, всегда есть что-то новое.
- AI protein-prediction tool AlphaFold3 is now open source [2] в Google заопенсорсили AlphaFold3, движок для предсказания структур протеинов с помощью ИИ. Для некоммерческого использования, конечно.
- The Death and Life of Prediction Markets at Google [3] неожиданное и любопытное, про внутренние инструменты предсказаний в Google и, заодно, немало про их внутреннюю культуру.
Ссылки:
[1] https://jero.zone/posts/reverse-engineering-apis
[2] https://www.nature.com/articles/d41586-024-03708-4
[3] https://asteriskmag.com/issues/08/the-death-and-life-of-prediction-markets-at-google
#readings #tech
В продолжение размышлений про то как публикуют открытые данные, я в какие-то из ближайших дней напишу про то как публикуют дата продукты и их качественные отличия от открытых данных (спойлер - большая часть дата продуктов коммерческие и в открытый доступ публикуют данные с ограничениями).
А пока в качестве одного из упоминаемых там материалов, проект OpenCellID [1]. База геолокаций сотовых вышек по всему миру, с возможностью выгрузки данных в по всему миру или отдельной стране.
В статистике упоминают более 30 миллионов вышек, а также можно загружать туда информацию с помощью их API [2]. За проектом стоит компания UnwiredLabs предоставляющая сервисы геолокации [3]
В чем особенность проекта так в том что он начинался как сообщество у которого появилось много контрибьюторов. Изначально данные в нём тоже были открыты и удобны для выгрузки, можно прочитать об этом в статье на Хабр в 2014 году [4], а сейчас данные не только не скачать без регистрации и API ключа, но и не более 2-х файлов в месяц.
Более того, у меня есть слепок данных из этого проекта за 2021 год и когда я сравниваю, например, данные по РФ, со статистикой по РФ на сайте и содержанием дампа на сегодня, то выглядят цифры вот так:
- 1.9 миллионов сотовых вышек РФ в выгрузке за 2021 г.
- 2.2. миллиона сотовых вышек по РФ упоминаются в статистике на 2024 г.
и только 146 тысяч сотовых вышек в выгрузке данных за 2024 г.
На форуме пользователи уже задаются вопросами почему так происходит, но безответно [5].
Ответ, почти наверняка, очевиден, владелец открытого сервиса "портит его" в пользу связанного коммерческого продукта. Так не редко случается в коммерческих дата продуктах изначально основанных на создание открытых данных.
Такое бывает и с опенсорс проектами переходящими в коммерциализацию.
Ссылки:
[1] https://opencellid.org
[2] https://wiki.opencellid.org/wiki/API
[3] https://unwiredlabs.com
[4] https://habr.com/ru/companies/promwad/articles/223635/
[5] https://opencellid.org/downloads.php
[6] https://community.opencellid.org/t/data-vs-statistics-differences/1327
#opendata #dataproducts #data
Написал большой лонгрид Хорошие и плохие практики публикации данных. Метаданные и форматы файлов про метаданные и то в каких форматах данных их публикуют.
#opendata #metadata #data #datacatalogs
Написал короткий лонгрид в продолжение размышлений о качестве открытых данных и дата продуктах
#opendata #thoughts #datasets
Я тут наблюдаю время от времени как публикуют открытые данные некоторые команды, в том числе с хорошей мировой репутацией, но с небольшими знаниями по современной дата инженерии и уже какое-то бесконечное время смотрю как многие открытые и не только открытые данные опубликованы. И прихожу к мысли о том что уже классическое определение открытых данных с точки зрения 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
Пока я рассуждал о том что новые инструменты 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
К вопросу о дата-инженерии и 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
Документы бюджета Великобритании 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
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в 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
В рубрике как это устроено у них один из крупнейших научных репозиториев данных в мире 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
В рубрике закрытых и открытых данных в России
❌ Росстат перестал публиковать ежемесячную статистику по миграции и по общей численности населения России.[1] - об этом пишет демограф Алексей Ракша со ссылками на последние публикации на сайте ведомства. Эти данные никогда не были открытыми в смысле машиночитаемости, но были открыты в форме текста/картинок/таблиц в докладе.
❌ Роскосмосу разрешили продавать снимки ДЗЗ [2] хотя он и раньше их продавал, но теперь может продавать их и госорганам. Это очень противоположная тенденция тому что происходит в мире, там наоборот, в геопространственных проектах ЕС и США всё больше общедоступных спутниковых снимков охватывающих весь мир.
❌ В России приготовились засекретить работу правительства в случае военного положения [3] Минюст РФ предложил закрывать часть общедоступных сведений об органах власти в случае военного положения. Ну, хотя бы не предложили интернет отключать, но в остальном без комментариев.
✅ ФНС России опубликовали новый набор открытых данных, сведения о специальных налоговых режимах [4]. На сегодняшний день это чуть ли не единственный российский ФОИВ публикующий регулярно и обновляющий осмысленные наборы данных.
Ссылки:
[1] /channel/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] /channel/nalog_gov_ru/1529
#opendata #closeddata #russia
В рубрике больших интересных наборов данных Annual National Land Cover Database (NLCD) [1] датасет с измерениями покрытия почвы в США с 1985 по 2023 годы, почти 40 лет.
Распространяется в виде GeoJSON, GeoTIF, SHP файлов и с помощью разных инструментов выгрузки и онлайн доступа.
В общей сложности это десятки гигабайт геоданных.
Ранее этот датасет охватывал только период 2001-2021 годов с шагом в 3 года, а теперь охватывает 38 лет с шагом в один год.
Для любых практических исследований в области сельского хозяйства и изменения климата - это бесценный датасет. Жаль лишь что он не охватывает весь мир, а только одну страну.
Ссылки:
[1] https://www.usgs.gov/news/national-news-release/usgs-releases-new-products-map-four-decades-land-cover-change
#opendata #datasets #geodata
