Я регулярно пишу про такое явление как датацентричное мышление "что угодно как таблица" и в более узком звучании "что-угодно как SQL". Причём последнее попадается всё чаще и всё чаще всё то ранее было доступно каким-то другим образом через API или в иной специфической форме доступно как таблицы.

Из последнего, sqlelf, это программная библиотека и утилита превращающая метаданные из исполняемых Linux файлов в базу Sqlite и позволяют проделывать все дальнейшие операции по чтению этих метаданных из SQL таблиц. Удобно для всех кто занимается форенсикой под Unix-like системы.

Из похожего, несколько лет назад я делал утилиту metawarc, индексирует содержание веб-архивов в формате WARC и создаёт локальную Sqlite базу с результатами. Что позволяет сильно ускорить задачи по подсчёту статистики, экспорту файлов из архива (архивы бывают большие и это важна задача) и многое другое. Единственное что я не сделал - это там нет SQL интерфейса, хотя добавить такую команду и примеры это дело пары часов.

Похожий код у меня есть для HTML страниц, он превращает дерево HTML в плоскую таблицу с дополнительным обсчётом ряда параметров. Я его всё подумывал опубликовать и возможно что база в памяти это решение. Возможно, потому сколько я не пытался не удаётся сильно уменьшить размеры таблицы тэгов. Она выходит больше оригинального файла от 7 до 21 раза, это без использования СУБД внутри, только размер pandas Dataframe.

Возвращаясь к "что угодно как SQL", я в феврале прошлого года приводил много примеров такого подхода, когда SQL синтаксис и интерфейс создаются для работы с текстовыми файлами, репозиториями Git, базой контейнеров для Docker и тд.

Чем дольше я об этом думаю, тем более чувствую что такой подход может иметь существенный потенциал для технологических продуктов. Например, если бы сервисы счётчиков посещаемости и иной пользовательской аналитики предоставляли бы не REST API, а сразу доступ к SQL таблицам с твоими данными то это резко упростило бы их интеграцию и использование. Такие внешние сервисы, кстати, есть, но суть в том что SQL интерфейсы доступа не являются сейчас стандартизированными продуктами.

Аналогично для многих других сервисов и продуктов которые сейчас интегрируются через ETL и ELT костыли.

А сама идея "что-угодно как SQL" может развиваться ещё применительно много к чему. К файловой системе, к реестру Windows, к работе с Excel/ODS файлами, к работе с онлайн таблицами (типа Google Sheets), к вебсайтам и ещё много к чему.

#thoughts #data #datatools #sql #everythingisdata

На фоне закрытия доступа к поиску по данным судебных решений я не могу не повториться о том как сейчас устроены открытые данные в России.

1. Их всё ещё много, не всё машиночитаемо, но многое пригодно к сбору.
2. Они всё ещё активно используются в самых разных проектах, в том числе в деловом обороте.
3. Основная причина закрытие - это расследования и публикации на их основе.

Фактически данные начинают закрывать когда какие-либо активисты начинают на их основе создавать хоть как-то заметные медийные продукты. Чем больше вокруг них шума, тем больше вероятность что данные прикроют.

Поэтому, из того что я наблюдаю, многие предприниматели кто создавал продукт на данных начинают не немножечко ненавидеть тех расследователей из-за которых потом эти данные закрываются. Теперь успех журналистского материала на данных из РФ оборачивается проблемами для всех не журналистов пользователей этих данных.

Но непубличных медиа материалов не бывает, поэтому этот процесс не закончится. Лично я не готов кого-либо осуждать, я подсказываю многим журналистам ответ на вопрос "почему исчезли эти данные?" потому что Вы о них написали, вот почему! Это не значит что не надо писать, это значит что стоит понимать природу этого явления.

Лично я уже упоминал что практически перестал писать о разного рода интересных датасетах внутри РФ не по той причине что писать не о чем, а по той причине что эти данные закроют. И архив любых датасетов надо делать не после того как начали закрывать, а до и тихо.

К сожалению, не только в этом году, но и в ближайшие годы эта ситуация не поменяется.

Что, безусловно, очень печалит, но непонятно как это можно поменять. Поэтому делать проекты на открытых данных, по прежнему, можно, а вот делать их публично и шумно уже нельзя, не потеряв источники данных.

#opendata #thoughts #data #russia

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

Однако, современные научные журналы - это, тоже, далеко не только тексты статей, там есть довольно много разных технологизированных тенденций и одна из них это публикация статей с данными. Такие статьи называют не datasets, а data paper, data report, data article и data note. Они включают сам текст статьи и уведомление о доступности данных включающее ссылки на первичные данные или данные полученные в результате работы.

Например, издательство Frontiers размещает data reports в своих онлайн изданиях [1]. Пока немного, всего 597 статей из 512 тысяч, это меньше чем 0.1%, но, тем не менее. Постепенно их число растёт.

В GBIF есть описание о том что такое data paper и примеры изданий их публикующих [2], подсказка , много таких изданий. Например, data paper есть в изданиях издательства Pensoft [3] и ещё немало специализированных журналов для данных вернее для статей с данными.

Есть подборки таких журналов [4] и их несложно найти при желании.

Подобные работы иногда сопровождаются приложенными дата файлами, а чаще ссылками на публикации данных в научных репозиториях. Таких как Dryad, Zenodo, Mendeley и ещё много других.

Для меня лично незакрытым вопросом остаётся воспринимать ли data papers как предмет индексирования поисковой системы по данным. С одной стороны большая часть данных из них доступны в каталогах данных, с другой стороны большая часть - это не все и многие данные в каталоги данных не попадают.

Ссылки:
[1] https://www.frontiersin.org/articles?publication-date=01%2F01%2F2007-06%2F04%2F2024&type=123
[2] https://www.gbif.org/data-papers
[3] https://mycokeys.pensoft.net/browse_journal_articles.php?form_name=filter_articles&sortby=0&journal_id=11&search_in_=0&section_type%5B%5D=134
[4] https://zenodo.org/records/7082126

#openaccess #thoughts #research #data #datasets

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

Причём именно в такой последовательности, вначале уровень развития (доход на душу населения, условно) и только далее уже число населения. К примеру, поэтому сотни тысяч наборов данных и более 200 каталогов данных в Нидерландах и почти ничего нет в Мьянме (Бирме). Собственно по этой причине нет почти никаких внутренних данных по Афганистану, Зимбабве, Туркменистану и ещё много каким странам. Но вот нельзя сказать что есть корреляция с политическим режимом в чистом виде. К примеру, в Китае более чем много данных публикуется.

Впрочем чуть ли не самым главным фактором является интегрированность страны в мировую экономику (науку, привлечение инвестиций и тд.), когда интегрированность высока то данных довольно много, особенно научных данных, кстати.

#opendata #datasets #data #thoughts

Размышляя над задачами поиска данных (data discovery) и их доступностью вспоминаю про ключевой принцип отличия открытых данных от общедоступной информации. Статус данных как открытых предполагает осознанность владельцем данных того что он делает. Чтобы опубликовать датасет, ему/ей надо подумать о метаданных, надо выбрать лицензию, надо подготовить данные в машиночитаемом виде и, желательно, убедится что данные разумного качества. Это всё хорошо работает когда такая осознанность у владельца данных есть и работает так себе когда её недостаточно.

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

Когда мы говорим про поиск данных, то пользователи редко ищут именно открытые данные, их, как правило, интересуют данные насколько возможно хорошего качества, желательно с максимальной свободой использования и желательно с минимальным техническим порогом для их использования. Желательно машиночитаемых, но часто если даже нет, то можно и скрейпить их из HTML или из документов .

Я довольно давно размышляю о том как можно охватить больше данных за пределами каталогов данных и идей и мыслей довольно много, но за каждым шагом есть свои ограничения и оценка востребованности.
1. Сейчас Dateno индексирует данные работая с ограниченным числом источников каталогизируемых полу-вручную. Если отказаться от этого принципа и подключить индексирование всего что есть через краулинг schema.org Dataset, то число наборов данных можно нарастить на 10-15 миллионов датасетов, одновременно снизится качество метаданных, появится SEO спам и просто мусор. Одна из претензий к Google Dataset Search именно по наличию такого мусора в индексе и сильная заспамленность.
2. Кроме датасетов по schema.org есть огромное число машиночитаемых ресурсов и API доступных через краулинг сайтов. Самые очевидные RSS/ATOM фиды которые к API можно отнести. Менее очевидные, к примеру, эндпоинты ArcGIS серверов которые и так уже активно в Dateno добавлялись , но не как датасеты, а как каталоги таблиц и с ручной проверкой. Тем не менее открытых API немало, но их поиск и доступность ближе к задачам OSINT и инфобеза, а не только data discovery.
3. Многие немашиночитаемые сведения можно делать машиночитаемыми автоматически. Извлекать таблицы из разных языков разметки, преобразовывать документы в таблицы или извлекать таблицы из контента там где они есть. Например, из НПА, из научных статей, из корпоративной отчетности и ещё много чего. Но это тоже много маленьких данных, интересных некоторым исследователям, журналистам, но не так вероятно что интересные data scientist'ам.
4. Тем не менее если оценивать качество поиска по числу наборов данных как основному критерию, то обогнать Google Dataset Search и другие поисковики по данным - это не то реальная, это не такая уж сложная задача. Вызовы в ней скорее в моделировании, как создавать фасеты на разнородных данных, не всегда имеющих геопривязку, например
5. Сложнее задача в создании нового качества доступа к общедоступным данным. Как сделать проиндексированные датасеты удобными? Как облегчить работу аналитиков и иных пользователей? И вот тут концептуальный момент в том где происходит переход от поисковика по метаданным к системе управления данными. К примеру, для статистических индикаторов невелика разница между тем чтобы индексировать их описание (метаданные) и сами значения. По ресурсоёмкости почти одно и то же, а имея копии сотен статистических порталов данных, остаёмся ли мы поисковиком или становимся агрегатором и можно превращаться во что-то вроде Statista ? Неочевидно пока что

#opendata #datasearch #datasets #dateno #thoughts

Помимо данных о маршрутах, о которых я ранее писал [1], есть немало узкоспециализированных источников структурированных данных, не очень то полезных для дата аналитиков и data scientist'ов, но полезных кому то ещё. Например, это данные о 3D моделях, майндмапы и какое-то число других результатов активностей распространяемых в форматах с машиночитаемым экспортом.

Их немало, но применение ограничено и области специфические. Куда интереснее всё становится когда мы переходим от восприятия поиска данных не через призму их обнаружения (discover), а через призму их извлечения и создания (extract). Данные есть и их много внутри чего-то что само по себе данными не является: веб-страниц, PDF файлов, офисных документов и иных документов разметки.

К примеру, бесконечное число таблиц находится в научных статьях и их препринтах, или в публичных отчетах компаний, или в нормативных документах и отчетах госорганов. Иногда (редко) эти таблицы легко извлекаются тэгами в разметке, чаще они представлены в виде изображений. Есть такая очень прикладная задача и даже датасеты по извлечению таких таблиц. У IBM есть датасет FinTabNet [2] с большой коллекцией таблиц извлеченных из отчетов компаний из списка S&P 500. Есть несколько десятков исследователей в мире работающих только над темой автоматического аннотирования подобных таблиц, и есть успехи в этой работе.

Так почему бы не взять один из общедоступных алгоритмов извлечения и не прикрутить к поисковой системе вроде нашего Dateno и не получить сотни миллионов таблиц для индексирования? Вот это уже на 100% вопрос масштаба. Документов в мире значительно больше чем общедоступных данных (за исключением биоинформатики, физики частиц и спутниковых снимков). При этом нужна инфраструктура чтобы хранить первичные документы, обрабатывать их и готовить таблицы. Поисковик превратится из базы метаданных в крупнейшую базу данных, из маршрутизатора на сайты с первоисточниками, в замкнутую на себя экосистему.

Но очень соблазнительно и вполне реалистично. Такой подход - это одна из причин почему я давно говорю о том что превзойти поисковый индекс Google по датасетам несложно, вопрос только в размере ресурсов которые необходимо на это затратить.

И всегда важно помнить что это очень много маленьких датасетов, в то время как для data science, к примеру, нужны хорошо размеченные "большие данные".

Ссылки:
[1] https://t.me/begtin/5616
[2] https://developer.ibm.com/data/fintabnet/

#opendata #data #thoughts #datasets #dateno

Поднакопилось какое-то количество мыслей про доступность/открытость данных и дата инженерию, прежде чем писать по каждой мысли отдельный текст, изложу тезисами:

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

- самое сложное - это производство данных и ещё сложнее производство хороших данных. Создавая Dateno одной из мыслей было хотя бы частично решить задачу нахождения данных индексируя основных производителей. Но это не решает проблему отсутствия данных. Как поощрять их создание? Конкурсы для волонтеров? Datathon'ы ? Вопрос открытый.

- геоданные очень прикольная штука когда они очищены и приведены в удобную форму. Можно, например, довольно быстро сделать геопортал Армении на базе TerriaJS и интегрировать туда данные из нашего портала открытых данных data.opendata.am даже сейчас пара сотен слоёв данных наберётся из открытых источников и результат даже будет вполне симпатичен и открыт. Стоит ли делать его с учётом скорого обновления maparmenia.am (не отовсюду и не всегда доступен, неизвестно чем будет после обновления) ? Стоит ли делать такой портал для других стран?

- особенность доступности данных в России что всё что на сайтах госорганов названо "открытыми данными" таковыми не является, или бесполезно, или не обновлялось от 4 до 8 лет. Создать портал открытых данных без гос-ва не так сложно, сколь сложно его держать актуальным и с тем что его надо обновлять. Перезапуск темы открытых данных в России так чтобы данные были востребованы? Ха! Самое очевидное - машиночитаемые нормативные документы и первичные нормативные документы и тексты для машинного обучения, систематизация научных данных и их агрегация и много-много-много датасетов. Это не дорого, этим некому заниматься внутри гос-ва и не похоже что появится кто-то в ближайшие годы. Но если федералы всё же запустят новую версию data.gov.ru то точно сделаем альтернативу ему, больше и лучше, просто чтобы все знали что они не умеют;)

- веб архивация, цифровая архивация находится в кризисе. Причин много, и они нарастают. Во первых многие страны огораживаются, как РФ от поисковых ботов, во вторых информации производится сильно больше чем раньше, волонтеров и НКО недостаточно, далее контент тяжелеет, далее всё больше контента в соцсетях с авторизацией и пэйволов, инструменты устаревают, соцсети блокируют доступ к контенту, а в некоторых странах нет даже политики сохранения даже ключевого контента.

#opendata #data #thoughts #webarchives #geodata

Чем с больше данных тем больше потребности в их эффективном сжатии. Из любопытных продуктов на эту тему:
- llama-zip - LLM-powered lossless compression tool, как уже понятно использует языковую модель LLAMA для сжатия текстов на английском языке. Работает только с текстами, сжимает как-то совсем неимоверно судя по примерам. Хочется дождаться его внешнего тестирования и сравнений с другими.
- ts_zip архиватор от Fabrice Bellard работающий с помощью встроенной языковой модели RWKV 169M v4 . Автор известен тем что создал NNCP, компрессор и прекомпрессор на основе нейросетей и побеждающий несколько лет в конкурсе Large Text Compression Benchmark

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

