Google анонсировали закрытие сервиса сокращения ссылок goo.gl [1] после того как уже более 5 лет с его помощью нельзя было создавать ссылки, а также были отключены функции аналитики и управления.

Окончательно сервис будет закрыт 25 августа 2025 когда перестанут работать ссылки, а с 23 августа 2024 года будет выводится предупреждение при их открытии.

Чтобы будет с этими ссылками? Команда Archive Team ведёт архивацию всех коротких ссылок в проекте URLTeam [2]. Уже просканировано 38.6 миллиардов ссылок и обнаружены активными 7 миллиардов ссылок.

P.S. ArchiveTeam это крупнейший глобальный краудсорсинговый проект по веб архивации, поучаствовать в нём можно с помощью ПО Warrior которое выполняет задачи по сбору контента синхронизируясь с трекером задач [3].

Ссылки:
[1] https://9to5google.com/2024/07/18/googl-links/
[2] https://tracker.archiveteam.org:1338/status
[3] https://wiki.archiveteam.org/index.php/ArchiveTeam_Warrior

#digitalpreservation #webarchive #google #crowdsourcing #urlshortener

Зима близко, "зима данных" статья
Are we entering a Data Winter? On the urgent need to preserve data access for the public interest [1] от Stefaan Verhulst
и исследование Consent in Crisis: The Rapid Decline of the AI Data Commons [2] от учёных из MIT.

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

В том числе
✅ 5% всех данных и 25% данных высокого качества для обучения ИИ (C4, RefinedWeb, Dolma) теперь ограничены в доступе
✅ 45% данных в наборе C4 ограничены условиями сервиса
✅ Многие контентные сайты теперь устанавливают пэйволы или меняют условия использования.
✅ Массово блокируются краулеры от таких компаний как OpenAI, Anthropic, и Google.
✅ Ряд компаний начинают требовать плату за доступ к данным (напр. Reddit, Inc., StackOverflow).
✅ Активно предпринимаются юридические действия такие как иск The New York Times’ против OpenAI и Microsoft.

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

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

Ссылки:
[1] https://policylabs.frontiersin.org/content/commentary-are-we-entering-a-data-winter
[2] https://www.dataprovenance.org/consent-in-crisis-paper

#opendata #data #ai #readings

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