Очень много архивных данных

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

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

Что из этого стоит записать на будущее:
1. Всячески избегать большого числа множества схожих, но очень малых файлов. Их архивация - это долго, больно и неправильно. Лучше ещё на этапе их получения/извлечения сразу складывать их в контейнеры вроде архивных файлов (zip, tar), баз данных (sqlite, duckdb) или монтируемых файловых систем вроде veracrypt. Потому что при всех рисках битых секторов, архивация множества мелких файлов очень медленный процесс.
2. Все чувствительные файлы всегда хранить в зашифрованных контейнерах (всё тот же veracrypt поможет). На случай повреждения таких файлов, держать несколько их копий. Вся работа с чувствительными данными также всегда должна быть внутри зашифрованных контейнеров.
3. Правило 3-2-1 для резервных копий очень простое и придумали его не дураки. Придерживаясь его можно избежать наиболее неприятных ситуаций с потерей данных.
4. Файлы веб-архивов неэффективны для сжатия. По умолчанию инструменты работы с WARC файлами поддерживают только если файлы не сжаты или сжаты gzip, а сами файлы вне зависимости от типа хранятся вперемешку. WARC устарел как контейнер, но хранение множества мелких файлов гораздо хуже и сопряжено с потерей метаданных.
5. Документация - это главный технический долг в отношении данных и архивов. Особенно когда восстанавливаешь архивы 20 и более летней давности. Иногда остаётся код с помощью которых данные были получены, иногда первичные данные, иногда даже описание из первоисточника, но полная прослеживаемость есть далеко не всегда.
6. Длинные не-латинизированные имена файлов - это зло. При копировании из NTFS в файловые системы Linux слишком часто возникают ошибки из-за длинных названий файлов на кириллице. Решается это переименованием или помещением файла в контейнер, но тем не менее

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

#datahoarding #thoughts #backups #data

Полезное чтение про данные, технологии и не только:
- Databases in 2024: A Year in Review [1] ежегодный обзор от Andy Pavlo про состояние и развитие СУБД и инструментов работы с данными. Ожидаемо про особенности лицензирования open source баз данных и про рост популярности DuckDB. Приятное чтение, хорошо структурированное, без маркетинга и рекламы.
- new DBMSs released in 2024 [2] список на dbdb.io, включает новые 17 СУБД появившиеся в 2024 году. Можно обратить внимание что большая их часть это key/value базы данных создаваемые как альтернативы Redis, после того как Redis сменили лицензию.
- Why AI Progress Is Increasingly Invisible [3] краткое изложение смысла статьи в том что прогресс в ИИ всё более невидим потому что большинство просто не обладает нужными знаниями чтобы его отслеживать (читать научные статьи, следить за бенчмарками и тд.) и то что основные измерения происходят внутри очень крупных создателей LLM и мы узнаем о прогрессе когда продукты уже появляются в доступе.
- The Well [4] два свежих открытых датасета на 15TB и 100TB с изображениями по физической симуляции и астрономии. Объёмы довольно большие и сравнимые с публикацией датасета ImageNet который активно использовался и используется для развития распознавания изображений
- DuckDB vs. coreutils [5] сравнение DuckDB и инструментов grep/awk/wc. Краткий вывод в том что на маленьких серверах DuckDB не в лидерах, а на больших на десктопах скорее да. Добавлю что раньше проскакивали сравнения что быстрее подсчитать число строк CSV файла через wc или DuckDB, и тогда тоже DuckDB выигрывал. Но вот эти тесты посложнее, и разные версии grep и wc существуют
- The Limits of Data [6] а вот это уже серьёзные размышления о том что данные не решают всех проблем и многое что учитывается с регулировании не измеряемо или измеряемо плохо через данные. Иначе говоря не всё можно поместить в дашборды на основе которых писать новые законы. Дискуссия не нова, но автор хорошо систематизировал и изложил ключевые аспекты.
- ORelly Technology Trends 2025 [7] много разных сторон технологий описано, я бы обратил внимание на снижающуюся популярность Java (-13%), Python (-5.3%), рост востребованности Rust (+9.6%) и Data engineering (+29%) и IT сертификация в целом снижается почти по всем направлениям. Тут надо не забывать что эти тренды ORelly считают по данным их обучающей платформы, а то есть выборка сильно меньше чем у похожих обзоров от Github или StackOverflow, но небесполезная в любом случае.

