Я ранее много раз упоминал стандарт публикации Frictionless Data [1] созданный командой Rufus Pollock, основателя Open Knowledge Foundation. Это стандарт контейнера для обмена данными и включающего специальный манифест с описанием состава данных. Самое очевидное и декларируемое его применение - это распространение данных в форматах CSV при которых в манифесте указаны параметры для открытия такого файла.

Идея эта не новая, например, библиотека конгресса США когда-то разработала стандарт Bagit [2] для обмена архивными данными. Но важным достоинством именно Frictionless Data является возможность расширения и создания своих стандартов на его основе. Так появился стандарт WACZ [3] для публикации веб-архивы внутри ZIP контейнера.

Веб архивы - это слепки сайтов создаваемые краулерами, такими как Internet Archive. Они создаются в международном стандарте WARC, а их метаданные в формате CDX, у которых есть множество достоинств и важный недостаток - они довольно сильно устарели. С метаданными есть потребность работать в машиночитаемом виде, сразу в JSON, а WARC файлы держать сжатыми, отсюда и появилась эта спецификация.

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

У нас в Национальном цифровом архиве пока используется только формат WARC для архивации сайтов и складывание файлов в ZIP архивы для архивации API и каталогов данных. Так вот у WARC главное достоинство - это некоторая, хоть и не самая большая, но экосистема и совместимость в виде статуса стандарта и множество недостатков таких как: плохое сжатие файлов, поддержка инструментами только сжатия в форматах .warc.gz (GZIP плохо жмёт и вообще и такие данные), отсутствие встроенного механизма индекса содержания или поддержка внешних индексов и, в целом, возможность быстрой навигации с разделением метаданных и содержания - сейчас в WARC файле хранятся одновременно заголовки файлов и сами данные, в результате надо листать весь архив.

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

Ссылки:
[1] https://frictionlessdata.io
[2] https://datatracker.ietf.org/doc/html/draft-kunze-bagit
[3] https://webrecorder.github.io/wacz-spec/1.2.0/

#opendata #datastandards

В блоге Fivetran весьма интересные размышления [1] о популярности dbt, инструмента по преобразованию данных с помощью SQL, с акцентом на то что dbt решает одну из главных системных проблем SQL - невозможность использования библиотек и шаблонов. В dbt это решается через их менеджер пакетов куда входят многочисленные рецепты работы с данными.

Авторы также ссылаются на статью середины прошлого года Against SQL [3] где как раз проблемы SQL четко актикулировались.

Я, кстати, также совершенно не в восторге от языка SQL, слишком много разных реализаций значительно меняющих/расширяющих SQL стандарт и сам по себе текст стандарта SQL 2016 составляет 1732 страницы. В целом то критика в адрес SQL идёт давно, многие NoSQL продукты появлялись как раз как замена SQL и, по ощущениям, как раз с появлением dbt происходит какое-то экспоненциальное перерождение подходов к работу с этим языком.

Ссылки:
[1] https://www.fivetran.com/blog/can-sql-be-a-library-language
[2] https://hub.getdbt.com/
[3] https://www.scattered-thoughts.net/writing/against-sql
[4] https://blog.ansi.org/2018/10/sql-standard-iso-iec-9075-2016-ansi-x3-135/

#reading #sql #data

Свежее европейское исследование Study on mapping data flows [1] о том как корпоративные данные хостятся и передаются в странах Европы. Используют данные Евростата, ITU и Cisco, а по итогам публикуют визуализацию на карте ЕС [2].

Визуализация, если честно, так себе, а вот исследование полезно для понимания в каких странах ЕС идёт рост строительства ЦОДов и развития облачных сервисов, а в каких их скорее нет. В лидерах, конечно, Германия, но там немало и других инсайтов.

Ссылки:
[1] https://digital-strategy.ec.europa.eu/en/library/study-mapping-data-flows
[2] https://digital-strategy.ec.europa.eu/en/policies/european-data-flow-monitoring

#data #datalofw #europe #policy #research

