Чем с больше данных тем больше потребности в их эффективном сжатии. Из любопытных продуктов на эту тему:
- llama-zip - LLM-powered lossless compression tool, как уже понятно использует языковую модель LLAMA для сжатия текстов на английском языке. Работает только с текстами, сжимает как-то совсем неимоверно судя по примерам. Хочется дождаться его внешнего тестирования и сравнений с другими.
- ts_zip архиватор от Fabrice Bellard работающий с помощью встроенной языковой модели RWKV 169M v4 . Автор известен тем что создал NNCP, компрессор и прекомпрессор на основе нейросетей и побеждающий несколько лет в конкурсе Large Text Compression Benchmark

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

1. Если у данных есть предопределённые схемы то самый эффективный способ их отдавать - это Parquet.
2. Если хранение данных вообще ничем не ограничено, то сохранять в JSONL
3. Если данные нужны для аналитики и их хочется сохранять сжатыми, то форматы gz, br, xz, zst, lz4 и bz2 если их обрабатывать в Clickhouse и в формате gz если в DuckDB. Фактически надо использовать сжатие GZip'ом при всех его недостатках.
4. Для холодного хранения можно сжимать чем угодно дающим хорошее сжатие, например xz, bz2 или 7z


#thoughts #compression #data #datatools

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

Открытые данные
- Раскрытие данных о госфинансах как часть государственной политики - про проекты открытости госфинансов и их значимости
- Открытые данные как основа госполитики - о том как устроены открытые данные в мире
- Как искать данные с помощью каталогов данных. Проект Datacatalogs.ru - об одном из первых каталогов-каталогов данных
- Sharing Data for Disaster Response and Recovery Programs - об открытых данных в вопросах чрезвычайных ситуаций и восстановления
- Открытость информационных систем нормотворчества - об открытости/закрытости систем нормотворчества в России

Data engineering
- Dateno. Global Data Discovery search engine - презентация проекта поиска по данным Dateno
- Datacrafter. Каталог и озеро данных на базе MongoDB - презентация для выступления на конференции SmartData, о внутренностях продукта Datacrafter и куча технических подробностей

Open Data Armenia
- Open Finances. International and Armenia overview - обзор проектов по открытости госфинансов в мире и в Армении
- Open Data, Open Code, Open Licenses - о разных компонентах открытости

Открытый код
- Открытый код в других странах - Как и в каком объёме и кто именно публикует открытый код, почему это важно и почему это становится всё более популярным

Приватность
- Слежка через государственные мобильные приложения - о том как государственные органы следят за гражданами с помощью мобильных приложений и сливают информацию о их передвижении и действиях коммерческим компаниям
- Термины и объекты регулирования: ADM-системы - о том что такое системы для автоматического принятия решения и как они описываются в разных странах
- О необходимости контроля и аудита ADM- систем - о том как регулировать ИИ используемый для автоматического принятия решений

Веб архивация
- Организация веб-архивов - о том как устроены современные интернет архивы и Национальный цифровой архив (ruarxive.org)
- Дата инженерия и цифровая гуманитаристика - о том какие большие цифровые гуманитарные проекты есть в мире и про Национальный цифровой архив

Понятный язык
- Простой и понятный русский язык - о простоте русского языка и её измерении
- Простота нормативно-правового языка - о подходах к оценке нормативно-правовых текстов

P.S. Всего у меня 200+ неразобранных презентаций за последние 15 лет, в онлайне не больше 30. Что-то устаревает, что-то нельзя публиковать, что-то бессмысленно без самого выступления, но, по мере разбора завалов, буду выкладывать дальше.

#opendata #opensource #plainlanguage #webarchives #digitalpreservation #dataengineering #armenia

В продолжение размышлений вслух:
1. О дешёвой дата инженерии. Посмотрел на днях некоторое количество курсов по data engineering и убеждаюсь что даже когда они про современный стек данных они не про оптимизацию бюджетов. После них можно понимать конкретные инструменты, иногда даже не только инструменты, но и общие принципы, но ответить на вопрос "А как сделать тоже самое только в 100 раз дешевле?" не получится. Может свой курс сделать типа cheap data engineering crush course? Навеяно чтением статей по создаю дешёвых data pipelines из говна и палок duckdb и cron с observability только уровня операционной системы.