Ссылки:
[1] https://www.cs.cmu.edu/~pavlo/blog/2025/01/2024-databases-retrospective.html
[2] https://dbdb.io/browse?start-year=2024
[3] https://yangx.top.com/7205359/why-ai-progress-is-increasingly-invisible/
[4] https://www.linkedin.com/feed/update/urn:li:activity:7269446402739515393/
[5] https://szarnyasg.org/posts/duckdb-vs-coreutils/
[6] https://issues.org/limits-of-data-nguyen/
[7] https://ae.oreilly.com/l/1009792/2024-12-06/332nf/1009792/1733515474UOvDN6IM/OReilly_Technology_Trends_for_2025.pdf

#databases #datasets #data #dataregulation #trends #readings

В рубрике интересных проектов по работе с данными LOTUS: A semantic query engine for fast and easy LLM-powered data processing [1] движок для обработки данных с помощью LLM поверх Pandas. Принимает на вход человеческим языком описанные конструкции, переводит их в программные операции над датафреймом.

Является демонстрацией работы из научной работы Semantic Operators: A Declarative Model for Rich, AI-based Analytics Over Text Data [2].

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

Если ещё и Pandas заменить на Polars или иную drop-in альтернативу, то ещё и обработка данных приобретёт хорошую скорость и производительность.

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

Ссылки:
[1] https://github.com/guestrin-lab/lotus
[2] https://arxiv.org/abs/2407.11418

#opensource #datatools #dataengineering #data #ai #llm

Сегодня буквально на полчаса была доступна новая версия портала data.gov.ru, но очень быстро снова оказалось закрытой для проведения аттестационных мероприятий.

Даже несколько десятков минут было достаточно чтобы составить впечатление и мне так много что есть сказать об этом, что в короткий формат Telegram канала не уложиться ну никак.

Когда портал "оживёт" я подробно разберу его в рассылке на Substack.

Я ранее там разбирал портал открытых данных Узбекистана, а в телеграм канале писал про особенности портала открытых данных Кыргызстана.

А также несколько раз уже писал про отсутствие портала открытых данных в Казахстане.

Пришла пора и про российский портал рассказать когда (или если?) он оживёт вновь.

#opendata #data #russia #datacatalogs

Про плохие примеры публикации данных, один из давних проектов по открытым данным это платформа Open Data for Africa запущенная в 2011 году [1] Африканским Банком Развития в партнёрстве с компанией Knoema.

С той поры прошло уже 13 лет, практически для каждой африканской страны теперь есть свои порталы на базе этой платформы, например, Либерия [2], Камерун [3], Зимбабве [4] и так далее, их довольно много.

С формальной точки зрения это дата порталы, с каталогами данных, возможностью экспорта данных в CSV, Excel, формат Tableau, с API и так далее. Вроде бы неплохо, но, при этом со множеством недостатков:
1. Объективно это не порталы открытых данных, а порталы статистики, поскольку все опубликованные там данные - это разного рода индикаторы, требующие специальной подготовки перед загрузкой.
2. Поскольку данные там в виде индикаторов, де-факто, их объём очень невелик. По некоторым странам максимум килобайт 10 можно наскрести. Причем слишком часто данные не обновлялись более 10 лет.
3. Многие данные происходят не из стран для которых порталы созданы, а из международных банков данных вроде FAO.
4. У порталов нет удобной выгрузки массовой данных, нужно пройти множество форм чтобы делать экспорт. API плохо документировано, без централизованного описания, нет машиночитаемых каталогов данных и тд.
5. Knoema уже какое-то время не существует как компания, в 2020 году их купили Eldridge [5], а ссылки на их сайте давно неработают, так что и судьбы их платформы мне лично неясна. Больше похоже что её нет, чем то что она есть.

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

При этом почти все африканские страны участвующие в OGP (Open Government Partnership) в своих отчетах пишут что вот мол у нас есть портал открытых данных, посмотрите какой он продвинутый.

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

Ссылки:
[1] https://www.afdb.org/en/news-and-events/afdb-promotes-statistical-development-with-the-launch-of-the-open-data-for-africa-platform-8739
[2] https://liberia.opendataforafrica.org
[3] https://cameroon.opendataforafrica.org
[4] https://zimbabwe.opendataforafrica.org
[5] https://www.businesswire.com/news/home/20201221005152/en/Knoema-Announces-Acquisition-by-Eldridge-and-Partnership-with-Snowflake
[6] https://dateno.io/registry