1. Если у данных есть предопределённые схемы то самый эффективный способ их отдавать - это Parquet.
2. Если хранение данных вообще ничем не ограничено, то сохранять в JSONL
3. Если данные нужны для аналитики и их хочется сохранять сжатыми, то форматы gz, br, xz, zst, lz4 и bz2 если их обрабатывать в Clickhouse и в формате gz если в DuckDB. Фактически надо использовать сжатие GZip'ом при всех его недостатках.
4. Для холодного хранения можно сжимать чем угодно дающим хорошее сжатие, например xz, bz2 или 7z


#thoughts #compression #data #datatools

В продолжение размышлений вслух:
1. О дешёвой дата инженерии. Посмотрел на днях некоторое количество курсов по data engineering и убеждаюсь что даже когда они про современный стек данных они не про оптимизацию бюджетов. После них можно понимать конкретные инструменты, иногда даже не только инструменты, но и общие принципы, но ответить на вопрос "А как сделать тоже самое только в 100 раз дешевле?" не получится. Может свой курс сделать типа cheap data engineering crush course? Навеяно чтением статей по создаю дешёвых data pipelines из говна и палок duckdb и cron с observability только уровня операционной системы.

2. О соцсетях. Из профессиональных соцсетей где есть что почитать LinkedIn вышел в лидеры с большим отрывом. Facebook превратился в бесконечный поток бытовухи, политоты и всех форм убийства времени, Twitter/X почти уже тоже. Остаются LinkedIn, Medium и Substack. А также какое-то количество профессиональных рассылок. По крайней мере в тех policy and engineering темах которые меня лично интересуют.

3. О веб архивации. По сути работа с веб-архивами это нишевая дата-инженерная отрасль. WARC файлы можно и нужно воспринимать как legacy big data, неудобные устаревшие форматы/контейнеры для неструктурированных данных, устаревшие стандарты и многое другое. Плюс технические и концептуальные вопросы краулинга контента. Очень хочется наличия современного инструментального стека, но тема настолько нишевая и настолько недофинансированная что непонятно откуда ему взяться. Непонятно кто такое может профинансировать. Человечество, в принципе, очень небрежно относится к тому что после него останется, во всех смыслах.

4. О мобильной слежке. Странно отсутствие масштабных сложных исследований/расследований про мобильную слежку противоборствующими сторонами. Хотя бы для Android'а где это проще. Например, какие мобильные приложения созданные в Турции или связанные с Азербайджаном или включают трекеры из этих стран используются в Армении. Или какие мобильные приложения аффилированные с Украиной используются в РФ и наоборот, какие приложения передающие инфу в РФ используются на Украине. Или Иран vs Израиль к примеру. Можно ещё посмотреть на грань противостояния Китай против США и Австралии и многое другое. Туда же можно ещё немало мировых конфликтов включить, за исключением тех где совсем цифровых сервисов нет. В принципе это про то надо принимать как факт что все коммерческие данные в конкретных юрисдикциях доступны спецслужбам этих стран. А может быть всё это есть, просто очень непублично;)

#thoughts

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

Всего в индексе Dateno сейчас 2 миллиона CSV файлов. Из них 144 тысячи файлов уже собраны и выгружены, на них обучаются алгоритмы и отрабатываются инструменты для выявления семантических типов, конвертации, преобразования форматов и тд. Всего эти файлы в несжатом виде составляют 697ГБ. Итого 697 ГБ / 144 * 2000 получается ~ 9.7 терабайта. Это только из проиндексированных каталогов данных и только CSV файлы. Кроме них ещё немало файлов XLS и XLSX, JSON, XML и многих других.

Ещё цифры:
- половина хранения, около 350ГБ - это 300 крупнейших CSV файлов. Наибольшие достигают размера в 11ГБ в несжатом виде
- крупнейшие датасеты выкладывают французы, канадцы, британцы и американцы на своих национальных порталах открытых данных

Если создавать архив хотя бы самых очевидных файлов в наиболее распространённых форматах потребуется порядка 100-500 ТБ хранения, конечно с оговорками что данные можно хранить сжатыми, с тем что если хранить несколько версий то старые версии можно класть в холодное хранилище и с тем что можно почистить дубликаты, но порядки примерно понятны. Большие отличия начинают возникать при хранении научных и спутниковых датасетов.

И добавлю что работа с таким бесконечным числом дата файлов вскрывает порой самые неожиданные технические челленджи. Например, то что нет функции из коробки по определению что содержание файла CSV файл. Даже если в каталоге данных написано что он CSV, на входе может быть ZIP или GZip файл с CSV внутри, HTML файл если файл уже удалили, ошибка в виде JSON ответа когда по какой-то причине сервер не отдаёт файл и так далее. Но если сервер не выдал ошибку, если файл лежит в хранилище, то лучший способ определить его формат - это прочитать и разобрать из него несколько строк. А встроенные идентификаторы формата не работают. У класса csv.Sniffer в Python слишком много ошибок False Positive (FAR), у duckdb полностью отсутствует поддержка не UTF-8 кодировок, Magika от Google выдаёт слишком много ошибок , как FAR, так и FRR. Приходится делать собственные простые инструменты.

#opendata #dateno #thoughts

Отвлекаясь от темы данных, немного о самоорганизации. Много лет, больше 15 у меня жизнь была организована по принципу zero inbox это когда каждое письмо во входящих было задачей, а далее день начинался с разбора почты. Правило нарушилось после ковида и, с перерывами на небольшие попытки чистить почту, к июню накопилось 1200+ писем.

Сегодня, наконец-то, удалось всё привести в порядок. Ура! Осталось 4 письма, все из которых являются именно задачами.

И, в который раз, я никак не могу упустить вниманием тот факт что до сих пор нигде не видел удобных автоматизированных email assistant'ов. Там даже ИИ необязательно для его эффективности. Но подход должен быть совершенно нестандартным.
1. Все письма которые информационные/рассылки легко идентифицируются их можно и нужно автоматически складывать в отдельную группу и создавать по ним ежесуточный/еженедельный дайджест.
2. Письмам можно автоматически присваивать теги и давать возможность отфильтровывать и группировать по этим тегам.
3. Куча дополнительных метаданных можно автоматически извлекать из писем и присваивать тегами или группировать. Например,
- письма от адресатов которые ранее Вам не писали
- письма от коллег
- наименования компаний из которых пишут отправители
- письма от контрагентов (по списку компаний/доменов)
4. Для гиков должен быть SQL интерфейс для фильтрации почты. Об этом я как-то уже писал

В современном мире быстрых сообщений часто почта выглядит как архаизм/анахронизм/неизбежное зло, но в корпоративном мире она никуда не исчезла и не исчезнет ещё скоро.

#selforg #email #thoughts #ideas

У меня есть регулярные аналитические задачи которые я решаю и которым сложно обучать других, не потому что нет людей способных к ним, а потому что они нетиповые и требуют опыта довольно длительного в разных областях. Это задачи по data discovery, обнаружению данных и систематизации источников. В каком-то смысле Dateno как поисковик, а до того каталоги каталогов данных появились как отражение этих задач. Потому что данные регулярно необходимо искать, находить, систематизировать и описывать.

Так вот в этих задачах ключевым является то что при всём развитии каталогизации данных за последние пару десятилетий слишком часто приходится сводить информацию из сотен полуструктурированных или неструктурированных источников и в таких задачах Dateno (пока что) мало помогает.

Вот примеры вопросов, выдуманные конечно, но близкие, таких задач.
1. Энергопотребление по странам Ближнего Востока
2. Индикаторы экономического роста и ёмкости рынка по странам Южной Африки
3. Реальная ценовая инфляция в Юго-Восточной Азии

И такого довольно много. В том числе по России, и пост-советским странам.

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

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

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

