Сугубо техническое и инструментальное. Я на днях обновил исходный код утилиты metacrafter [1] и библиотеки для Python iterabledata [2].

Metacrafter - это утилита и библиотека для Python по выявлению семантических типов данных и далее автодокументирования датасетов. Она изначально поддерживала MongoDB, базовые типы файлов вроде csv, xml, jsonl и тд, а также большую часть SQL баз данных (через SQLAlchemy). Не хватало только поддержки файлов которые могут быть разнообразно сжаты. Эту задачу получилось решить переключившись на библиотеку iterabledata которая поддерживает работу с файлами вроде .csv.bz2, .xml.xz, .jsonl.gz и так далее. Собственно к уже имеющимся алгоритмам сжатия и форматам я добавил ещё Zstandard и Brotli. Из популярных форматов не поддерживаются пока только Snappy и 7z . Но у Snappy неудобная реализация на Python, надо её переписывать, а библиотека для 7z не поддерживает режим открытия файла в контейнере, без обязательного раз сжатия .

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

А поддержку сжатых файлов в metacrafter пришлось добавлять не просто так, а потому что хранение бесконечного числа CSV'шек и других первичных файлов в Dateno сжирает очень много места, а обрабатывать их надо. И обрабатывать достаточно быстро и с достаточно небольшими ресурсами памяти, процессора и тд.

Один из способов такой экономии это обновление инструментария для поддержки сжатых файлов на всех этапах. Причём не только на этапе обработки данных, но и на этапе извлечения и загрузки. Импорт в СУБД тоже нужен не в чистых .csv или .json, файлах, а в том числе, сжатыми тоже.

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://github.com/apicrafter/pyiterable

#opensource #datatools #data #metacrafter #dateno

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

У этого есть много причин, я бы выделил такие главные из них как:
1. Вовлечение широкого числа мотивированных участников в создание общего знания.
2. Понимание у участников того, что всё ими созданное принадлежит человечеству, не закрыто копирайтом и не является собственностью конкретного юр. лица
3. Открытая Вики экосистема: свободные лицензии, открытый код, открытые данные, открытые API и тд.
4. Гибкость, адаптируемость под новые способы работы с данными, авторедактирование, исправление и многое другое.

Для всех кто создавал знания с помощью Mediawiki или Semantic Mediawiki это может показать очевидным. Но не для создателей БРЭ в текущей их онлайн реинкарнации.

К тому как БРЭ создавалось у меня много вопросов, начиная с фундаментальной непрозрачности проекта (поди найди их годовые отчёты, их нет ) и продолжая выбранным форматом создания, но ключевое следующее:
- все материалы в БРЭ закрыты копирайтом. При том что это 100% госфинансирование, при том что в самой энциклопедии используется бесконечное число материалов взятых из первоисточников в CC-BY-NC/CC-BY.
- БРЭ никогда не была открытой средой. Там не было не только свободных лицензий, но и API, экспорта датасетов, открытого кода и вообще ничего
- всё это время чуть ли не единственная мотивация авторов писать туда была оплата за статьи. Денег нет - моментально нет нового контента.

Поэтому даже если БРЭ, по какой-либо, неведомой причине, власти РФ решат спасать то всё что необходимо сделать:
1. Опубликовать все материалы БРЭ под свободной лицензией допускающей свободное использование в любом Вики проекте, конкретно под лицензией CC-BY и в виде открытых данных.
2. Перевести в открытый код весь исходный код используемый в БРЭ.

Если не решат спасать, то сделать надо то же самое.

#government #content #encyclopedy #wiki #data

В рубрике интересных каталогов данных портал DataOne [1] с данными о о земле, климате и связанными науками, агрегирующий данные из 63 научных репозиториев по этой теме и созданных на его же технологии, доступных как hosted repositories. Большая часть этих порталов созданы университетами и органами власти в США, всего в них более 956 тысяч наборов данных и уникальная возможность поиска датасетов по их геопривязке.

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

Поддерживается Университетом Калифорнии, не имеет открытого кода, но довольно большое сообщество и открытое API.

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

#opendata #datasets #data #earthsciences

Вышел стандарт DCAT-AP 3.0 по публикации каталогов открытых данных. Это официальный стандарт Евросоюза по публикации данных и он основан на стандарте DCAT 3.0 от W3C.

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

Его отдельные ревизии есть в ЕС, в США, в отдельных европейских странах и ещё в ряде стран мира.

В Армении, если появится государственный портал открытых данных, он тоже будет с поддержкой DCAT. Если не появится, то мы добавим поддержку в Open Data Armenia