#opendata #africa #baddata #datacatalogs #data

Отличная лекция A Short Summary of the Last Decades of Data Management [1] от Hannes Mühleisen. Она была на GOTO 2024, а я её увидел только сегодня, большая досада, конечно.

Hannes сооснователь DuckDB и большой специалист в проектировании СУБД рассказывает про последние десятилетия эволюции баз данных.

У него, конечно, своё видение вселенной, но он из тех людей к чьему мнению можно прислушаться.

Выводы у него получаются такие:
- таблицы вечны (чтобы там не придумывали с новыми СУБД, всё всё равно сводится к таблицам)
- NoSQL были плохой идеей. В частности, MongoDB и тут очень хочется с ним поспорить, но, не то чтобы в его словах нет резона. Хотя MongoDB до сих пор очень популярная СУБД.
- Реляционные системы съедают почти всё. В общем то мир по прежнему существует как совокупность систем отношений между объектами, почти всё сводится к ним.
- Большие данные мертвы. Это уже новый/старый тезис, его повторяют часто. И часто он сводится к тому что "большие данные это то что ты не можешь обработать на десктопе". Но сейчас есть инструменты позволяющие обрабатывать на десктопах десятки терабайт с терпимой скоростью.
- DuckDB. Ну тут не без саморекламы у него конечно, но DuckDB реально крутой продукт. Я лично рекомендую всем кто только начинает работать с данными начинать с него.

Повторюсь что лекция замечательная, студентам изучающим базы данных будет очень полезна. Для остальных скорее как расширение кругозора и понимания того как устроен мир эволюции СУБД.

Ссылки:
[1] https://www.youtube.com/watch?v=-wCzn9gKoUk

#data #lectures #databases #rdbms

Полезное чтение про данные, технологии и не только:
- Digitalizing sewage: The politics of producing, sharing, and operationalizing data from wastewater-based surveillance [1] оцифровка канализации и переходу к слежке через анализ сточных вод. Скрыто за пейволом, но тема важная, и активно развивающаяся. Годится для тем рассказов социальной фантастики про то как полиция выявляет убийц расчленителей и наркоманов, а медики больных по анализу сточных вод в реальном времени. Статья за пэйволом
- AI Is Bad News for the Global South [2] статья о том что ИИ для развивающихся стран не несёт ничего хорошего. Потому что английский язык, потому что gig-экономика включает многих из развивающихся стран, а теперь будет ИИ контент.
- The Access to Public Information: A Fundamental Right [3] книга Alejandra Soriano Diaz, о том что доступ к информации - это фундаментальное право и от него зависят другие права. Увы, книга не в открытом доступе,
- Kickstarting Collaborative, AI-Ready Datasets in the Life Sciences with Government-funded Projects [4] статья о том что государство должно активно софинансировать создание данных/датасетов в медицине и других life sciences. Там же ссылка на Open Dataset Initiative [5] создание открытых научных датасетов по запросу сообществ.

Ссылки:
[1] https://journals.sagepub.com/doi/abs/10.1177/23996544241313454
[2] https://foreignpolicy.com/2024/12/17/ai-global-south-inequality/
[3] https://www.cambridgescholars.com/product/978-1-0364-1521-1
[4] https://fas.org/publication/collaborative-datasets-life-sciences/
[5] https://alignbio.org/datasets-in-detail

#opendata #data #foi #readings #ai

По итогам вчерашней лекции зафиксирую ключевые тезисы о которых я пишу тут давно, но фрагментировано:

1. Формат Apache Parquet позволяет публиковать текущие крупные датасеты в виде пригодном для немедленной работы аналитиков, меньшего объёма и с лучшей структурой (типизацией содержимого). Это уже давний стандартизированный формат публикации данных пришедший из стека Apache и набравший популярность по мере роста популярности data science.

2. Apache Parquet не единственный такой формат, но один из наиболее популярных в последнее время. Он поддерживается почти всеми современными аналитическими инструментами работы с дата фреймами и аналитическими базами данных. Кроме него есть ещё и такие форматы публикации как ORC, Avro, значительно менее популярные, пока что.

