Полезное чтение про данные, технологии и не только:
- 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

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

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

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

А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.

В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!

Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.

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

Ссылки:
[1] https://clearspending.ru/opendata/

#duckdb #tech #dataengineering #etl

Полезное чтение про данные технологии и не только:
- Querying 1TB on a laptop with Python dataframes [1] статья от разработчиков обёртки для систем управления запросами к базам данных Ibis про обработку 1TB данных в виде адаптированного бенчмарка TPC-H на ноутбуке с помощью разных движков для датафреймов. Надо правда оговорится что ноутбук там не абы какой а MacBook Pro с 96GB RAM, но это не отменяет того факта что RAM в 10 раз меньше чем обрабатываемых данных. Главный вывод - duckdb выше всяких похвал, единственный движок который отработал все запросы до конца.
- Whenever [2] свежая библиотека для работы с датами и временем в Python, изначально написана на Rust. Помимо того что очень быстро работает и это очень актуально при обработке больших объёмов данных, она ещё и всегда учитывает переход на летнее время.
- datawizard: Easy Data Wrangling and Statistical Transformations [3] пакет для R для манипуляции данными. Казалось бы вопрос, кто сейчас пользуется R для таких задач? Но точно пользуются и для тех кто это делает такой пакет может оказаться очень полезным.
- Confronting Impossible Futures [4] полезное чтение о том что развитие, в том числе любой сценарий развития ИИ, необходимо учитывать в корпоративных стратегиях. Несмотря на то что всё ещё идёт продолжающийся взлёт хайпа вокруг этой темы, будет ещё много событий которые могут создать новые бизнес модели, сломать имеющиеся и тд.
- Applied forecasting [5] открытый курс по прикладному прогнозированию. Видео, слайды, примеры на R, выглядит достаточно просто чтобы садиться за изучение и достаточно сложно чтобы курс был интересным.
- Questionable practices in machine learning [6] а теперь дети запомните слова которые нельзя говорить (с) статья про спорные практики в машинном обучении. Большая их часть возникает от того что где-то не подумали, где-то ошиблись, где-то нехватает практического/теоретического знания у ML разработчиков, но есть и те которые нельзя сотворить случайно. Статья полезная, больше про технологии чем про этику и про автоматизацию контроля качества ML моделей.
- The biggest-ever global outage: lessons for software engineers [7] подробный разбор ситуации с недоступностью миллионов компьютеров на базе Windows из-за антивируса CrowdStrike и того какие выводы из неё можно извлечь. Многое не только про эту историю с CrowdStrike, но и предыдущие проблемы с их антивирусом и другие примеры больших сбоев других софтверных вендоров.
- TabularFM: An Open Framework For Tabular Foundational Models [8] открытый код, научная статья и модели на HuggingFace по извлечению смысла из табличных данных. Это, конечно, упрощённое описание того что такое Tabular Foundation Model, но можно сказать что это применение нейросетей к табличным данным.

Ссылки:
[1] https://ibis-project.org/posts/1tbc/
[2] https://github.com/ariebovenberg/whenever
[3] https://easystats.github.io/datawizard/index.html
[4] https://www.oneusefulthing.org/p/confronting-impossible-futures
[5] https://af.numbat.space/
[6] https://arxiv.org/abs/2407.12220
[7] https://newsletter.pragmaticengineer.com/p/the-biggest-ever-global-outage-lessons
[8] https://www.semanticscholar.org/paper/TabularFM%3A-An-Open-Framework-For-Tabular-Models-Tran-Hoang/977fec09a458fe326e5059774e3f05ab695acf2a

#readings #ai #data #opensource

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

Вакансия целиком: https://opendata.am/2024/07/20/job-opening-community-and-partnerships-coordinator/.

Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.

#opendata #api #statistics #thoughts

Статистическая служба Малайзии внедряет AI Helper [1] в сайт для разработчиков прилагаемый к их порталу статистических данных. На простые вопросы вполне эффективно отвечает и даже умеет генерировать код для языков разработки которых нет в примерах на сайте. На сайте сейчас все примеры на Python и R, но можно получить код для Java сделав такой запрос к AI Helper'у.

В данном случае применение ИИ гос-вом самое что ни на есть безобидное.

Ссылки:
[1] https://developer.data.gov.my/#using-the-ai-helper

#opendata #ai #statistics #malaysia

В рубрике закрытых данных в РФ Департамент транспорта Москвы ограничил доступ к реестру легковых такси [1], он доступен только с заполнение ГРЗ и вводом каптчи.

Ранее реестр такси был доступен в виде таблицы на сайте мэрии Москвы mos.ru

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

Причём произошло это примерно год назад.

Правда ещё есть реестр такси Московской области объединённый с реестром такси Москвы [2], но формально он реестром такси Москвы не является.

Что первично, раскрытие данных или приватность? В РФ до недавних пор было первое, в ЕС приватность чаще на первом месте.


Ссылки:
[1] https://transport.mos.ru/auto/reestr_taxi
[2] https://mtdi.mosreg.ru/taxi-cars

#opendata #closedata #taxi #moscow #moscowregion #privacy