В РФ стандарт DCAT ни в какой версии не применялся. В начале инициатив по открытости Минэк РФ придумал свои "методические рекомендации" с раскрытием метаданных в виде CSV файлов. Чтобы облегчить краулинг данных на портал data.gov.ru. Рекомендации эти применяют до сих пор, хотя они и морально и технически устарели, а data.gov.ru более не существует.

Пока же добавлю что DCAT поддерживается в Dateno при индексации каталогов и, в частности, метаданные из порталов на базе ArcGIS Hub собираются именно в формате DCAT.

#opendata #data #standards

Подборка ссылок на продукты публикации датасетов для API и аналитики:

С открытым кодом:
- SQLite Studio [1] быстро первращает базы SQLite в веб интерфейс. Можно смотреть структуру таблиц и делать запросы. А также есть демо [2]. По ощущениям очень простой и удобный для этой небольшой задачи.
- Datasette [3] хорошо известный в узких кругах продукт, очень быстро превращающий датасеты в веб интерфейс. Умеет в разные данные, разные API, разные интерфейсы и куча расширений. Когда хочется конструктор и разного
- CSVBase [4] простой до безобразия для превращения CSV файлов в API. Внутри всё Python, одновременно и сервис для публикации данных онлайн для тех кто очень хочет делать это за деньги
- APIReady [5] написанный мной 11 лет назад очень простой движок по превращению CSV файлов в API. Честно говоря с той поры я его даже не развивал, просто как демонстрация самой идеи.
- APICrafter [6] тоже написанная мной утилита по публикации API к базам MongoDB. Развитие APIReady и необходимость поскольку MongoDB по умолчанию не давало и не даёт приемлимое API в их Community Server. Только в облачном сервисе есть уже что-то удобное. Всё на Python, управляется развесистыми YAML конфигами которые строятся автоматически на основе просканированных баз данных [7]

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

А я через какое-то время напишу про то какие есть бесплатные и коммерческие, не open source, онлайн инструменты делиться датасетами.

Ссылки:
[1] https://github.com/frectonz/sqlite-studio
[2] https://sqlite-studio.frectonz.io/
[3] https://datasette.io/
[4] https://github.com/calpaterson/csvbase
[5] https://github.com/ivbeg/apiready
[6] https://github.com/apicrafter/apicrafter
[7] https://github.com/apicrafter/apicrafter/blob/main/examples/rusregions/apicrafter.yml


#opensource #datatools #data #api

В рубрике как это устроено у них новый каталог открытых данных Словакии data.slovensko.sk заменил предыдущий портал data.gov.sk (более недоступен). Новый портал переписали на CSharp и его код доступен [1]. Из его особенностей - это ориентация на SPARQL, доступность возможности работы со SPARQL эндпоинтом, а также то что краулит из 12 каталогов открытых данных страны и подлерживает каталоги датасетов по стандартам DCAT-AP, SPARQL и CKAN API.

Выглядит любопытно, но эта картина была бы неполной если бы:
1. Разработчики не поломали бы все ссылки на data.gov.sk которые были в европейском data.europe.eu где новый портал даже не зарегистрирован, а старый уже недоступен и ссылки "протухли"
2. Нет общедоступной документации API нового каталога
3. Нет экспорта DCAT AP или CKAN API у нового каталога.

В целом очень неаккуратно. Про SPARQL я скажу так, у него и Semantic Web есть очень много сторонников в европейских проектах за госсчёт, но к современной дата инженерии он имеет смутное отношение. Вообще никакого, если честно. Экспорт данных в Parquet, удобное REST API и, может быть, даже GraphQL эндпоинт куда важнее.

Ссылки:
[1] https://github.com/slovak-egov/nkod-portal

#opendata #slovakia #eu #standards #data #datasets

Где то полтора года назад я писал про то как устроен поиск по данным у Гугла и про ограничения использования разметки из Schema.org. Для тех кто пропустил ту публикацию, расскажу: Schema.org - это стандарт структурированной разметки веб страниц помогающий поисковикам извлекать из веб страниц структурированные разметку о продуктах, статьях, людях , фильмах, книгах и других понятиях. Включая такое понятие как набор данных (Dataset). Саму разметку делают веб-мастера или они встроены в код веб сайта, а поисковая система находит веб страницы и умело их обрабатывает.

Изначально готовили этот стандарт Google, Microsoft и Yandex. Сейчас главный её потребитель это Гугл. Данные этой разметки индексируют, также, другие краулеры и её извлекают из индекса Common Crawl. Я как раз недавно об этом писал.

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

В таблице выборка сайтов в которых есть разметка Dataset. И вот разве они есть на сайтах вроде kakprosto.ru или cbonds.ru ? Совсем нет. Там статьи и другие материалы. И так не только по российским доменам, но и по многим другим.