3. В формате Apache Parquet уже публикуются данные раскрываемые госорганами. Его использует статслужба Малайзии, Правительство Франции, разработчики порталов открытых данных OpenDataSoft и многочисленные исследователи по всему миру. Почему они так делают? Потому что получают запрос от аналитиков, потому что это снижает стоимость хранения и обработки данных.

4. DuckDB - это один из наиболее ярких примеров стремительного удешевления работы с данными большого объёма на настольных компьютерах. Значимость его как инструмента именно в том что появляется возможность работы с данными условно в сотни гигабайт на недорогих устройствах. Например, работа с данными в сотни гигабайт на железе стоимостью до $1000.

5. Производительность DuckDB стремительно растёт. Рост от 3 до 25 раз для разных запросов и поддержка данных до 10 раз большего размера и это за 3 года с 2022 по 2024. Поэтому, хотя у DuckDB есть альтернативы - chDB, движки для дата фреймов такие как Polars, но важен потенциал развития.

6. Почему это важно для исследователей? У рядовых исследовательских команд не всегда есть возможность развертывания "тяжёлой инфраструктуры" или привлекать профессиональных дата аналитиков и дата инженеров. Чаще приходится работать на десктопах и не самых дорогих.

7. Почему это важно при публикации данных? Рассмотрим случай когда госорган, в нашем случае, Минкультуры РФ публикует каталог музейного фонда у себя на портале открытых данных. Сейчас это 11GB ZIP файл, разворачивающийся в 78GB файл в формате JSONS (на самом деле это NDJSON/JSON lines, из построчных записей в JSON). С этими данными всё ещё можно работать на десктопе, но пока скачаешь, пока распакуешь, это будет трудоёмко. Если бы Министерство сразу публиковало бы этот и другие датасеты в Parquet, то итоговый размер датасета был бы 2.7GB и работать с ним можно было бы немедленно, быстрее и удобнее.

8. Технологии дата инженерии и аналитики стремительно развиваются. Отстать можно очень быстро, например, многие только-только узнают про инструменты для дата фреймов вроде Pandas, а в то же время Pandas уже рассматривается как легаси потому что Pandas почти перестал развиваться, а заменяющие его движки Polars или Dask показывают значительно лучшую производительность.

9. Высокая конкуренция среди команд разработчиков СУБД. За ней можно наблюдать, например, через рейтинги производительности ClickBench где если не все то большая часть аналитических СУБД и через каталог СУБД в мире DBDB. Прямо сейчас происходящее называют золотым веком баз данных [и дата инженерии]. Причём развитие идёт в сторону повышения производительности на текущем оборудовании. А это значит что в ближайшем будущем будет ещё больший прогресс в том чтобы работать с данными большого объёма на недорогом оборудовании.

#opendata #opensource #datatools #data

Полезное чтение про данные, технологии и не только:
- TPC-H SF300 on a Raspberry Pi [1] бенчмарк TPC-H SF300 для DuckDB на Raspberri Pi с 16 GB RAM и 1TB SSD. TPC-H тест на двух базах в 26GB и 78GB. Самое главное, все стоимость всего всего этого железа $281.
- BuzzHouse: Bridging the database fuzzing gap for testing ClickHouse [2] в блоге ClickHouse об автоматизации тестирования запросов к ClickHouse. Автор создал и оформил 100+ issues выявленных таким автоматическим тестированием.
- Öppna data-portalen [3] портал открытых данных Шведского национального совета по культурному наследию. Все они геоданные в открытых форматах для возможности нанесения на карту.
- Pilot NIH Science of Science Scholars Program [4] национальный институт здравоохранения США запустил программу для исследователей по работе с их внутренними данными. Это те данные которые не могут быть открыты, но доступны с соблюдением требований безопасности, приватности, с оборудования предоставленного государством и тд. Ограничений немало, но и данные из тех что относят к особо чувствительным.
- LINDAS [5] официальный государственный портал связанных данных (Linked Data) Швейцарии. Создан и поддерживается Швейцарскими Федеральными Архивами. Включает 133 набора данных/базы данных
- Visualize Swiss Open Government Data [6] Швейцарская государственная платформа для визуализации данных. Да, по сути это как если бы к Datawrapper прикрутили каталог данных и придали бы всему государственный статус. Наборов данных там около 200 и, самое главное, всё с открытым кодом [6]