Voltron Data, стартап со-основанный создателем Apache Arrow, Wes McKinney, привлек $110M инвестиций [1]. Подробности стартапа не раскрывают, но он точно будет основан на базе Apache Arrow и ориентирован на обработку больших объёмов данных и, учитывая что в основателях как минимум 2 человека вовлечённых в создание продуктов на данных использующих графические процессоры [2], почти наверняка в нем будет что-то с оптимизацией обработки данных с помощью GPU.

Ссылки:
[1] https://techcrunch.com/2022/02/17/voltron-data-grabs-110m-to-build-startup-based-on-apache-arrow-project/
[2] https://voltrondata.com/news/fundinglaunch/

#startups #data #opensource

Культура работы с данными, она в немелочных мелочах. Её иногда можно понять по тому в каких форматах публикуются данные или по тому насколько полно заполнено представляемые данные и как оперативно они обновляются, но то что значительно сложнее проверить и требует отраслевых знаний - это то _чего нет в опубликованных данных_, но что необходимо для аналитического и практического применения данных.
Например, во Франции Национальный институт здоровья публикует не только суммы грантов на исследования, но и ФИО основного исследователя и его ORCID [1].

Почему это важно? Потому что ORCID, в отличие от ФИО, позволяет однозначно идентифицировать человека.
А многие данные внутри государственных и муниципальных систем уже линкуют с OSM, Geonames и Wikidata. Например, Территории с надписью " Город и страна искусства и истории» региона Ile de France [2].

Если посмотреть на европейские госданные то в них много интеграции с международными авторитетными источниками. Не только с Wikidata, но и с WorldCat и др. гораздо больше ссылок на международные справочники и гораздо больше данных. Например, только данных в портале агрегаторе data.opendatasoft.com, аккумулирующего данные публикуемые органами власти Франции, около 1ТБ данных и это по предварительной оценки выкачки 75% наборов данных с этого портала.

Ссылки:
[1] https://nihr.opendatasoft.com/.../nihr-summary.../table/...
[2] https://data.iledefrance.fr/explore/dataset/vpah_idf/table/

#opendata #data #dataportals

О том как устроена классификация данных, семантические типы, бизнес глоссарии у меня накопилось уже на большой лонгрид. Типизация данных сильно заточена под их понимание.

Пока вот такая картинка/схема того как будет устроен реестр идентификаторов/сементических типов Metacrafter registry [1].

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

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

Ссылки:
[1] https://github.com/apicrafter/metacrafter-registry

#data #reading #dataunderstanding

Для тех кто работает с данными и кому нужно регулярно кто-либо архивировать из социальных сетей, продвинутый инструмент для этой задачи - snscrape [1]. Поддерживает Faceboo, VK, Twitter, Instagram, Reddit и ещё много чего. Лучше всего архивирует данные твиттера.

Когда надо сохранить/регулярно сохранять чьи-то социальные сети - вещь незаменимая.

Работает с командной строки, написан на языке Python.

Ссылки:
[1] https://github.com/JustAnotherArchivist/snscrape

#datatools #opensource #digitalpreservation

В блоге Pinterest история про то как они выбирали и в итоге настроили оркестратор задач на базе Airflow [1]. Пост интересный, про сложную архитектуру, реально большие данные, сложные процессы и тд.

А также там же много интересных цифр про Pinterest:
- 500 петабайт данных всего
- 600 терабайт данных ежесуточно
- 4000 workflows
- 10 000 data flows
- 38 000 ежесуточных задач в среднем

Достоинство больших проектов и крупных команд как раз в таких масштабах и решениях возникающих от сложностей подобного объема данных.

А в случае Pinterest'а ещё и интересна их архитектура связки потоков данных, развертывания кода и кластеров Kubernetes.

Ссылки:
[1] https://medium.com/pinterest-engineering/spinner-pinterests-workflow-platform-c5bbe190ba5

#opensource #bigdata #datarchitecture #datapipelines

В рубрике большие наборы открытых данных открытые данные о химических элементах, формулах, веществах и тд.

