Я как раз собирался составить очередную подборку интересного чтения про данные и понял что один из текстов стоит упомянуть отдельно и поговорить про него. Это заметка Is Excel immortal? [1] от Benn Stancil. Бэн регулярно пишет интересно про данные, венчурный рынок, стартапы, аналитику и про Excel он пишет очень правильные слова.

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

Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.

Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.

Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.

Но в, самом деле, какой может быть замена Excel к 2075 году?

Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее

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

Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.

Каким может быть Excel будущего?

1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks

Что можно добавить?

Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal

#thoughts #excel #data #datatools

Симпатичный жанр NO SLIDES, выступления без презентаций и одноимённая конференция [1] где нет презентаций в виде слайдов, только прямая речь и демонстрация экрана. А также таблица с выступлениями прошедшей конференции со ссылками на видеозаписи на Youtube [2]. Почти всё про данные и про аналитику, есть немало интересного что посмотреть.

Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.

Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0

#thoughts #presentations #conferences

Хорошая статья в Системном блоке про судьбу ABBYY, их продукта Compreno и научного подхода в переводе текстов [1]. Если вкратце, то судьба печально, LLM ИИ пожирают мир. Я помню в 2010-х разговоры про Compreno как люди вовлеченные в этот проект его расхваливали, но вживую его так и не успел попробовать, а теперь уже и непонятно зачем.

А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только про гибель трансформацию компьютерной лингвистики, это и про будущее онтологического моделирования, это про судьбу проектов вроде Wolfram Alpha (похоже недолгую уже), это про применение LLM в моделировании и систематизации данных.

Вот я вам приведу пример, у нас в Dateno десятки миллионов карточек датасетов и далеко не у всех есть привязка к категориям, не у всех есть теги, не у всех есть геометки и тд.. Можно вложить усилия и категоризировать их вручную, а можно натравить одну или несколько LLM и проделать эту работу. Можно ещё на несколько задач LLM натравить и будет ещё больший эффект, вопрос лишь в цене запросов или развертывания open source LLM.

А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".

Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/

#thoughts #readings #ai

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

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

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

Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.

Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.

Что с этим делать?

Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.

Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.

При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.

Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.

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

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

#opendata #dateno #geodata #thoughts

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

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

Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.

2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.

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

4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.

5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.

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

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

8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.

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

#dateno #thoughts #dataengineering #elt #etl #datapipelines

Не успела появится профессия 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

Я тут наблюдаю время от времени как публикуют открытые данные некоторые команды, в том числе с хорошей мировой репутацией, но с небольшими знаниями по современной дата инженерии и уже какое-то бесконечное время смотрю как многие открытые и не только открытые данные опубликованы. И прихожу к мысли о том что уже классическое определение открытых данных с точки зрения 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

Написал короткий лонгрид в продолжение размышлений о качестве открытых данных и дата продуктах

#opendata #thoughts #datasets

Кстати, не могу не поделиться мыслью что в мире сейчас большой явный кризис в сообществе открытости данных и вызван он развитием ИИ. Я уже не в первый раз слышу разговоры в стиле зачем нам публиковать хорошие открытые данные и работать над их качеством если ИИ всё сожрёт. Это прям большое ментальное давление на очень многие проекты Wikipedia, OpenStreetMap, сообщество OKF и десятки других.

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

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

#opendata #thoughts #community

К вопросу о том что есть и чего нет в Dateno в контексте того доступно через наше API и того что исследователи уже искали по наукометрии. Есть специфика данных в Dateno в том что пока ещё исследовательских данных в нём маловато и по очень объективным причинам.

В реестре каталогов данных Dateno сейчас 874 репозитория научных данных из которых проиндексировано пока только 99 репозиториев, а это чуть более 11% источников метаданных такого типа. И даже эти 874 репозитория - это не все репозитории научных данных в мире, а наиболее очевидные. Точное число, скорее всего, никто не знает потому что реестры вроде Re3Data и Fairsharing более широко трактуют научные дата-ресурсы и включают туда не только каталоги данных, но и базы данных.

Возвращаясь к источникам, в чём с ними сложность:
1. Коммерческие каталоги научных данных вроде облачных продуктов Elsevier и Figshare значительно ограничивают возможности их индексирования. Проиндексировать их можно, но высока вероятность блокировок с их стороны. это примерно 34% каталогов научных данных в реестре Dateno.
2. Каталоги результатов научной деятельности на DSpace легко индексируются, но устроены так что невозможно отдельно индексировать только датасеты. Чтобы проиндексировать их надо скачать все метаданные всех объектов и далее уже фильтровать датасеты. Причем последних будет не более 5% от всего общего числа материалов
3. Некоторые каталоги научных данных вроде тех что основаны Thredds или Galaxy имеют очень скудный набор метаданных, по сути они выглядят как большие научные файлохранилища. Правда и области применения у них узкие: метеорология и биоинформатика, поэтому они пока отложены
4. Для научных репозиториев данных главное API до сих пор это OAI-PMH 2.0. Очень унаследованное, очень неудобное по многим критериям, очень стандартизированное и обладающее критическим недостатком: оно не отдаёт ссылки на файлы в метаданных. Иначе говоря карточку датасета получить можно с базовыми полями метаданных, но метаданных связанных с ним файлов нельзя. Это решается, но тем не менее.
5. Есть очень крупные источники научных наборов данных в OpenAIRE, ScienceDB, ScienceBase, DataCite, BASE и ещё ряде других. Проиндексировав даже парочку из них можно добавить сразу +10-20 миллионов записей, но..., качество датасетов будет посредственное. Честно говоря я тяну с их подключением так долго как могу не потому что это сложно, а потому что качество содержания поискового индекса снизится, у этих источников нет ссылок на ресурсы. Потому что все они агрегируют через OAI-PMH 2.0 Если бы единственным критерием качества в Dateno было бы только число записей, то вопросов бы не было.

Итого это развёрнутый ответ на невысказанный вопрос "Почему в Dateno так мало научных данных, всего 488 тысяч датасетов?" Краткий ответ: из-за качества данных, а более полный ответ выше.

В любом случае крайне важно что ключевой продукт Dateno, резко отличающий его от Google Dataset Search, - это открытый индекс. Помимо открытого API к поиску это ещё и открытый реестр каталогов данных и открытая статистика.

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

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

А пока покажу некоторые существенные отличия и сравнение GDS (Google Dataset Search) и Dateno.

#opendata #dateno #thoughts #datacatalogs #datasets