Ссылки:
[1] https://duckdb.org/2025/01/17/raspberryi-pi-tpch.html
[2] https://clickhouse.com/blog/buzzhouse-bridging-the-database-fuzzing-gap-for-testing-clickhouse
[3] https://www.raa.se/hitta-information/oppna-data/oppna-data-portal/
[4] https://dpcpsi.nih.gov/oepr/pilot-nih-science-science-scholars-program
[5] https://lindas.admin.ch/
[6] https://github.com/visualize-admin

#opendata #opensource #data #rdmbs #datatools

Свежий документ Data Governance in Open Source AI [1] от Open Source Initiative про то как публиковать данные для обучения ИИ с открытым кодом. В документе много всего, важно что они промоутируют отход от чистого определения Open Data и говорят о новом (старом) подходе Data Commons с разными моделями доступа к данным.

Дословно в тексте упоминаются, привожу как есть:
- Open data: data that is freely accessible, usable and shareable without restrictions, typically
under an open license or in the Public Domain36 (for example, OpenStreetMap data);
• Public data: data that is accessible to anyone without authentication or special permissions
(for example, Common Crawl data). Note that this data can degrade as web content
becomes unavailable;
• Obtainable data: data that can be obtained or acquired through specific actions, such as
licensing deals, subscriptions or permissions (for example, ImageNet data);
• Unshareable non-public data: data that is confidential or protected by privacy laws,
agreements or proprietary rights and cannot be legally shared or publicly distributed.

С точки зрения многих в открытых данных всё это звучит как размывание открытости, но с точки зрения практики ИИ в этом есть логика.

Ссылки:
[1] https://opensource.org/blog/reimagining-data-for-open-source-ai-a-call-to-action

#opendata #data #readings

Полезное чтение про данные, технологии и не только:
- Chart Smarter, Not Harder: Plotly Now Offers Universal DataFrame Support [1] о том как разработчики движка визуализации Plotly многократно ускорили визуализацию графиков используя библиотеку Narwhals поверх Polars и pyArrow. Познавательные цифры и опыт для тех кто сталкивается с медленной отрисовкой графиков.
- Siyuan [2] персональная система управления знаниями и заметками. Китайский аналог Notion и Obsidian. Открытый код под AGPL, бесплатно для личного использования. Много интеграции в китайскую экосистему вроде WeChat и тд
- Requestly [3] расширение для браузера, прокси, для перехвата запросов. Необходимо всем разработчикам работающим с API. Открытый код под AGPL и онлайн сервис за деньги. По сути конкурент Postman
- Maxun [4] ещё один no-code инструмент для скрейпинга сайтов. Облегчает жизнь тем кто не хочет кодировать то что можно не кодировать. Открытый код, AGPL
- VeilStream [5] для разнообразия не вполне обычный коммерческий сервис, прокси для PostgreSQL который принимает запросы от пользователей, а ответы отдаёт отфильтрованными от персональных данных. Меня не покидает ощущение что это несколько, ммм, извращённое решение, но тем не менее. Оно есть и, видимо, кто-то его покупает.
- 10 Ways to Work with Large Files in Python: Effortlessly Handle Gigabytes of Data! [6] статья полностью для джунов, но именно джунам её прочитать обязательно. Там есть небольшая реклама Dask и игнорирование Polars, DuckDB и тд. А если говорить серьёзно, то всё зависит от того какие у тебя большие данные, в каком они состоянии и что с ними планируется делать. К примеру, обработка десятков и сотен гигабайт бинарных данных происходит иначе.
- Python Rgonomics 2025 [7] материал о том как работать в Python тем кто учил R. Полезное чтение для тех кто живёт в двух мирах или переходит с R на Python.

Ссылки:
[1] https://plotly.com/blog/chart-smarter-not-harder-universal-dataframe-support/
[2] https://github.com/siyuan-note/siyuan
[3] https://github.com/requestly/requestly
[4] https://github.com/getmaxun/maxun
[5] https://www.veilstream.com/
[6] https://blog.devgenius.io/10-ways-to-work-with-large-files-in-python-effortlessly-handle-gigabytes-of-data-aeef19bc0429
[7] https://www.emilyriederer.com/post/py-rgo-2025/

#readings #opensource #data #datatools