Всё это не творчество, а весьма структурированный процесс, результат которого, по сути, идёт в основу ТЗ на дата продукт.

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

Что я могу сказать точно так то что для всех областей data discovery инструментов нехватает. Dateno закрывает некоторые поисковые задачи, но не аналитические. GPT подобные инструменты не помогают в решении поиска данных когда данных нет. Но, возможно, инструменты подспорья аналитика могут быть куда как более структурированными и решать если не типовые задачи, то реализовывать типовые подсказки для их решения.

#thoughts #dateno

К вопросу об AI и больших языковых моделях, я на днях тестировал несколько LLM'ок вопросами в форме "дай мне расходы бюджета города N по по месяцам с января по май 2024 года". И пока ни один из них не дал такого расклада со ссылкой на первоисточник документа бюджета города. Только на новости на сайте мэрии и новостных агентств.

В этом важное ограничение всех этих инструментов - у них нет доступа к огромным базам данных на которых можно строить аналитику. Я вот сомневаюсь что Bloomberg или S&P Global откроют свои базы для OpenAI или чего-то подобного, если только это не будет какое-то стратегическое партнерство. А вот применение ИИ к макропрогнозированию и работе с экономическими данными - это будет реальный прорыв для одних и катастрофа для других.

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

А от AI краулеров почти все СМИ и иные контентные сайты начнут стремительно закрываться. И требовать убирать их контент из индексов этих AI моделей. Потому что бизнес модель контентных сайтов через рекламу или подписку скоро начнет стремительно рушится.

#ai #data #thoughts

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

Хотя такая связь и есть, но из того что я много лет наблюдаю не только по РФ, но и по другим странам я вижу гораздо большую связь с устойчивостью государства, экономикой и качеством госуправления, которые, часто, высоки именно в развитых демократиях, но, при этом в демократиях бедных, к примеру, тема открытых данных не развита или на 100% зависит от внешних грантов.

В то время как внутренние инициативы по открытости данных есть в самых разных странах: Китае, Вьетнаме, Катаре, ОАЭ, Казахстане, Таиланде и даже в России в каком-то виде. Это те страны которые, к примеру, по Democracy Matrix [1] относятся к автократиям.

Про каждую страну можно не одну статью написать почему это так, и почему в этих странах, не входящих в ОЭСР или Open Government Partnership есть довольно продвинутые инициативы, законы, порталы и научные проекты про открытые данные и на их основе.

Почему так происходит? Что общего в этих странах?

У меня нет универсального ответа на этот вопрос, но есть несколько гипотез:
1. Вне зависимости от политического руководства страны не оспаривается нигде тезис что работа госаппарата по созданию и распределению общественного блага. По мере роста числа квалифицированных пользователей данными сотрудники госорганов как минимум часть своей работы раскрывают как данные просто потому что требуются дополнительные усилия чтобы эти материалы публиковать неудобным образом (в закрытых немашиночитаемых форматах).
2. Даже в авторитарных странах есть публичная коммуникация государства с гражданами и по мере нарастания госрасходов на информатизацию, раскрытие части данных является ответом на общественные запросы: "Зачем Вы потратили на это столько денег?", "Какая с этого польза гражданам?"
3. Коммуникация с местным и международным цифровым бизнесом, привлечение зарубежных инвесторов, демонстрация открытости рынка. В авторитарных странах чаще на порталах открытых данных речь идёт о коммуникации с бизнесом.
4. Развитие науки, создание проектов с раскрытием открытых научных данных
5. Демонстрация того что "вы называете нас авторитарными, а посмотрите, у нас качество госуправления и открытость повыше вашей"
6. Демонстрация устойчивости государства: "Мы сильные и устойчивые, нам нечего скрывать, наша открытость нас не пугает"

Есть и другие, более специфичные для конкретных стран гипотезы и доводы.

