Читаю работу OpenAlex: End-to-End Process for Topic Classification [1] от команды графа по научным работам OpenAlex о том как они классифицируют научные работы по каким темам и там у них есть иерархическая модель разметки работ по уровням Domains -> Fields -> Subfields -> Topics, причём тем (topics) довольно много и они привязаны все к статьям в Википедии. А вообще они построили свою классификацию через идентификацию макрокластеров [3] сообществ через цитирование. Большая и интересная тема, с понятной сложностью и результатами.
Я на всё это смотрю с точки зрения улучшения классификации датасетов в Dateno [4]. Сейчас в Dateno используется два классификатора. Европейский Data Theme [5] используемый в их портале data.europe.eu, но у него всего 13 тем очень верхнеуровневых и тематические категории (topic category) из ISO 19115 [6] которых 19 штук и тоже без иерархии. Тематические категории используются в каталогах данных на базе Geonetwork и в программе INSPIRE Евросоюза и они применимы к геоданным, в первую очередь.
Это одна из особенностей Dateno, да и остальных индексаторов датасетов. По разным блокам и типам каталогов данных свои тематические категории, не связанные между собой и кроме обычных датасетов и геоданных есть ещё и большие банки статистических данных живущих по своим правилам и своим группам.
Сложностей несколько:
- в отличие от научных работ здесь нет цитирования или аналогичных связей, значительно сложнее строить смысловые кластеры. Их можно строить на названиях, оригинальных тематиках в первоисточнике, тематиках самого первоисточника, но не на цитировании и не на связях.
- язык науки в мире почти весь английский, а там где не английский то французский, но в целом все исходят из того что он английский. А среди датасетов много данных на самых разных языках. Тут как раз проще со статистикой которая почти всегда имеет английскую версию и сложнее с остальным.
Тем не менее своя классификация необходима и её идеальные параметры были бы когда одна тема охватывает не более 10 тысяч наборов данных или временных рядов. То есть если мы имеем базу в 22 миллиона набора датасетов, то тематик должно быть не менее 2.2 тысяч, а ещё лучше не менее 5 тысяч. Тогда пользователь получает возможность быстро сузить поиск до нужной ему темы. Тогда у Dateno появляется ещё одна важная модель его применения, это подписка на появление нужных данных в одной или нескольких узких областях избегая ложных срабатываний при ключевых словах.
Без ИИ тут, кстати, не обойтись и ребята из OpenAlex использовали модель GPT 3.5 Turbo [7] для кластеризации научных работ и подбора названий выявленным кластерам.
Ссылки:
[1] https://docs.google.com/document/d/1bDopkhuGieQ4F8gGNj7sEc8WSE8mvLZS/edit?tab=t.0
[2] https://docs.google.com/spreadsheets/d/1v-MAq64x4YjhO7RWcB-yrKV5D_2vOOsxl4u6GBKEXY8/edit?gid=983250122#gid=983250122
[3] https://zenodo.org/records/10560276
[4] https://dateno.io
[5] https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/data-theme
[6] https://apps.usgs.gov/thesaurus/term-simple.php?thcode=15&code=000
[7] https://www.leidenmadtrics.nl/articles/an-open-approach-for-classifying-research-publications
#opendata #opensource #dateno #thoughts
Я на всё это смотрю с точки зрения улучшения классификации датасетов в Dateno [4]. Сейчас в Dateno используется два классификатора. Европейский Data Theme [5] используемый в их портале data.europe.eu, но у него всего 13 тем очень верхнеуровневых и тематические категории (topic category) из ISO 19115 [6] которых 19 штук и тоже без иерархии. Тематические категории используются в каталогах данных на базе Geonetwork и в программе INSPIRE Евросоюза и они применимы к геоданным, в первую очередь.
Это одна из особенностей Dateno, да и остальных индексаторов датасетов. По разным блокам и типам каталогов данных свои тематические категории, не связанные между собой и кроме обычных датасетов и геоданных есть ещё и большие банки статистических данных живущих по своим правилам и своим группам.
Сложностей несколько:
- в отличие от научных работ здесь нет цитирования или аналогичных связей, значительно сложнее строить смысловые кластеры. Их можно строить на названиях, оригинальных тематиках в первоисточнике, тематиках самого первоисточника, но не на цитировании и не на связях.
- язык науки в мире почти весь английский, а там где не английский то французский, но в целом все исходят из того что он английский. А среди датасетов много данных на самых разных языках. Тут как раз проще со статистикой которая почти всегда имеет английскую версию и сложнее с остальным.
Тем не менее своя классификация необходима и её идеальные параметры были бы когда одна тема охватывает не более 10 тысяч наборов данных или временных рядов. То есть если мы имеем базу в 22 миллиона набора датасетов, то тематик должно быть не менее 2.2 тысяч, а ещё лучше не менее 5 тысяч. Тогда пользователь получает возможность быстро сузить поиск до нужной ему темы. Тогда у Dateno появляется ещё одна важная модель его применения, это подписка на появление нужных данных в одной или нескольких узких областях избегая ложных срабатываний при ключевых словах.
Без ИИ тут, кстати, не обойтись и ребята из OpenAlex использовали модель GPT 3.5 Turbo [7] для кластеризации научных работ и подбора названий выявленным кластерам.
Ссылки:
[1] https://docs.google.com/document/d/1bDopkhuGieQ4F8gGNj7sEc8WSE8mvLZS/edit?tab=t.0
[2] https://docs.google.com/spreadsheets/d/1v-MAq64x4YjhO7RWcB-yrKV5D_2vOOsxl4u6GBKEXY8/edit?gid=983250122#gid=983250122
[3] https://zenodo.org/records/10560276
[4] https://dateno.io
[5] https://op.europa.eu/en/web/eu-vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/data-theme
[6] https://apps.usgs.gov/thesaurus/term-simple.php?thcode=15&code=000
[7] https://www.leidenmadtrics.nl/articles/an-open-approach-for-classifying-research-publications
#opendata #opensource #dateno #thoughts
Полезные ссылки про данные, технологии и не только:
- Towards Inserting One Billion Rows in SQLite Under A Minute [1] заметка 2021 года о том как высокопроизводительно загружать миллиарды строк а базы SQLite. Актуально для всех кто делает высокопроизводительные системы не имея больших бюджетов.
- GROBID [2] переводится как GeneRation Of BIbliographic Data, инструментарий с открытым кодом по извлечению структурированного содержания из PDF файлов, особенно применяется к научным статьям. Активно используется для извлечения библиографических данных.
- Depsy [3] онлайн база цитирования пакетов с открытым кодом в научных статьях. От той же команды что делает OpenAlex. Этот проект более не развивается уже лет 7, а жаль, но исходный код доступен как и API.
- Cadent Open Data [4] раздел с открытыми данных в Cadent, британской газовой компании. Открытые данные прописаны в стратегии цифровизации и отдельный портал с данными [5] которые раскрываются по регуляторным требованиям и инициативами по data sharing
- Schneider Electric Datasets [6] коллекция наборов данных на портале для разработчиков Schneider Electric. В основном данные по энергопотреблению. Бесплатные, но требуют регистрации
Ссылки:
[1] https://avi.im/blag/2021/fast-sqlite-inserts/
[2] https://grobid.readthedocs.io/en/latest/
[3] http://depsy.org
[4] https://cadentgas.com/reports/open-data
[5] https://cadentgas.opendatasoft.com/pages/welcome/
[6] https://exchange.se.com/develop/developer-resources?source=developerResources&developerResources=Datasets
#opendata #opensource #readings
- Towards Inserting One Billion Rows in SQLite Under A Minute [1] заметка 2021 года о том как высокопроизводительно загружать миллиарды строк а базы SQLite. Актуально для всех кто делает высокопроизводительные системы не имея больших бюджетов.
- GROBID [2] переводится как GeneRation Of BIbliographic Data, инструментарий с открытым кодом по извлечению структурированного содержания из PDF файлов, особенно применяется к научным статьям. Активно используется для извлечения библиографических данных.
- Depsy [3] онлайн база цитирования пакетов с открытым кодом в научных статьях. От той же команды что делает OpenAlex. Этот проект более не развивается уже лет 7, а жаль, но исходный код доступен как и API.
- Cadent Open Data [4] раздел с открытыми данных в Cadent, британской газовой компании. Открытые данные прописаны в стратегии цифровизации и отдельный портал с данными [5] которые раскрываются по регуляторным требованиям и инициативами по data sharing
- Schneider Electric Datasets [6] коллекция наборов данных на портале для разработчиков Schneider Electric. В основном данные по энергопотреблению. Бесплатные, но требуют регистрации
Ссылки:
[1] https://avi.im/blag/2021/fast-sqlite-inserts/
[2] https://grobid.readthedocs.io/en/latest/
[3] http://depsy.org
[4] https://cadentgas.com/reports/open-data
[5] https://cadentgas.opendatasoft.com/pages/welcome/
[6] https://exchange.se.com/develop/developer-resources?source=developerResources&developerResources=Datasets
#opendata #opensource #readings
В качестве регулярных напоминаний, за долгое время я написал немало инструментов с открытым кодом для работы с данными. За что члены команды меня регулярно ругают потому что основная моя работа искать клиентов и профессионалов в команду, но слишком я люблю работать руками, поэтому разного рода инструментов создал много и часть поддерживаю.
- newsworker - библиотека для Python по автоматическому извлечению новостей из веб страниц. Анализирует структуру веб страницы, кластеризует блоки, идентифицирует элементы блоков, парсит даты и создаёт RSS ленту на основе. Написал это много лет назад и до сих пор использую, но уже не обновляю
- qddate - библиотека для Python для парсинга дат в условно любом формате, которые могут быть написаны на 8 языках, в разных стилях и тд. Особенность в том что работает она очень быстро, не использует регулярные выражения, а вместо этого внутри используется библиотека pyparsing. Плюс куча оптимизаций по тому как парсить даты максимально быстро. До сих пор использую, но код практически не обновлялся
- undatum - утилита командной строки для обработки данных в форматах CSV, JSON, NDJSON, Parquet, BSON и др. Изначально была цель сделать аналог xsv для NDJSON. В целом получилось и я ей пользуюсь до сих пор, но с недавних пор чаще использую DuckDB из-за значительно большей производительности. Возможно утилиту переделаю однажды.
- apibackuper - утилита командной строки для архивации API. Странно звучит, но да, утилита через API выгружает все данные последовательным перебором и сохраняет их в виде датасета JSON Lines/NDJSON. Активно используется внутри Dateno для сбора метаданных и в Ruarxive для архивации
- metacrafter - утилита и библиотека для идентификации семантических типов данных. Полезна для выявления смысловых полей в датасетах: адресов, названий компаний, кодов типа ИНН, ОГРН, КПП и тд., а также для идентификации персональных данных. Делал я её относительно недавно, умеет она работать и с файлами и с базами данных. Тоже используется в Dateno
- docx2csv - утилита извлечения таблиц из файлов docx. Очень простая и были планы перенести этот код в универсальный дата конвертер.
- pyiterable - библиотека для Python для потокового чтения дата файлов таких как BSON, JSON, NDJSON, Parquet, ORC, XLS, XLSX и XML в том числе сжатых Gzip, Bzip2, ZStandard и другими компрессорами. Используется внутри metacrafter и undatum.
—
По прошествии лет многие инструменты хочется переделать, а многие устаревают, но их написание часто сильно ускоряет работу с теми данными с которыми я работаю постоянно.
#opensource #data #datatools
- newsworker - библиотека для Python по автоматическому извлечению новостей из веб страниц. Анализирует структуру веб страницы, кластеризует блоки, идентифицирует элементы блоков, парсит даты и создаёт RSS ленту на основе. Написал это много лет назад и до сих пор использую, но уже не обновляю
- qddate - библиотека для Python для парсинга дат в условно любом формате, которые могут быть написаны на 8 языках, в разных стилях и тд. Особенность в том что работает она очень быстро, не использует регулярные выражения, а вместо этого внутри используется библиотека pyparsing. Плюс куча оптимизаций по тому как парсить даты максимально быстро. До сих пор использую, но код практически не обновлялся
- undatum - утилита командной строки для обработки данных в форматах CSV, JSON, NDJSON, Parquet, BSON и др. Изначально была цель сделать аналог xsv для NDJSON. В целом получилось и я ей пользуюсь до сих пор, но с недавних пор чаще использую DuckDB из-за значительно большей производительности. Возможно утилиту переделаю однажды.
- apibackuper - утилита командной строки для архивации API. Странно звучит, но да, утилита через API выгружает все данные последовательным перебором и сохраняет их в виде датасета JSON Lines/NDJSON. Активно используется внутри Dateno для сбора метаданных и в Ruarxive для архивации
- metacrafter - утилита и библиотека для идентификации семантических типов данных. Полезна для выявления смысловых полей в датасетах: адресов, названий компаний, кодов типа ИНН, ОГРН, КПП и тд., а также для идентификации персональных данных. Делал я её относительно недавно, умеет она работать и с файлами и с базами данных. Тоже используется в Dateno
- docx2csv - утилита извлечения таблиц из файлов docx. Очень простая и были планы перенести этот код в универсальный дата конвертер.
- pyiterable - библиотека для Python для потокового чтения дата файлов таких как BSON, JSON, NDJSON, Parquet, ORC, XLS, XLSX и XML в том числе сжатых Gzip, Bzip2, ZStandard и другими компрессорами. Используется внутри metacrafter и undatum.
—
По прошествии лет многие инструменты хочется переделать, а многие устаревают, но их написание часто сильно ускоряет работу с теми данными с которыми я работаю постоянно.
#opensource #data #datatools
GitHub
GitHub - ivbeg/newsworker: Advanced news feeds extractor and finder library. Helps to automatically extract news from websites…
Advanced news feeds extractor and finder library. Helps to automatically extract news from websites without RSS/ATOM feeds - ivbeg/newsworker
Билл Гейтс опубликовал оригинальный код Microsoft 50 летней давности, для Altair BASIC [1].
Подумать только, я вот BASIC во всех формах застал очень мало. Только QBasic в ранних версиях MS DOS и совсем немного Visual Basic в Windows. А так мой самый ранний код - это Паскаль и Ассемблер. И, признаться, в 15-16 лет я писал его чище и аккуратнее, но с куда меньшим пониманием ответов на вопрос "зачем".
Но код на BASIC это, в любом случае, ностальгия.
Ссылки:
[1] https://www.gatesnotes.com/home/home-page-topic/reader/microsoft-original-source-code
#opensource #microsoft #billgates #digitalpreservation
Подумать только, я вот BASIC во всех формах застал очень мало. Только QBasic в ранних версиях MS DOS и совсем немного Visual Basic в Windows. А так мой самый ранний код - это Паскаль и Ассемблер. И, признаться, в 15-16 лет я писал его чище и аккуратнее, но с куда меньшим пониманием ответов на вопрос "зачем".
Но код на BASIC это, в любом случае, ностальгия.
Ссылки:
[1] https://www.gatesnotes.com/home/home-page-topic/reader/microsoft-original-source-code
#opensource #microsoft #billgates #digitalpreservation
Я вот всё расхваливаю DuckDB как очень быстрый движок для обработки данных, а он не один такой. Например, ещё есть FireDucks который делает команда из японского NEC и который они активно оптимизируют конкурируя с DuckDB и Polars и в который добавляют поддержку ускорения через GPU.
Плюс разработчики много полезного пишут в своём блоге о том как они работают над оптимизацией обработки запросов [1]
Но есть и существенный минус, его исходный код, похоже, не открыт. Мне не удалось его найти в их репозиториях, там есть только собранные пакеты для Python.
P.S. Картинка отсюда [2].
Ссылки:
[1] https://fireducks-dev.github.io/posts/
[2] https://www.linkedin.com/posts/avi-chawla_pandas-is-getting-outdated-and-an-alternative-activity-7312407582340485120-fH_K?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAA_-HABh4I2pH__YZElkrySwr_MWhdKIVs
#data #datatools #opensource
Плюс разработчики много полезного пишут в своём блоге о том как они работают над оптимизацией обработки запросов [1]
Но есть и существенный минус, его исходный код, похоже, не открыт. Мне не удалось его найти в их репозиториях, там есть только собранные пакеты для Python.
P.S. Картинка отсюда [2].
Ссылки:
[1] https://fireducks-dev.github.io/posts/
[2] https://www.linkedin.com/posts/avi-chawla_pandas-is-getting-outdated-and-an-alternative-activity-7312407582340485120-fH_K?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAA_-HABh4I2pH__YZElkrySwr_MWhdKIVs
#data #datatools #opensource
Сугубо техническое. К вопросу про автодокументирование и применение LLM. Я в качестве теста решил обновить инструмент undatum [1] переделав команду analyze для анализа структуры разных видов дата файлов: csv, jsonl, parquet и xml и добавив поддержку не таких машиночитаемых xls, xlsx и даже таблиц из docx файлов.
Но главное было автоматизировать документирование датасетов. Утилита теперь принимает опцию —autodoc при которой список колонок таблиц передаётся в AI Perplexity и полученные описания используются для генерации описания к полям. Соответственно, можно задавать разные языки и получать детальное описание колонки на нужном языке.
Это, конечно, не всё что нужно для автодокументирования датасетов, но некая существенная часть.
И да, в некоем преобразованном виде оно используется в Dateno [2] и есть ещё много других областей применения.
Пока код в основной ветке undatum и для работы надо также обновить библиотеку pyiterable [3] и пока нет отдельного релиза в виде пакета для Python, но потестировать уже можно.
Для работы надо ввести ключ для API Perplexity в переменную окружения PERPLEXITY_API_KEY и вызвать команду
undatum analyze —autodoc —language <язык> <название дата файла>
Дата файл может быть сжатым, например, somedata.csv.gz или somedata.jsonl.zst
Ссылки:
[1] https://github.com/datacoon/undatum
[2] https://dateno.io
[3] https://github.com/apicrafter/pyiterable
#opensource #datatools #data
Но главное было автоматизировать документирование датасетов. Утилита теперь принимает опцию —autodoc при которой список колонок таблиц передаётся в AI Perplexity и полученные описания используются для генерации описания к полям. Соответственно, можно задавать разные языки и получать детальное описание колонки на нужном языке.
Это, конечно, не всё что нужно для автодокументирования датасетов, но некая существенная часть.
И да, в некоем преобразованном виде оно используется в Dateno [2] и есть ещё много других областей применения.
Пока код в основной ветке undatum и для работы надо также обновить библиотеку pyiterable [3] и пока нет отдельного релиза в виде пакета для Python, но потестировать уже можно.
Для работы надо ввести ключ для API Perplexity в переменную окружения PERPLEXITY_API_KEY и вызвать команду
undatum analyze —autodoc —language <язык> <название дата файла>
Дата файл может быть сжатым, например, somedata.csv.gz или somedata.jsonl.zst
Ссылки:
[1] https://github.com/datacoon/undatum
[2] https://dateno.io
[3] https://github.com/apicrafter/pyiterable
#opensource #datatools #data
Обнаружил ещё один инструмент по проверке данных validator [1], умеет делать кросс табличные проверки данных и использует схему из спецификации Frictionless Data [2]. Пока малоизвестный, но кто знает. Он выглядит неплохо по способу реализации, но есть проблема с самой спецификацией и о ней отдельно.
Я неоднократно писал про Frictionless Data, это спецификация и набор инструментов созданных в Open Knowledge Foundation для описания и публикации наборов данных. Спецификация много лет развивалась, вокруг неё появился пул инструментов, например, свежий Open Data Editor [3] помогающий готовить датасеты для публикации на дата платформах на базе ПО CKAN.
С этой спецификацией есть лишь одна, но серьёзная проблема. Она полноценно охватывает только плоские табличные файлы. Так чтобы работать со схемой данных, использовать их SDK, тот же Open Data Editor и тд. Это даёт ей применение для некоторых видов данных с которыми работают аналитики и куда хуже с задачами дата инженерными.
Существенная часть рабочих данных с которыми я сталкивался - это не табличные данные. К примеру, в плоские таблицы плохо ложатся данные о госконтрактах или юридических лицах или объектах музейных коллекций. Там естественнее применения JSON и, соответственно, построчного NDJSON.
Для таких данных куда лучше подходят пакеты валидации данных вроде Cerberus [4]. Я использовал её в случае с реестром дата каталогов [5] в Dateno и пока не видел решений лучше.
Ссылки:
[1] https://github.com/ezwelty/validator/
[2] https://specs.frictionlessdata.io
[3] https://opendataeditor.okfn.org
[4] https://docs.python-cerberus.org/
[5] https://github.com/commondataio/dataportals-registry/
#opensource #data #datatools #dataquality
Я неоднократно писал про Frictionless Data, это спецификация и набор инструментов созданных в Open Knowledge Foundation для описания и публикации наборов данных. Спецификация много лет развивалась, вокруг неё появился пул инструментов, например, свежий Open Data Editor [3] помогающий готовить датасеты для публикации на дата платформах на базе ПО CKAN.
С этой спецификацией есть лишь одна, но серьёзная проблема. Она полноценно охватывает только плоские табличные файлы. Так чтобы работать со схемой данных, использовать их SDK, тот же Open Data Editor и тд. Это даёт ей применение для некоторых видов данных с которыми работают аналитики и куда хуже с задачами дата инженерными.
Существенная часть рабочих данных с которыми я сталкивался - это не табличные данные. К примеру, в плоские таблицы плохо ложатся данные о госконтрактах или юридических лицах или объектах музейных коллекций. Там естественнее применения JSON и, соответственно, построчного NDJSON.
Для таких данных куда лучше подходят пакеты валидации данных вроде Cerberus [4]. Я использовал её в случае с реестром дата каталогов [5] в Dateno и пока не видел решений лучше.
Ссылки:
[1] https://github.com/ezwelty/validator/
[2] https://specs.frictionlessdata.io
[3] https://opendataeditor.okfn.org
[4] https://docs.python-cerberus.org/
[5] https://github.com/commondataio/dataportals-registry/
#opensource #data #datatools #dataquality
Я лично не пишу научных статей, потому что или работа с данными, или писать тексты. Но немало статей я читаю, почти всегда по очень узким темам и пользуюсь для этого, в основном, Semantic Scholar и подобными инструментами. Смотрю сейчас Ai2 Paper Finder [1] от института Аллена и они в недавнем его анонсе [2] пообещали что он умеет находить очень релевантные ответы по по очень узким темам. Собственно вот пример запроса по узкой интересной мне теме и он нашёл по ней 49 работ.
Вот это очень интересный результат, в списке интересных мне инструментов прибавилось однозначно.
Там же в анонсе у них есть ссылки на схожие продукты в этой области и на бенчмарки LitSearch [3] и Pasa [4] для измерения качества поиска по научным работам работам.
Ссылки:
[1] https://paperfinder.allen.ai/
[2] https://allenai.org/blog/paper-finder
[3] https://github.com/princeton-nlp/LitSearch
[4] https://github.com/bytedance/pasa
#ai #openaccess #opensource #science
Вот это очень интересный результат, в списке интересных мне инструментов прибавилось однозначно.
Там же в анонсе у них есть ссылки на схожие продукты в этой области и на бенчмарки LitSearch [3] и Pasa [4] для измерения качества поиска по научным работам работам.
Ссылки:
[1] https://paperfinder.allen.ai/
[2] https://allenai.org/blog/paper-finder
[3] https://github.com/princeton-nlp/LitSearch
[4] https://github.com/bytedance/pasa
#ai #openaccess #opensource #science
И о научных работах которые я искал, собственно более всего меня интересовали свежие статьи о автодокументировании наборов данных и вот наиболее релевантная работа AutoDDG: Automated Dataset Description Generation using Large Language Models [1] которую я проглядел несмотря на то что у меня в Semantic Scholar настроены фильтры с уведомлением о статьях по определенным темам. Кстати, хорошо бы если бы эти фильтры могли иметь форму запросов к AI помощнику, результаты должны быть точнее.
А статья интересная, от команды Visualization, Imaging, and Data Analysis Center at New York University (VIDA-NYU) которые делали очень много разных инструментов по автоматизации анализа данных и, кстати, они авторы одного из поисковиков по открытым данным Auctus [2], только они забросили этот проект года 3 назад, но он был интересен.
Вот эта команда вместе со статьёй выложили код AutoDDG [3] который пока явно мало кто видел. Можно код посмотреть и увидеть что они там делали примерно то что и я в утилите undatum [4], но с лучшей проработкой. Вернее у меня проработка была практическая и моя утилита умеет датасеты в разных форматах документировать, но у них, несомненно, качество документирования проработаннее и продуманнее.
Хорошая статья, полезный код. Прилинковывать его к своим проектам я бы не стал, но идеи подсмотреть там можно. Заодно они применяют ИИ для выявления семантических типов данных, приятно что кто-то думает в том же направлении что и я;)
Ссылки:
[1] https://www.semanticscholar.org/reader/5298f09eced7aa2010f650ff16e4736e6d8dc8fe
[2] https://github.com/VIDA-NYU/auctus
[3] https://github.com/VIDA-NYU/AutoDDG
[4] https://t.me/begtin/6578
#opensource #datadocumentation #ai #aitools
А статья интересная, от команды Visualization, Imaging, and Data Analysis Center at New York University (VIDA-NYU) которые делали очень много разных инструментов по автоматизации анализа данных и, кстати, они авторы одного из поисковиков по открытым данным Auctus [2], только они забросили этот проект года 3 назад, но он был интересен.
Вот эта команда вместе со статьёй выложили код AutoDDG [3] который пока явно мало кто видел. Можно код посмотреть и увидеть что они там делали примерно то что и я в утилите undatum [4], но с лучшей проработкой. Вернее у меня проработка была практическая и моя утилита умеет датасеты в разных форматах документировать, но у них, несомненно, качество документирования проработаннее и продуманнее.
Хорошая статья, полезный код. Прилинковывать его к своим проектам я бы не стал, но идеи подсмотреть там можно. Заодно они применяют ИИ для выявления семантических типов данных, приятно что кто-то думает в том же направлении что и я;)
Ссылки:
[1] https://www.semanticscholar.org/reader/5298f09eced7aa2010f650ff16e4736e6d8dc8fe
[2] https://github.com/VIDA-NYU/auctus
[3] https://github.com/VIDA-NYU/AutoDDG
[4] https://t.me/begtin/6578
#opensource #datadocumentation #ai #aitools
www.semanticscholar.org
[PDF] AutoDDG: Automated Dataset Description Generation using Large Language Models | Semantic Scholar
An academic search engine that utilizes artificial intelligence methods to provide highly relevant results and novel tools to filter them with ease.
Очень любопытный подход к созданию каталогов данных для распространения тяжёлых датасетов бесплатно 0$ Data Distribution [1]. Если вкратце то автор воспользовался сервисом Clouflare R2 в опции Egress и используя DuckDB и таблицы Iceberg, распространяя файлы в формате Parquet.
DuckDB там можно заменить на PyIceberg или Snowflake, главное возможность бесплатно подключить и захостить данные. У автора хорошее демо [2] с тем как это работает, ограничения только в том что надо вначале, достаточно быстро и автоматически получить ключ доступа к каталогу, но это как раз не проблема.
Это, с одной стороны, выглядит как чистый лайфхак ибо Cloudflare может изменить ценовую политику, а с другой очень даже полезная модель применения.
И сама работа с таблицами используя Apache Iceberg [3]. Если вы ещё не читали об этом подходе и инструменте, то стоит уделить время. Это тот случай когда каталог данных существует в дата инженерном контексте, а то есть по автоматизации работы с данными, но без СУБД. Однако поверх Iceberg можно построить свои системы управления данными, как открытые так и не очень. Это одна из фундаментальных технологий в том смысле что из неё и других как конструктор можно собрать свой дата продукт.
Ссылки:
[1] https://juhache.substack.com/p/0-data-distribution
[2] https://catalog.boringdata.io/dashboard/
[3] https://iceberg.apache.org/
#opensource #datacatalogs #dataengineering #analytics
DuckDB там можно заменить на PyIceberg или Snowflake, главное возможность бесплатно подключить и захостить данные. У автора хорошее демо [2] с тем как это работает, ограничения только в том что надо вначале, достаточно быстро и автоматически получить ключ доступа к каталогу, но это как раз не проблема.
Это, с одной стороны, выглядит как чистый лайфхак ибо Cloudflare может изменить ценовую политику, а с другой очень даже полезная модель применения.
И сама работа с таблицами используя Apache Iceberg [3]. Если вы ещё не читали об этом подходе и инструменте, то стоит уделить время. Это тот случай когда каталог данных существует в дата инженерном контексте, а то есть по автоматизации работы с данными, но без СУБД. Однако поверх Iceberg можно построить свои системы управления данными, как открытые так и не очень. Это одна из фундаментальных технологий в том смысле что из неё и других как конструктор можно собрать свой дата продукт.
Ссылки:
[1] https://juhache.substack.com/p/0-data-distribution
[2] https://catalog.boringdata.io/dashboard/
[3] https://iceberg.apache.org/
#opensource #datacatalogs #dataengineering #analytics
Substack
0$ Data Distribution
Ju Data Engineering Weekly - Ep 78
Про Apache Iceberg как всё более нарастающий технологический тренд в дата инженерии, ещё в декабре 2024 года Amazon добавили его поддержку в S3, а сейчас появляется всё больше число инструментов поддерживающих подключение к Apache Iceberg.
Даже удивительно как технология которой уже более 8 лет может стремительно набрать популярность при достижении определённого уровня зрелости и появлении эффективных инструментов.
Что важно знать про Apache Iceberg:
1. Это стандарт и ПО для построения озер данных созданный для преодоления ограничений предыдущих продуктов со схожими функциями такими как Apache Hudi
2. В основе Apache Iceberg технологии хранения на базе S3 и файлы Parquet. Parquet используется как контейнеры хранения данных, а S3 как хранилище данных и метаданных
3. Фундаментальная идея в реализации недорого хранилища для аналитических данных с высокопроизводительным доступом через SQL.
4. Важная причина роста популярности в комбинации: производительности, снижения стоимости и большой экосистемы из движком для запросов (query engines)
5. Серверных продуктов с открытым кодом для Apache Iceberg пока немного, кроме самой референсной реализации есть Nessie и Lakekeeper. Но много облачных провайдеров которые поддерживают такие таблицы.
6. Большая часть примеров сейчас про облачные S3 хранилища, в основном AWS. Для подключения S3 совместимых хранилищ требуется повозится
7. Применять Apache Iceberg оправдано когда у вас есть команда аналитиков умеющих в SQL и совсем неоправдано для не умеющих
8. К задачам связанным с открытыми данными этот тип дата каталога малоприменим потому что он про удобное рабочее место для продвинутого аналитика, а не про дистрибуцию данных.
9. Вообще такие продукты - это про разницу между каталогами данных, каталогами метаданных, каталогами открытых данных. Названия выглядят так словно отличий мало, а отличия огромны. Как и области применения.
#opensource #dataengineering #dataanalytics #iceberg
Даже удивительно как технология которой уже более 8 лет может стремительно набрать популярность при достижении определённого уровня зрелости и появлении эффективных инструментов.
Что важно знать про Apache Iceberg:
1. Это стандарт и ПО для построения озер данных созданный для преодоления ограничений предыдущих продуктов со схожими функциями такими как Apache Hudi
2. В основе Apache Iceberg технологии хранения на базе S3 и файлы Parquet. Parquet используется как контейнеры хранения данных, а S3 как хранилище данных и метаданных
3. Фундаментальная идея в реализации недорого хранилища для аналитических данных с высокопроизводительным доступом через SQL.
4. Важная причина роста популярности в комбинации: производительности, снижения стоимости и большой экосистемы из движком для запросов (query engines)
5. Серверных продуктов с открытым кодом для Apache Iceberg пока немного, кроме самой референсной реализации есть Nessie и Lakekeeper. Но много облачных провайдеров которые поддерживают такие таблицы.
6. Большая часть примеров сейчас про облачные S3 хранилища, в основном AWS. Для подключения S3 совместимых хранилищ требуется повозится
7. Применять Apache Iceberg оправдано когда у вас есть команда аналитиков умеющих в SQL и совсем неоправдано для не умеющих
8. К задачам связанным с открытыми данными этот тип дата каталога малоприменим потому что он про удобное рабочее место для продвинутого аналитика, а не про дистрибуцию данных.
9. Вообще такие продукты - это про разницу между каталогами данных, каталогами метаданных, каталогами открытых данных. Названия выглядят так словно отличий мало, а отличия огромны. Как и области применения.
#opensource #dataengineering #dataanalytics #iceberg
Amazon
Представляем Таблицы Amazon S3 – полностью управляемые таблицы Apache Iceberg, оптимизированные для аналитических рабочих нагрузок…
Узнайте больше о новинках AWS с помощью Представляем Таблицы Amazon S3 – полностью управляемые таблицы Apache Iceberg, оптимизированные для аналитических рабочих нагрузок
Полезные ссылки про данные, технологии и не только:
- Cloudflare R2 data catalog [1] свежий каталог данных на базе Apache Iceberg от Cloudflare поверх их сервиса хранения файлов R2. Хорошая новость, потому что R2 дешевле Amazon S3 при сравнимом качестве сервиса. Жду когда Backblaze запустит аналогичный сервис для их Backblaze B2
- xorq [2] читается как zork, фреймворк для обработки данных с помощью разных движков. Там и DuckDB, и Pandas, и DataFusion и др. Удобство в универсальности, но продукт пока малоизвестный, надо смотреть
- Iceberg?? Give it a REST! [3] автор рассуждает о том что без REST каталога Iceberg малополезен и, в принципе, про развитие этой экосистемы. Многие уже рассматривают стремительный взлёт Iceberg как хайп, что не отменяет того что технология весьма любопытная.
- BI is dead. Change my mind. [4] текст от Engeneering director в Clickhouse о том как меняется (может поменяться) BI в ближайшее время. TLDR: LLM + MCP + LibreChat. Чтение полезное для всех кто занимается внутренней аналитикой и использует Clickhouse
- Roadmap: Data 3.0 in the Lakehouse Era [5] изменения в экосистеме управления данными с точки зрения венчурного капитала. Простым языком для тех кто инвестирует средства в то какие новые технологии в дата инженерии появились и развиваются.
Ссылки:
[1] https://blog.cloudflare.com/r2-data-catalog-public-beta/
[2] https://github.com/xorq-labs/xorq
[3] https://roundup.getdbt.com/p/iceberg-give-it-a-rest
[4] https://www.linkedin.com/pulse/bi-dead-change-my-mind-dmitry-pavlov-2otae/
[5] https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era
#opensource #dataanalytics #datatools #dataengineering
- Cloudflare R2 data catalog [1] свежий каталог данных на базе Apache Iceberg от Cloudflare поверх их сервиса хранения файлов R2. Хорошая новость, потому что R2 дешевле Amazon S3 при сравнимом качестве сервиса. Жду когда Backblaze запустит аналогичный сервис для их Backblaze B2
- xorq [2] читается как zork, фреймворк для обработки данных с помощью разных движков. Там и DuckDB, и Pandas, и DataFusion и др. Удобство в универсальности, но продукт пока малоизвестный, надо смотреть
- Iceberg?? Give it a REST! [3] автор рассуждает о том что без REST каталога Iceberg малополезен и, в принципе, про развитие этой экосистемы. Многие уже рассматривают стремительный взлёт Iceberg как хайп, что не отменяет того что технология весьма любопытная.
- BI is dead. Change my mind. [4] текст от Engeneering director в Clickhouse о том как меняется (может поменяться) BI в ближайшее время. TLDR: LLM + MCP + LibreChat. Чтение полезное для всех кто занимается внутренней аналитикой и использует Clickhouse
- Roadmap: Data 3.0 in the Lakehouse Era [5] изменения в экосистеме управления данными с точки зрения венчурного капитала. Простым языком для тех кто инвестирует средства в то какие новые технологии в дата инженерии появились и развиваются.
Ссылки:
[1] https://blog.cloudflare.com/r2-data-catalog-public-beta/
[2] https://github.com/xorq-labs/xorq
[3] https://roundup.getdbt.com/p/iceberg-give-it-a-rest
[4] https://www.linkedin.com/pulse/bi-dead-change-my-mind-dmitry-pavlov-2otae/
[5] https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era
#opensource #dataanalytics #datatools #dataengineering
The Cloudflare Blog
R2 Data Catalog: Managed Apache Iceberg tables with zero egress fees
R2 Data Catalog is now in public beta: a managed Apache Iceberg data catalog built directly into your R2 bucket.
Любопытный проект Local deep research [1] локальный privacy-first инструмент для постановки заданий LLM для комплексных исследований. По аналогии с режимами deep research в OpenAI, Perplexity и других облачных прдуктах.
Описание очень симпатично и кажется практичным, но лично у меня с первой попытки не завелось, исследования по темам Recent development in CSV files analysis и Recent development in automatic data analysis не принесли никаких результатов.
Наверняка дело в настройках, но, как бы, из коробки не заработало. Тем не менее, несомненно, инструмент интересный.
Впрочем это не единственный инструмент, есть ещё deep-searcher [2] который тоже умеет искать с использованием разных моделей и возвращать результаты локально.
Ссылки:
[1] https://github.com/LearningCircuit/local-deep-research
[2] https://github.com/zilliztech/deep-searcher
#opensource #ai #research #analytics
Описание очень симпатично и кажется практичным, но лично у меня с первой попытки не завелось, исследования по темам Recent development in CSV files analysis и Recent development in automatic data analysis не принесли никаких результатов.
Наверняка дело в настройках, но, как бы, из коробки не заработало. Тем не менее, несомненно, инструмент интересный.
Впрочем это не единственный инструмент, есть ещё deep-searcher [2] который тоже умеет искать с использованием разных моделей и возвращать результаты локально.
Ссылки:
[1] https://github.com/LearningCircuit/local-deep-research
[2] https://github.com/zilliztech/deep-searcher
#opensource #ai #research #analytics
GitHub
GitHub - LearningCircuit/local-deep-research: Local Deep Research is an AI-powered assistant that transforms complex questions…
Local Deep Research is an AI-powered assistant that transforms complex questions into comprehensive, cited reports by conducting iterative analysis using any LLM across diverse knowledge sources in...