Стартапы по работе с данными о которых мало кто знает

Hanzo [1] компания с изначальной специализацией на ведении корпоративных веб-архивов с акцентом на рынок complience, регуляторных требований, в первую очередь от SEC и FINRA, финансовых регуляторов. Кроме архивов специализируются на архивации данных из корпоративных систем коммуникации и совместной работы таких как Slack и Google Workspace. В целом этот рынок называется eDiscovery. Привлекли венчурных инвестиций на $3.3M

Open Data Blend [2] проект частной компании NumbleLearn по представлению аналитики по фармацевтическому рынку в Великобритании. Используют данные о рецептах публикуемые Агентством здравоохранения Великобритании и предоставляют рынку подробные инсайты и иные формы представления понимания этого рынка. Сведений о инвестициях в них нет, но похоже что проект живой и приносит деньги.

Ссылки:
[1] https://www.hanzo.co
[2] https://www.opendatablend.io/

#opendata #data #startups

Я ранее много раз упоминал стандарт публикации 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