- PubChem [1] одна из крупнейших в мире баз данных по химическим веществам с параметрами веществ и идентификаторами и описаниями из десятков источников данных. Несколько десятков гигабайт архивов экспортированных в XML файлов.
-HMDB [2] The Human Metabolome Database (HMDB) - база молекул метаболитов в человеческом теле. Общий объём, включая спектральные данные, более 20GB архива с XML файлами
- MassBank Europe [3] база спектральных масс высокого качества. Данных относительно немного, сотни мегабайт выложенных на Github

А также многие другие. В PubChem перечислено 844 источника данных [4] многие из которых включают полные дампы открытых данных.

Ссылки:
[1] https://pubchemdocs.ncbi.nlm.nih.gov/downloads
[2] https://hmdb.ca/downloads
[3] https://massbank.eu/MassBank/
[4] https://pubchem.ncbi.nlm.nih.gov/sources

#opendata #chemistry #openaccess #data #datasets

Для всех кто учится работать с данными и работать с SQL я рекомендую сразу начинать изучать dbt, например, по ссылкам из awesome-dbt [1] и начиная с бесплатного официального курса [2]. Пройдёт год-два максимум и dbt в России начнут повсеместно использовать, а для работы инженера-аналитика (analytics engineer) дистанционно на проект/компанию в любой стране - это будет одна из наиболее востребованных технологий.

Почему dbt? Потому что пока это наиболее развитый инструмент преобразования данных. Если в областях ETL/ELT, data orchestration, data visualization, BI и других есть масштабная конкуренция и авторы и создатели проектов регулярно пишут о том как заменить одно на другое или как отказаться от чего-либо, например, как отказаться от Airflow [3], то про dbt все пишут только о том как они заменили свои механизмы трансформации данных на dbt.

Продукт получился просто таки попаданием в яблочко, в России он мало применяется только по причине малой применимости тут других зарубежных облачных продуктов. Но важная особенность dbt что он, и облачный, и как изначальный open source продукт.

Ссылки:
[1] https://github.com/Hiflylabs/awesome-dbt
[2] https://courses.getdbt.com/collections
[3] https://blog.fal.ai/the-unbundling-of-airflow-2/

#datatools #studies #learning #sql #dbt

По итогам просмотра многих тех материалов ГосТех'а что были в открытом доступе я, пожалуй, могу сформулировать ряд конкретных проблем связанных не только с ним самим, но скорее с тем кто ставит/должен ставить задачи той команде которая им занимается:

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

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

- "непонимание" принципов разделения власти. Если вчитаться в Конституцию РФ то там четко расписано разделение полномочий между федеральными, региональными и муниципальными властями. При этом в России последние лет 15 как минимум, а может и дольше уже идёт ползучая технологическая унитаризация, когда федеральные власти создают информационные системы с которыми обязаны работать региональные и муниципальные власти. Всё что сейчас рассказывается в Гостех и сама идея Гостеха активно продолжается в этом направлении.

- усиление цифрового патернализма. Это вопрос уже не глупости или незнания, это вопрос идеологии. Гостех продолжается в форме услуг для граждан где в восприятии его авторов граждане - это такие ранимые субъекты государственной опеки о которых надо заботиться, холить и лелеять, по крайней мере в публичной риторике. В этом смысле Гостех мало отличается от Госуслуг, основная идея выморачивании услуг гражданам только к услугам по жизненным ситуациям, а каналы обратной связи только к жалобам. Эта модель не предполагает существования активных граждан или НКО или, даже, бизнеса взаимодействующего с органами власти в части их работы. Граждане только получают то что лица принимающие решения считают для них важным.

- отказ от усиления граждан. Вот это такой важный, а кто-то скажет что политический момент, идущий в сочетании с усилением цифрового патернализма. Усиление гражданина - это снижение информационного неравенства между ним и более сильным контрагентом. Например, для усиления гражданина как потребителя ЦБ РФ требует от банков и других финансовых организаций раскрывать довольно много информации о себе. Помогает это в финансовой грамотности? Да, помогает. А вот при госинформатизации нет требований к органам власти раскрывать сведения о том как информационные системы работают, какие данные там содержатся и многое другое. Гостех в этом смысле ничем не отличается. Несмотря на декларируемое развитие "цифрового правительства", из международного термина взяты лишь госуслуги, а большая прозрачность, открытые данные, открытые данные по умолчанию и т.д. просто игнорируются.

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


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