2. О соцсетях. Из профессиональных соцсетей где есть что почитать LinkedIn вышел в лидеры с большим отрывом. Facebook превратился в бесконечный поток бытовухи, политоты и всех форм убийства времени, Twitter/X почти уже тоже. Остаются LinkedIn, Medium и Substack. А также какое-то количество профессиональных рассылок. По крайней мере в тех policy and engineering темах которые меня лично интересуют.

3. О веб архивации. По сути работа с веб-архивами это нишевая дата-инженерная отрасль. WARC файлы можно и нужно воспринимать как legacy big data, неудобные устаревшие форматы/контейнеры для неструктурированных данных, устаревшие стандарты и многое другое. Плюс технические и концептуальные вопросы краулинга контента. Очень хочется наличия современного инструментального стека, но тема настолько нишевая и настолько недофинансированная что непонятно откуда ему взяться. Непонятно кто такое может профинансировать. Человечество, в принципе, очень небрежно относится к тому что после него останется, во всех смыслах.

4. О мобильной слежке. Странно отсутствие масштабных сложных исследований/расследований про мобильную слежку противоборствующими сторонами. Хотя бы для Android'а где это проще. Например, какие мобильные приложения созданные в Турции или связанные с Азербайджаном или включают трекеры из этих стран используются в Армении. Или какие мобильные приложения аффилированные с Украиной используются в РФ и наоборот, какие приложения передающие инфу в РФ используются на Украине. Или Иран vs Израиль к примеру. Можно ещё посмотреть на грань противостояния Китай против США и Австралии и многое другое. Туда же можно ещё немало мировых конфликтов включить, за исключением тех где совсем цифровых сервисов нет. В принципе это про то надо принимать как факт что все коммерческие данные в конкретных юрисдикциях доступны спецслужбам этих стран. А может быть всё это есть, просто очень непублично;)

#thoughts

К вопросу о том сколько в мире общедоступных / открытых данных, приведу цифры чуть более приближенные к настоящим оценкам.

Всего в индексе Dateno сейчас 2 миллиона CSV файлов. Из них 144 тысячи файлов уже собраны и выгружены, на них обучаются алгоритмы и отрабатываются инструменты для выявления семантических типов, конвертации, преобразования форматов и тд. Всего эти файлы в несжатом виде составляют 697ГБ. Итого 697 ГБ / 144 * 2000 получается ~ 9.7 терабайта. Это только из проиндексированных каталогов данных и только CSV файлы. Кроме них ещё немало файлов XLS и XLSX, JSON, XML и многих других.

Ещё цифры:
- половина хранения, около 350ГБ - это 300 крупнейших CSV файлов. Наибольшие достигают размера в 11ГБ в несжатом виде
- крупнейшие датасеты выкладывают французы, канадцы, британцы и американцы на своих национальных порталах открытых данных

Если создавать архив хотя бы самых очевидных файлов в наиболее распространённых форматах потребуется порядка 100-500 ТБ хранения, конечно с оговорками что данные можно хранить сжатыми, с тем что если хранить несколько версий то старые версии можно класть в холодное хранилище и с тем что можно почистить дубликаты, но порядки примерно понятны. Большие отличия начинают возникать при хранении научных и спутниковых датасетов.

И добавлю что работа с таким бесконечным числом дата файлов вскрывает порой самые неожиданные технические челленджи. Например, то что нет функции из коробки по определению что содержание файла CSV файл. Даже если в каталоге данных написано что он CSV, на входе может быть ZIP или GZip файл с CSV внутри, HTML файл если файл уже удалили, ошибка в виде JSON ответа когда по какой-то причине сервер не отдаёт файл и так далее. Но если сервер не выдал ошибку, если файл лежит в хранилище, то лучший способ определить его формат - это прочитать и разобрать из него несколько строк. А встроенные идентификаторы формата не работают. У класса csv.Sniffer в Python слишком много ошибок False Positive (FAR), у duckdb полностью отсутствует поддержка не UTF-8 кодировок, Magika от Google выдаёт слишком много ошибок , как FAR, так и FRR. Приходится делать собственные простые инструменты.

#opendata #dateno #thoughts

Свежий гайд от Всемирного банка про Beneficial Ownership Registers: Implementation Insights and Emerging Frontiers [1] в виде пояснений о том как реализовывать реестры конечных бенефициаров компаний и с весьма конкретными рекомендациями. На сегодняшний день таких реестров немного, самый известный это реестр компаний в Великобритании и чуть меньше в других странах, но тренд в этом направлении точно есть и общедоступные и открытые данные тоже. Конкретно в этом документе разобраны такие проекты в Нигерии, Кении, Северной Македонии и Великобритании.

Кроме того напомню что в реестрах Open Ownership есть данные из Дании, Словакии и чуть-чуть Армении. [2]

Про Армению разговор отдельный, там всего несколько компаний и сами данные довольно плохого качества, можно сказать что инициативы де-факто работающей нет.

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

Ссылки:
[1] https://openknowledge.worldbank.org/server/api/core/bitstreams/fea074cb-e6a4-4ebe-8348-6cd151d2f424/content
[2] https://register.openownership.org/data_sources

#opendata #readings #transparency

Сугубо техническое и инструментальное. Я на днях обновил исходный код утилиты 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

Давайте я для разнообразия напишу про что-нибудь хорошее с открытыми данными в РФ
- похоже что жив и даже перезапущен портал справочников Минздрава (nsi.rosminzrav.ru), это 1797 наборов данных справочной информации в виде датасетов в XML, JSON, XLS и CSV форматах для экспорта
- всё ещё живы и активны многие региональные порталы открытых данных таких как портал данных Республики Коми (opendata.rkomi.ru) и портал данных города Новосибирска (opendata.novo-sibirsk.ru). Таких обновляющихся порталов около десятка.
- всё ещё доступен и обновляется портал открытых данных Минкульта РФ (opendata.mkrf.ru) , наборов данных новых там нет, но старые продолжают обновлять.
- Пушкинский дом продолжает публиковать открытые данные в своём репозитории (dataverse.pushdom.ru)
- некоторые университеты в РФ начали публиковать открытые данные о своей деятельности, например раздел с данными в формате CSV на сайте РНИМУ им. Пирогова и раздел данных Нижегородского НГТУ . А также научные данные публикуются как отдельные проекты, как это делает СГМУ в репозитории клинических данных
- некоторые датасеты для машинного обучения публикует ВНИИАС / РЖД в рамках проекта RailDataSets

#opendata #russia #datasets

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

Похоже что сайт bigenc.ru придётся архивировать.

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

А с другой стороны, а зачем вообще на неё тратили средства?

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

Любые энциклопедические проекты должны быть открытыми, с открытыми данными, открытым кодом, API, краудсорсингом и _без любой идеологии_.

Людей жалко, конечно.

#wikipedia #bigenc #closeddata #russia

Велика вероятность закрытия сайта Большой российской энциклопедии (bigenc.ru) 17 июня. Руководство проекта написало об этом сегодня. Наша команда постарается сделать архивную копию на этих выходных. Если у Вас есть копии контента и Вы готовы их передать, мы обязательно добавим их в архив и сделаем материалы общедоступными.

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

#deathwatch #webarchive #bigenc

В продолжение про БРЭ и почему печальный конец проекта был только вопросом времени. Я бы начал с того что вопрос о том почему необходимо поддерживать классические энциклопедические проекты в мире давно не стоит на повестке. В большинстве стран где создавались национальные энциклопедии этот процесс остановился ещё лет 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

Свежий инструмент Amphi для визуальных ETL процессов, с low-code проектированием труб данных (data pipelines) через интерфейс в Jupyter lab

Из плюсов:
- low code
- не cloud-first
- базовый набор для обработки структурированных и неструктурированных данных
- всё можно делать в UI прямо в Jupyter Lab
- открытый код

Из минусов:
- low-code (для кого-то минус)
- не cloud-first (для кого-то минус)
- мало разнообразия в источниках получения данных
- лицензия Elastic, недоопенсорс

Мне чем-то напомнило Apache Nifi, но только отчасти.

Интеграция в Jupyter Lab - хорошо,но пока что и в целом надо приглядется. Продукт явно сделан пока скорее для инвесторов чем для пользователей, но без пользователей и инвестиций не будет.

В целом из разработки дата инструментов мне нравятся не только продукты, но и команды Clickhouse и Duckdb.

Хочется дождаться ETL сделанное по аналогии с Duckdb. Удобным ядром и большим числом хорошо написанных расширений. Какое-то время назад мне казалось что Meltano на эту роль подходит, но с тех пор как они отдали свои публичные ресурсы довольно хреновым маркетологам читать их стало тяжело. Развитие продукта сложно оценивать.

#etl #opensource #datatools