Из 1.4 миллионов размеченных Datasets в Common Crawl, реально ситуация такова что около 33% мусор, около 33% коммерческие датасеты и оставшиеся 33% данные которые можно скачать. И ещё надо проверять качество их метаданных.

Конечно, реально датасетов больше чем в индексе Common Crawl и индексация веба даст больший охват. Но даже индексация данных по стандартам API CKAN или DCAT работает быстрее и качество метаданных лучше.

#opendata #dateno #data #datasetsx

За много лет у меня накопилось множество инструментов для командной строки которые я создавал для разных дата задач:
- undatum [1] утилита для обработки данных с акцентом на JSONl файлы
- datadiff [2] утилита для создания патчей для датасетов
- mongo2md [3] утилита по автогенрации markdown документации к коллекциям mongodb
- metacrafter [4] утилита и библиотека по идентификации семантических типов данных
- docx2csv [5] утилита по превращению таблиц в файлах DOCX в CSV
- lazyscraper [6] утилита по быстрому и автоматическому извлечению данных из HTML таблиц и другой разметки

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

Сейчас я задумался не пора ли многие из них перенести в один инструмент. Тот же undatum.

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

Вот примерно такое я хочу сделать с undatum добавив туда разные функции и поддерживая работу с NoSQL как приоритет.

Но самое интересная это думать над тем как это реализовать. Я всё чаще склоняюсь к тому что Duckdb правильнее воспринимать как data transformation движок, а не как хранилище. Можно очень многое ускорить с его помощью. Но не всё и тут важны альтернативы. Силами языка или встроенным DB движком.

А ещё у меня есть экспериментальный код mongorefine и код утилиты datacrafter которые живут несколько иначе и связать всё вместе сложнее.

В общем вот такие мысли в последнее время, и открытый код который хочется развивать. А вот код из Dateno можно раскрывать только ограниченно, потому что там много специфичного know how.

Ссылки:
[1] https://github.com/datacoon/undatum
[2] https://github.com/datacoon/datadifflib
[3] https://github.com/datacoon/mongo2md
[4] https://github.com/apicrafter/metacrafter
[5] https://github.com/ivbeg/docx2csv
[6] https://github.com/ivbeg/lazyscraper

#opensource #datatools #data

РБК пишут что Росавиация перестала публиковать сведения [1] о структуре авиапарков самолетов в реестре эксплуатантов самолетов. Причём сделали они это под таким экзотическим предлогом как "оптимизация размещения информации". Было бы очень смешно, не будь противно от таких отговорок.

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

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

Я не буду упоминать существующие альтернативные источники данных внутри РФ, их тоже могут закрыть. Зачем же помогать закрывающим;)

Самый очевидный косвенный источник этих данных - это Flight Radar, OpenSKY, ADS Exchange и другие проекты по краудсорсингу наблюдения за полетами воздушных судов. До тех пор пока в России не преследуют тех кто ставил их, то оперативная информация по взлётам и посадкам (действующим самолётам) будет доступна. Её будет дороже собирать, но мало что изменится. А преследовать тех кто ставил ADS-B ресиверы крайне сложно, сами они не передают информацию, только получают.

У многочисленных проектов слежки за самолётами есть базы самих самолётов. Крупнейшая мне известная находится в сервисе OpenSKY [3], а также в проекте Open Aviation Data [4].

Спасибо "оптимизаторам" из Росавиации что напомнили про все эти проекты. Давно хотел об этом написать, да всё откладывал.

Это наглядный пример как раз решения задачи по data discovery с поиском альтернативных источников закрываемой статистики.

Ссылки:
[1] https://www.rbc.ru/business/25/06/2024/667b00219a7947de5642ddfe
[2] https://favt.gov.ru/dejatelnost-aviakompanii-reestr-komercheskie-perevozki/
[3] https://opensky-network.org/aircraft-database
[4] https://atmdata.github.io/sources/

#opendata #data #russia #aviation #closeddata #statistics #alternativedata

Подборка полезных инструментов для работы с данными и не только:
- GROBID [1] библиотека и набор утилит для разбора PDF научных статей. Извлекает таблицы, ссылки, заголовки, цитаты, даты и именованные сущности. Используется внутри проекта Semantic Scholar. Открытый код под Apache 2.
- sqleton [2] универсальная библиотека для Python для доступа к разным SQL СУБД. Альтернатива SQLAlchemy, но выглядит как более простая в использовании
- reladiff [3] библиотека для Python для сравнения больших таблиц, сравнительно легко её можно доработать для сравнения больших датасетов
- Daft [4] распределенная библиотека для датафреймов на Rust и Python. Внутри Apache Arrow и язык запросов в виде функций для Python

