Полезное чтение про данные, технологии и не только:
- A Quick Introduction to JavaScript Stored Programs in MySQL [1] в блоге Oracle MySQL о том чтобы использовать программы на Javascript внутри СУБД. Признаться честно я к этой практике отношусь с глубоким осуждением, особенно в части аргументации что миллионы разработчиков используют Javascript так давайте запихнём его ещё куда-нибудь. Тем не менее тоже тренд и тоже понятный, хотя и запоздавший лет на 10-15.
- ColPali: Efficient Document Retrieval with Vision Language Models [2] про распознавание текстов и Vision LLMs. Вот это перспективная тема которая может подвинуть текущих лидеров OCR.
- A Crash Course on Relational Database Design [3] хорошая инфографика для совсем начинающих работающих с базами данных. Как и вся наглядная инфографика от ByteByteGo
- Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models [4] проект STORM родом из Stanford который позволяет писать длинные вики статьи с помощью LLM на произвольные неизвестные темы. Выглядит как инструмент который может, как сильно дополнить Википедию, так и создать реального её конкурента с нуля, так и ещё много для чего. Когда уже сделают LLM для быстрой генерации корпоративной документации на ИТ продукты или доков для open source?
Ссылки:
[1] https://blogs.oracle.com/mysql/post/a-quick-introduction-to-javascript-stored-programs-in-mysql
[2] https://huggingface.co/blog/manu/colpali
[3] https://blog.bytebytego.com/p/a-crash-course-on-relational-database
[4] https://storm-project.stanford.edu/research/storm/
#ai #readings #sql #databases #ocr #data
- A Quick Introduction to JavaScript Stored Programs in MySQL [1] в блоге Oracle MySQL о том чтобы использовать программы на Javascript внутри СУБД. Признаться честно я к этой практике отношусь с глубоким осуждением, особенно в части аргументации что миллионы разработчиков используют Javascript так давайте запихнём его ещё куда-нибудь. Тем не менее тоже тренд и тоже понятный, хотя и запоздавший лет на 10-15.
- ColPali: Efficient Document Retrieval with Vision Language Models [2] про распознавание текстов и Vision LLMs. Вот это перспективная тема которая может подвинуть текущих лидеров OCR.
- A Crash Course on Relational Database Design [3] хорошая инфографика для совсем начинающих работающих с базами данных. Как и вся наглядная инфографика от ByteByteGo
- Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models [4] проект STORM родом из Stanford который позволяет писать длинные вики статьи с помощью LLM на произвольные неизвестные темы. Выглядит как инструмент который может, как сильно дополнить Википедию, так и создать реального её конкурента с нуля, так и ещё много для чего. Когда уже сделают LLM для быстрой генерации корпоративной документации на ИТ продукты или доков для open source?
Ссылки:
[1] https://blogs.oracle.com/mysql/post/a-quick-introduction-to-javascript-stored-programs-in-mysql
[2] https://huggingface.co/blog/manu/colpali
[3] https://blog.bytebytego.com/p/a-crash-course-on-relational-database
[4] https://storm-project.stanford.edu/research/storm/
#ai #readings #sql #databases #ocr #data
Oracle
A Quick Introduction to JavaScript Stored Programs in MySQL
Recently MySQL added the ability to write Stored Programs in JavaScript. This allows developers to leverage JavaScript capabilities for complex data processing and business logic within the database server. We think this is really cool. Here’s why.
sq data wrangler [1] или просто sq - утилита для преобразований данных в SQL базах данных. По идеологии это аналог jq, утилиты для обработки JSON файлов. Фактически, автор, явно фанат jq перенес идею на SQL. Лично мне синтаксис jq всегда был из серии перловых регулярных выражений. Недостаточно просто и ясно, но это исключительно моё личное восприятие и есть немало фанатов jq применяющих его по поводу и без.
Поддерживает MySQL, Postgres, SQL Server, SQLite, CSV, JSON и XLSX.
Включают множество самых разных команд для работы с источниками данных и таблицами. Хорошо зайдет для тех кто работает с SQL, но не любит SQL синтакс.
#datatools #datawrangiling #dataengineering #opensource #sql #jq
Поддерживает MySQL, Postgres, SQL Server, SQLite, CSV, JSON и XLSX.
Включают множество самых разных команд для работы с источниками данных и таблицами. Хорошо зайдет для тех кто работает с SQL, но не любит SQL синтакс.
#datatools #datawrangiling #dataengineering #opensource #sql #jq
Такое чувство что производители облачных СУБД "почувствовали фишку" / осознали возможность демонстрации своих продуктов через наглядное представление больших датасетов. Я ранее писал про OSS Insight [1] от TiDB Cloud с данными извлечёнными из Github, а теперь и команда ClickHouse анонсировала [2] CryptoHouse [3] как бесплатный открытый сервис для блокчейн аналитики. Просто открываешь веб интерфейс и делаешь SQL запросы. А то что интерфейс не требует даже авторизации - это лишнее подтверждение способности выдерживать большие нагрузки.
Выглядит как довольно продвинутая штука, есть немало баз данных над которыми было бы интересно иметь такой интерфейс, но без заоблачных облачных ценников и с возможностью экспорта результатов. Скорее всего это можно сделать достаточно просто и дешево с помощью ch-ui [4] и подобных инструментов.
Недостатков тоже много, в таком интерфейсе непонятно где увидеть документацию, нет data storitelling'а, есть только чистый SQL и таблицы. Не для всех задач такое подходит, но когда знаешь структуру данных и что ищешь, то вполне.
Ссылки:
[1] https://ossinsight.io/
[2] https://clickhouse.com/blog/announcing-cryptohouse-free-blockchain-analytics
[3] https://crypto.clickhouse.com/
[4] https://github.com/caioricciuti/ch-ui
#opendata #clickhouse #sql #blockchain
Выглядит как довольно продвинутая штука, есть немало баз данных над которыми было бы интересно иметь такой интерфейс, но без заоблачных облачных ценников и с возможностью экспорта результатов. Скорее всего это можно сделать достаточно просто и дешево с помощью ch-ui [4] и подобных инструментов.
Недостатков тоже много, в таком интерфейсе непонятно где увидеть документацию, нет data storitelling'а, есть только чистый SQL и таблицы. Не для всех задач такое подходит, но когда знаешь структуру данных и что ищешь, то вполне.
Ссылки:
[1] https://ossinsight.io/
[2] https://clickhouse.com/blog/announcing-cryptohouse-free-blockchain-analytics
[3] https://crypto.clickhouse.com/
[4] https://github.com/caioricciuti/ch-ui
#opendata #clickhouse #sql #blockchain
А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.
Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.
К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)
#sql #datatools #data
Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.
К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)
#sql #datatools #data
SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL [1] научная статья от исследователей Google про GoogleSQL. Особенность в том что это не альтернативный новый язык, а именно специальный диалект для удобного написания конвейеров и так называемого pipe syntax для SQL.
GoogleSQL уже реализован во многих их продуктах вроде BigQuery, F1 и ZetaSQL [2]
Ссылки:
[1] https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/
[2] https://github.com/google/zetasql
#google #sql #datatools #data
GoogleSQL уже реализован во многих их продуктах вроде BigQuery, F1 и ZetaSQL [2]
Ссылки:
[1] https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/
[2] https://github.com/google/zetasql
#google #sql #datatools #data
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs