Я давно не кидался окаменелостями в адрес российского Гостеха, и тут, уж извините, дам ссылку на выступление Мишустина на Digital Astana 2024 [1]. Как всегда, важно не то что он говорил, а то что _не говорил_. Ни разу не упомянул Гостех, ограничившись разговорами про Госуслуги и российские цифровые платформы. А почему он его не упомянул?

А потому что:
1. Значительная часть государственных информационных систем в Средней Азии делаются за счёт международной поддержки: USAID, скандинавские страны, Германия и др., разного рода глобальные институты развития. Рассчитывать что их будут интегрировать с российскими ИТ разработками или что там будет сотрудничество не стоит. Но это не самое главное.
2. Власти Казахстана уже "отбились" от попыток впаривания им Гостеха, ловко соскочив после того как Сбер попал под санкции. Я бы оценивал шансы на возвращение как минимальные.
3. Российские технологические решения которые пушит Пр-во в другие страны будут восприниматься как инструменты российской "мягкой силы" и влияния, поэтому у их внедренцев неслабые такие шансы влететь на санкции.
4. Гостеха не существует! [2]

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

Ссылки:
[1] https://t.me/government_rus/11105
[2] https://t.me/begtin/5370

#government #govtech #russia #thoughts

Сегодня, любопытства ради, я посмотрел трансляцию Минцифры РФ со "Дня госуслуг".

Всё думал как это прокомментировать, сформулирую мысли тезисами:
1. Госуслуги в России действительно существуют, в отличие от Гостеха, там есть реальное нечто о чём создатели могут рассказать и что могут показать. Показали они не так много как могли, рассказали что-то кому-то общеизвестное, кому-то новое, но главное - живое. Поэтому в качестве комплимента можно сказать что их пиар достаточно правдив, хотя и неуклюж, но неуклюж достаточно естественно.

2. Конечно, правильно было бы назвать не "День Госуслуг", а день Ростелекома. По сути большая часть происходящего и большинство выступавших именно оттуда, из РТК Лабс. Но это просто констатация факта, от этого не горячо, не холодно.

3. Ключевой вопрос, важный всегда и везде, а на кой .. зачем всё это мероприятие проводилось? Вопрос немаловажен тем что в отличие от того же Гостеха, Госуслуги не надо продавать. Госуслуги - это монопольный государственный продукт работа с которым для госорганов - это не опция, а уже скорее обязательство и функция. "Продавать его" госслужащим, федеральным или региональным смысла нет. Как и нет смысла "продавать его" аудитории форума Россия. В принципе нет никакого смысла его продавать, кроме как если надо рассказывать о достижениях РФ в ИТ и уже понятно что с Гостехом так знатно облажались что надо говорить о чём-либо реальном.

4. Почему выглядит странно? Потому что, по хорошему, у российских Госуслуг могут быть три канала коммуникации:
4.1. Руководство - это когда надо "продать идею" чтобы влить в них ещё больше денег. Но это, как бы, давно уже не проблема. Скорее проблемой было какое-то время то что часть сервисов внутри Госуслуг планировали (планируют ли ещё?) передать в Гостех. Но не передали, что показательно
4.2. Разработчики, но для этого надо превращать Госуслуги в экосистему и открывать код/API, документацию и тд. Эту "поляну" Пр-во уже слило в Гостех, где идея госэкосистемы благополучно-неблагополучно приобретает свою доменную смерть.
4.3. Потенциальные покупатели из других стран. Поскольку уже понятно что даже на постсоветском пространстве Гостех никто не купит, потому что этот "кот в мешке" ещё даже не родился и уж тем более ничего показать нельзя. А вот Госуслуги живые. Но что-то не было похоже что аудитория именно этого форума была хоть как-то приближена к такой продаже.

5. О последнем подробнее. Да, Госуслуги в РФ - это гораздо более живой проект чем многие другие и выступавшие на форуме в целом, общем и в частностях не врали. Но кое-что осталось за кадром (не договаривали), а это стоимость. И стоимость там огромна поскольку она включала ещё и стоимость внедрения, интеграции, доработки многих информационных систем и ещё много чего. В общем это дохрена, не каждая развитая страна может позволить себе такие расходы. Я лично с трудом могу поверить что какая-либо из стран являющаяся российским торговым партнером или, хотя бы, не вводившая санкции начнёт вот так просто такой продукт внедрять.

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

Часть 1 из 2

#thoughts #government #russia

7. При этом что российские госуслуги, что лучшие мировые примеры вроде Эстонии или Сингапура или госуслуги Казахстана через КаспиБанк, увы, не являются отчуждаемыми продуктами. Даже частично, даже в какой-то разумной доле снижающей стоимость внедрения. Во многих других областях решения есть: порталы данных, официальная статистика, гражданские бюджеты, порталы открытой демократии и открытого диалога и ещё много чего, но не для госуслуг. Да чего уж там, даже для национальных цифровых идентификационных платформ нет универсальных решений. Слишком большая вариативность уже созданного и необходимого для интеграции и местных законов, местной цифровой готовности и тд.