#government #govtech #technology #data #transparency

Одна из этически спорных тем вокруг автоматизированных алгоритмов - это персонализированные цены, когда компания/сервис предоставляют конкретному пользователю цену за услугу или продукт и эта цена формируется, в том числе, на основе информации о пользователе. Это нельзя назвать алгоритмами ИИ, но это очень близко к алгоритмам скоринга по смыслу и реализации.

Mozilla и Consumers International с мая по сентябрь 2021 года проводили исследование персонализированных цен в Tinder и выяснили что в сервисе средняя цена за Tinder Plus имеет вариации в зависимости от возраста, пола и местонахождения клиента. В исследовании [1] подробно разобрано какие критерии алгоритм использует и страны в которых оно проводилось: США, Бразилия, Нидерланды, Республика Корея, Индия, Новая Зеландия.

По итогам исследователи предлагают подписать петицию [2] и усилить регулирование за подобными сервисами.

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

Ссылки:
[1] https://assets.mofoprod.net/network/documents/Personalized_Pricing.pdf
[2] https://foundation.mozilla.org/en/blog/new-research-tinders-opaque-unfair-pricing-algorithm-can-charge-users-up-to-five-times-more-for-same-service/

#privacy #data #bigdata #ai #algorithms #mozilla

Должны ли историки программировать? А писатели или литературные критики? В мире довольно многое происходит в направлениях Digital Humanities и Computational Humanities, Цифровых гуманитарных наук.

В последние годы быть гуманитарием не означает что нельзя быть программистом, например, такие проекты как Programming Historian [1] помогает историкам использовать инструменты для работы с данными, подключаться к цифровым онлайн библиотекам через API, развертывать продукты по визуализации исторических данных, анализировать и распознавать тексты и многое другое.

Многие публикуют результаты своих работ как открытый код или исполнимые статьи (executable papers), например, статья Forgotten Books [2] о выживании культуры.

Digital Humanities есть и в России, есть несколько университетов с этими направлениями в обучении.

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

Например, Росархив публикует исключительно административные данные [3] которые никому не нужны и не публикует даже реестры архивного фонда. А самое главное что ведомство даже не пытается выступать регулятором обеспечивающим открытость подведомственных ему государственных архивов.

Министерство культуры в России до сих пор лидер по открытию данных [4], но все мы тревожимся как долго это сохранится, учитывая смену руководства и отсутствие планов по будущему открытию данных.

Но данных много, их много в частных, общественных проектах, много в открытом доступе и возможность делать интересные проекты в этой области в России есть. Главное желание и немного технических навыков.

Ссылки:
[1] https://programminghistorian.org/
[2] https://forgotten-books.netlify.app
[3] https://archives.gov.ru/opendata
[4] http://opendata.mkrf.ru/

#opendata #digitalhumanities

В Румынии приняли закон об открытии данных [1] в котором реализуют директиву Евросоюза (EU) 2019/1024. При том что в стране уже публикуется более 2600+ наборов данных на национальном портале открытых данных [2], теперь можно ожидать что данных будет больше.

Напомню что открытые данные Евросоюза агрегируются на портале data.europa.eu [3] и там уже почти 1.4 миллиона наборов данных, из которых не менее 3/4 - это геоданные в форматах WFS и WMS.

Ссылки:
[1] https://www.thediplomat.ro/2022/01/27/romanian-government-approved-the-law-on-open-data-and-reuse-of-public-sector-information-initiated-by-adr-and-mcid/
[2] https://data.gov.ro
[3] https://data.europa.eu/en

#opendata #datasets #eu #romania