А есть и взгляд с другой стороны. Когда инициативы по открытости закрываются с невнятной коммуникацией ( Россия ) или когда вместо портала открытых данных есть портал закрытых данных только для граждан и с получением не более чем по 100 записей за раз (Казахстан), такие инициативы не говорят об устойчивости гос-ва, они дают только сигналы: "Мы боимся!", "Мы не умеем этим управлять!".

А я ещё не раз напишу с примерами о том как данные публикуют в недемократических государствах.

Ссылки:
[1] https://www.democracymatrix.com/ranking

#opendata #data #thoughts

К вопросу о каталогах данных, которые я изучаю вот уже много лет, в особенности каталоги общедоступных и открытых данных, чем больше я наблюдаю рынок, экосистему и тд. в том числе относительно больших каталогов данных, тем больше убеждаюсь что весь этот рынок за очень короткое время может перемешать Microsoft или, с меньшей вероятностью, Gitlab, реализовав в Github/Gitlab такое понятие как репозиторий данных.

По сути и так огромное число датасетов публикуют через Git, особенно научные репозитории выкладывают на Github, а на размещённое там уже дают ссылки с какого нибудь Zenodo.

Причём сделать дата репозитории Microsoft может сделать очень дешёвым образом.
1. Добавить атрибут data к репозиториям с данными, чтобы их можно было бы выделить в поиске.
2. Добавить спецификацию в YAML с метаданными датасета/датасетов в этом репозитории. За основу можно взять DCAT.

К счастью или к сожалению, ничего такого они не делают и, как следствие, своего поиска по данным у Microsoft нет. Но если бы сделали то Github было бы проще индексировать с помощью Dateno.

#opendata #datasets #microsoft #github #thoughts

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

Вижу всё больше и больше таких продуктов, особенно в областях devOps, dataOps и в продуктах типа ELT/ETL и других в области современного стека данных. Я и сам в инструментах что создавал или создаю делаю такое же.

Очень скоро работа с данными не потребует знаний даже SQL потому что всё будет в этом самом декларативном программировании. Из известных мне популярных ETL/ELT движков разве что Dagster не на декларативных языках, а по модели data-as-a-code, все написано на Python.

Внутри Dateno тоже используется декларативный сбор данных с помощью движка datacrafter [1] который я изначально делал для совсем других задач по извлечению данных из API и по преобразованию файлов. А также вместе с datacrafter там работает движок apibackuper [2] в котором тоже декларативный язык но в виде конфига для Python. Его, по хорошему, надо переписать для работы с конфигом в YAML и ещё многое поправить.

Достоинство декларативных языков в том что легко генерировать эти конфиги. В Dateno краулер создаёт тысячи конфигов под каждый сайт и запускает сбор данных вызовом datacrafter'а, и уже потом собирает результаты и складывает в базу данных.

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

Пока главный недостаток почти всех инструментов такого рода в отсутствии хорошей поддержки NoSQL в целом и MongoDB в частности. Из-за чего и приходится пользоваться собственным стеком инструментов.

Ссылки:
[1] https://github.com/apicrafter/datacrafter/
[2] https://github.com/ruarxive/apibackuper

#opensource #dataengineering #thoughts

По поводу глобального синего экрана смерти из-за ошибки в антивирусе CrowdStrike [1] который поразил авиакомпании и тысячи критических инфраструктурных и просто компаний.

Ключевое тут - это хрупкость человечества и расширение списка мест этой хрупкости.

Но что пока радует так то что рукожопы пока лидируют в угрозе человечеству далеко обгоняя хакеров.

Ссылки:
[1] https://www.forbes.com/sites/kateoflahertyuk/2024/07/19/crowdstrike-windows-outage-what-happened-and-what-to-do-next/

#it #tech #thoughts

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

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

Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.

Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.

Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.

Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.

Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.

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

Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.

Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.

#dateno #statistics #indicators #geodata #geo #thoughts

Не так страшны законы как их беззаконное применение (с)
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.

Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?

По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?

Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.

Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.

У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.

Поправьте меня если я неправ.

#blogging #thoughts #telegram #regulation