Ссылки:
[1] https://github.com/allenai/grobid
[2] https://github.com/erezsh/sqeleton
[3] https://github.com/erezsh/reladiff
[4] https://github.com/Eventual-Inc/Daft

#opensource #datatools #data #pdf #sql #dataframes

Ещё один симпатичный бенчмарк сравнений обработки данных на Python с использованием чистого Python и разных библиотек.

Безоговорочный лидер Duckdb и близкий к нему по скорости Polars, но всё равно отстающий.

Вполне ожидаемо, от Duckdb многие в восторге именно из-за комбинаций скорости и функций.

Причём в текущем состоянии Duckdb ещё и может быть идеальным инструментом для ETL/ELT трансформации данных. Его можно рассматривать не как базу для хранения, а как инструмент быстрой обработки данных. А в нынешних облачных реалиях быстрый значит и дешёвый.

У меня вот есть штук пять внутренних и open source инструментов про которые я понимаю что если их на duckdb (или polars) смигрировать, то они станут удобнее и практичными многократно.

#opensource #datatools #data #duckdb #benchmarks

В Форбс статья про то что Минцифры переписало законопроект об обезличенной информации и то что ключевые положения там остались о том что цель законопроекта в том чтобы забрать данные у бизнеса и сконцентрировать в одной госсистеме.

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

Говоря откровенно, этот закон людоедский. Правительство оказалось неспособным собрать данные для ИИ из государственных информационных систем, хотя там их не просто много, а бесконечно много. У российского гос-ва есть такие данные как:
- медицинские данные (снимки рентгена, томографов и тд);
- спутниковые данные (структуры Роскосмоса);
- данные фото и видеофиксации (дороги, стройки и тд)
- языковые данные
- научные данные

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

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

#regulation #russia #closeddata #data

Вышла вторая версия стандарта Data Package [1] ранее он назывался Frictionless Data. Полезен он будет всем кто публикует табличные CSV файлы которые с его помощью очень хорошо описываются. Это большой плюс, особенно для тех кто не является дата инженерами или аналитиками, а рядовыми учёными, пользователям и тд.

Это же и минус. Лично я вспоминаю что мало какие интересные данные публиковал за последние годы именно в CSV. В основном же это были JSON lines файлы или parquet. А стандарт пока CSV ориентированный, что не отменяет его полезности если с CSV Вы работаете и активно. Или если пользователи готовят всё ещё данные в Excel, а надо бы что-то получше.

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

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

#opensource #standards #opendata #data #okfn

Любопытная картина по геопространственным сервисам в мире от Spatial Stack [1] за исключением того что там избыточно перечислены все подразделения ESRI.

И, конечно, отдельно нужны картины по open source стеку и по enterprise (без облака) стеку. Потому что очень уж разные задачи решаются. Не все могут и хотят решать задачи с помощью облачных сервисах.

P.S. У меня сегодня перегруз входящих материалов, сразу с десяток интересных тем о которых хочется рассказать, но видимо не все сразу.

Ссылки:
[1] https://www.spatialstack.ai

#geodata #landscapes #spatial #data

К вопросу об 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

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

Но даже так я слегка пробежался по старому коду движка metacrafter'а [1], инструмента для идентификации семантических типов данных, или более простым языком, инструмент идентификации того что за колонка в наборе данных или в базе данных и что с ней можно делать. Инструмент я потихоньку начал приводить в целевое состояние - усиление поисковых возможностей у Dateno и автодокументирование датасетов.

Что нового:
- правила для metacrafter'а перенесены теперь в новый репозиторий metacrafter-rules [2], их стало больше, в основном за счёт правил для других языков отличных от английского и русского;
- обновился серверный и клиентский режимы работы. Теперь можно ускорить сканирование данных запустив metacrafter как сервер и обращаясь к нему через параметр remote при вызовах сканирования файлов или баз данных. Это важно для ускорения процесса поскольку правила инициализируются только один раз
- добавилась команда просмотра правил 'metacrafter rules list'
- и так далее

Главный недостаток сейчас - это скорость работы на больших датасетах. Чем больше колонок тем дольше анализ, до нескольких минут. Это не так критично для задач вроде сканирования корпоративных СУБД, но тяжко для задач Dateno когда миллионы датасетов.

На самом деле чтобы всё ускорить нужно просто много ресурсов: процессорных, хранения и памяти. А прикрутив LLM'ку можно сильно повысить качество автодокументирования данных.

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

Ссылки:
[1] https://github.com/apicrafter/metacrafter/
[2] https://github.com/apicrafter/metacrafter-rules/

#opensource #data #datatools #dateno #metacrafter