8. Поэтому пиар российских Госуслуг - это странно, очень странно. Может ещё одно предположение что всё это было к кадровым перестановкам в Пр-ве? Но, что-то вот верится с трудом. Пока всё идет к тому что ничего не поменяется (с)

9. Хорошо бы он выглядел если бы на сцену вышел бы какой-нибудь российский вице-премьер и так бы и сказал: "Друзья, мы тут с Гостехом облажались и решили его закрыть. А вот Госуслуги это супер, Госуслуги это зашибись. Теперь будем на их основе госпроекты развивать". Шучу, наверное;) Это на меня так сюрреализм происходящего влияет.

Часть 2 из 2

#thoughts #government #russia

Я давно не напоминал что, помимо всего прочего, я веду реестр каталогов данных по всему миру, Common Data Index [1] и там уже почти 10 тысяч записей, большая часть которых - это геопорталы/каталоги геоданных. Но также много порталов открытых данных, микроданных, научных данных, каталогов индикаторов и каталогов данных для машинного обучения. Список пополняется постоянно, но работы ещё много.

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


1. Очень малое пересечение современной дата инженерии, дата анализа и data science с порталами открытых данных и вообще почти всеми системами раскрытия информации госорганами. Публикация данных в Parquet большая редкость, в лучшем случае доступны данные в форматах SPSS или Stata, а чаще просто CSV/XLS. Официальная статистика, в принципе, феноменально консервативна. Не так много статслужб публикующих данные на постоянной основе как открытые данные, но почти все так или иначе данные публикуют.

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

3. Государства практически не создают каталогов данных для развития ИИ. Два концентратора данных и моделей - Kaggle и HuggingFace используются всеми, частными, корпоративными и государственными исследователями. Только в некоторых странах такие наборы данных публикуются на официальных порталах открытых данных.

Ссылки:
[1] https://github.com/commondataio/dataportals-registry

#opendata #datacatalogs #data #thoughts

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

Так вот интересное тут то что в корпоративном мире с густой аналитикой (когда аналитические команды есть и они сильные, и запрос на аналитику есть), так вот в корпоративном мире data lineage - это понятное явление, если не привычное, то активно обсуждаемое и применяемое. Потому что decision maker'ы часто задают вопросы о том как та или иная цифра вышла и надо иметь ответ о том, а как же это оно есть. А вот в мире общедоступных данных, статистики и, отчасти, науки, с data lineage всё, скажем там, плоховато или очень специфично.

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

В других случаях это сложнее, иногда реально сложно. Ещё сложнее со статистикой, при том что там источники данных указываются практически всегда, но это указание может быть не на первоисточник, а на глобальный источник. Простой пример, какой-нибудь агрегатор данных статистики вроде портала данных ООН (data.un.org) может собирать данные из портала данных Международного валютного фонда (IMF) data.imf.org, а тот из первоисточника, страницы раскрытия данных на сайте резервного банка или статслужбы страны. А кто-то коммерческий может, опять же, собирать данные с портала ООН и выдавать в своём сервисе.
Будем ли он при этом рисовать полноценный data lineage от портала данных ООН до сайта статслужбы ? Вообще-то нет, источником будет указан портал ООН.

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

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

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

Первые продвинуты технологически и сразу ориентированы на разработчиков (API, структурированное хранилище, преобразование данных в удобные форматы JSON, Parquet и др.), но, часто, забывая про базовые принципы открытости.

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

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

Это реализация data lineage, это проектирование по принципу API First, это современные форматы предоставления данных для data science, это _всегда_ наличие bulk download, это концепция в основе что data as a product, а не данные как производный продукт от чего то ещё.

#opendata #data #dataengineering #thoughts

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

Есть много способов чистить данные с помощью кода, есть хороший инструмент OpenRefine [1] известный многим кто с открытыми данными работает. Но, честно скажу, в плане скорости, но не удобства, к примеру, DuckDB бьёт все рекорды. Главный недостаток - отсутствие удобного UI аналогичного OpenRefine или то что в OpenRefine нельзя, к примеру, заменить его движок на DuckDb.

В остальном это реально очень быстро. И работать с локально с многогигабайтными датасетами и в миллионы и десятки миллионов записей - вполне реально. Для сравнения, OpenRefine у меня едва-едва тянет базу в 100 тысяч записей в 680 MB.

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

В общем-то на базе DuckDB и, скорее всего, chDb можно построить полноценную дата-студию по приведению данных в порядок перед загрузкой в хранилище. Опять же, если иметь полноценный веб интерфейс поверх.

Такие инструменты хорошо встраиваются как ядро более прикладных дата-продуктов.

Ссылки:
[1] https://openrefine.org

#data #datatools #thoughts #duckdb #openrefine

Я регулярно пишу про такое явление как датацентричное мышление "что угодно как таблица" и в более узком звучании "что-угодно как 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