Полезная подборка чтения про данные на ближайшие дни, про разное:
- 10 Hot 🔥 Data & Analytics Trends to Watch in 2022 [1] в блоге Count, о том какие тренды идут в аналитической инженерии.
- Open Archaeo [2] проект открытая археология включая открытые данные, открытый код, стандарты, руководства и протоколы работы
- The Battle for Data Engineer’s Favorite Programming Language Is Not Over Yet [3] дискуссионная статья о будущем языка программирования Rust как языка для инженеров данных
- Data diffs: Algorithms for explaining what changed in a dataset [4] статья об алгоритмах отслеживания изменений в наборах данных
- Building Python Microservices with Apache Kafka: All Gain, No Pain [5] глубоко технологическая заметка о том как делать API с помощью Python и Kafka.
- Easy data processing at scale with Optimus [6] ещё одна очень технологическая заметка о движке Optimus для Python, заменяющий Pandas и включающие многие доп возможности, например, всё то же определение семантических типов данных. В упрощённом варианте, конечно, но есть такое.
- Inside Pornhub [7] нетехническое и познавательное чтение о внутреннем устройстве PornHub'а. Побольше бы таких о крупных/интересных компаниях

Ссылки:
[1] https://blog.count.co/how-data-analytics-will-change-in-2022/
[2] https://open-archaeo.info
[3] https://betterprogramming.pub/the-battle-for-data-engineers-favorite-programming-language-is-not-over-yet-bb3cd07b14a0
[4] https://blog.marcua.net/2022/02/20/data-diffs-algorithms-for-explaining-what-changed-in-a-dataset.html
[5] https://medium.com/towards-data-science/building-python-microservices-with-apache-kafka-all-gain-no-pain-1435836a3054
[6] https://medium.com/@argenisleon/easy-data-processing-at-scale-with-optimus-f467f867d756
[7] https://www.theverge.com/c/22925906/pornhub-mindgeek-content-moderation

#data #datascience #readings #opendata

В блоге Meta пишут о том что компания строит свой переводчик реального времени с использованием ИИ [1] и обещают поддерживать много языков и хорошее качество перевода, но не указывают сроки. Тут сложно не вспомнить что похожие технологии появляются и у других компаний, например, в Microsoft Skype уже довольно давно умеет переводить между 40 языками.

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


Ссылки:
[1] https://ai.facebook.com/blog/teaching-ai-to-translate-100s-of-spoken-and-written-languages-in-real-time

#ai #translation #data

Дорогие друзья,

В этом году мы традиционно планировали провести День открытых данных. Начавшееся с митапов в 2012 году, это мероприятие выросло в важную площадку для диалога между сообществом пользователей открытых данных, НКО, представителями бизнеса и органами государственной власти, а также стало частью международного движения открытости.

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

Мы откладываем проведение этого мероприятия на неопределенный срок, но остаемся приверженцами открытости, и постараемся предложить сообществу другие возможности для общения и обсуждения важных вопросов в дальнейшем.

Спасибо всем, кто поддерживает нас, и до будущих встреч!

Оргкомитет «Дня открытых данных»

dbt Labs привлекли рекордные $222M инвестиций [1] при общей оценке в $4.2B (миллиардов долларов США) на свой продукт dbt Cloud. Сумма очень большая, но совершенно не удивительно что это произошло. Я ранее писал о том что dbt в каком-то смысле уникальный продукт давший второе рождение SQL. Если ранее каждый продукт по сбору или оркестрации данных обеспечивал самостоятельные механизмы их преобразования, то сейчас многие заменяют или подключают dbt под эти задачи. Фактически dbt становится индустриальным стандартом де-факто, действительно не так много альтернатив пригодных к немедленной промышленной эксплуатации.

Главный же недостаток dbt в "убийстве NoSQL". Многие продукты которые подчеркивали свои NoSQL языки запросов сейчас оказываются периферийными, находящимися за пределами Modern Data Stack или же определяемые как унаследованные базы данных, за пределами основных операционных процессов.

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

Ссылки:
[1] https://blog.getdbt.com/next-layer-of-the-modern-data-stack/

#moderndatastack #startups #data #dbt