Ivan Begtin
7.99K subscribers
1.82K photos
3 videos
101 files
4.53K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and other gov related and tech stuff.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Secure contacts ivan@begtin.tech
Download Telegram
В рубрике стартапов на данных и связанных с данными

- CloudQuery [1] сервис инвентаризации облачных активов. Это когда у вас серверов и других сервисов много, а управлять ими уже сложно ну или надо хотя бы знать где что находится. Также есть в открытом коде [2]. Подняли $15M инвестиций 22 июня [3]

- Avo [4] система управления аналитикой и прослеживаемостью пользователей. Подняли $5M в 5 раундов, последний раунд в сентябре 2020 г. Дают удобный интерфейс для отслеживания каждого пользователя и с интеграцией с RudderStack, Segment, Posthog и другими инструментами.

- Y42 [5] платформа управления данными с претензией на полный цикл охвата: интеграция, моделирование, визуализация и оркестрация. Всего подняли 33.9M в 2 раунда. Последний раунд в октябре 2021 г.

- Castor [6], стартап по каталогизации данных, получил инвестиций в объёме $23.5M в начале июня [7]. В основном делают акцент на большей понимаемости данных, удобном интерфейсе каталога и тд.

- Immuta [8] разработчики платформы по защите данных с функциями обнаружения чувствительных данных подняли раунд E на $100M [9] инвестиций. Это корпоративный каталог с акцентом на интеграцию со всеми крупнейшими облачными базами данных Snowflake, RedShift, BigQuery и тд. Общий объём привлеченных ими инвестиций $276M

Ссылки:
[1] https://www.cloudquery.io/
[2] https://github.com/cloudquery/cloudquery
[3] https://www.cloudquery.io/blog/cloudquery-raises-15m-series-a
[4] https://www.avo.app/
[5] https://www.y42.com/
[6] https://www.castordoc.com/
[7] https://techcrunch.com/2022/06/07/castor-a-data-catalog-startup-nabs-23-5m-to-expand-its-platform/
[8] https://www.immuta.com
[9] https://www.immuta.com/articles/series-e-funding-announcement/

#startups #data #itmarket
В качестве регулярного напоминания проект по созданию каталога каталогов данных DataCatalogs [1] созданный командой @infoculture.

В нем собрано описание 263 каталогов данных всех типов и категорий: открытых, закрытых, государственных, общественных, частных и тд., сгруппированных по 115 темам.

Этот сайт создан поверх базы в Airtable которую мы ведем в Инфокультуре и можно предложить туда каталог данных через форму на сайте [2].

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

Из незавершённого:
- нет экспорта каталога в открытые данные и выкладкой на сайте или в Github. Проще всего через Github Actions скорее всего
- нет автоматизированного пополнения Awesome Opendata Russia [3], списка ссылок на порталы и ресурсы по открытым данным в России.

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

Ссылки:
[1] https://datacatalogs.ru
[2] https://www.datacatalogs.ru/add-resource
[3] https://github.com/infoculture/awesome-opendata-rus

#opendata #russia #datasets #datacatalogs
YaLM 100B [1] GPT-подобная нейросеть для обработки и создания текста. Доступна под лицензией Apache 2.0 и вчера выложена командой Яндекса на Github.

Авторы заявляют 100 миллиардов параметров, отсюда 100B в названии, и то что модель создавалась на основе 1.7 ТБ текстов и рассчитывалась 65 дней на кластере из 800 видеокарт A100.

Подробнее в статье в Medium [2] и на Habr [3].

Ссылки:
[1] https://github.com/yandex/YaLM-100B
[2] https://medium.com/yandex/yandex-publishes-yalm-100b-its-the-largest-gpt-like-neural-network-in-open-source-d1df53d0e9a6
[3] https://habr.com/ru/company/yandex/blog/672396/

#datasets #gpt #neuralnetworks #ai
Продолжается кампания по архивации российских сайтов СМИ, медиа и культурных инициатив

Веб-архивы сайтов доступны для скачивания в формате WARC и открываются в приложении ReplayWeb.page.

Сведения о планах архивации и сохраненных ресурсах доступны в открытой таблице.

Если вы знаете, какой сайт может стать утерянным, сообщите нам об этом с помощью специальной формы.

В это же время в Великобритании в национальной библиотеке проходит выставка «Breaking the News», для которой используются сохраненные новости из веб-архива Великобритании (UKWA). Коллекция «Новости» в UKWA содержит веб-архивы более 2700 новостных сайтов. Туда входят крупные национальные новостные издания — BBC, Guardian, Daily Mail и т.д. Помимо этого собираются веб-архивы тысячи местных новостных сайтов, посвященных жизни отдельных городов и деревень.

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

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

Когда речь заходит об архивации на системном уровне то возникает вопрос стандартов и универсальных спецификаций. А их и то оказывается не так много. У библиотеки Конгресса США есть коллекция форматов рассматриваемых для архивации табличных данных/баз данных [1]․

Почти все они - это форматы обмена данными, такие как XML, JSON, CSV, HDF, CDF, XLS и тд. Рекомендуемыми форматами для данных при этом являются CSV/TSV и SQLite [2].

А вот в Швейцарии разработали и приняли ещё в 2013 году стандарт SIARD, его описание также есть в библиотеке Конгресса [3]. Этот стандарт описывает унифицированный экспорт баз данных не только с точки зрения данных, но и всех связанных объектов, понятий, артефактов и метаданных. Стандарт не самый древний, но ограниченный с самого начала такими СУБД как Oracle, Microsoft SQL Server, MySQL, IBM DB2, Microsoft Access. Тут не то что NoSQL нет, но и нет поддержки облачных СУБД, нет многих популярных баз данных и не только. А сам стандарт с 2015 года практически не развивался.

Что характерно, других универсальных стандартов экспорта/импорта СУБД не существует. Что иногда кажется странным, поскольку в ИТ очень любят разрабатывать собственные спецификации. Например, в Modern Data Stack уже есть множество стандартов описания метаданных в СУБД таких как OpenMetadata [4] и OpenLineage [5] которые довольно сильно пересекаются с SIARD в части метаданных описывающих данные, но не заходят в область непосредственно сохранения контента.

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

Ссылки:
[1] https://www.loc.gov/preservation/digital/formats/fdd/dataset_fdd.shtml
[2] https://www.loc.gov/preservation/resources/rfs/data.html
[3] https://www.loc.gov/preservation/digital/formats/fdd/fdd000426.shtml
[4] https://docs.open-metadata.org/metadata-standard/schemas
[5] https://github.com/OpenLineage/OpenLineage

#databases #digitalpreservation
В рубрике интересных наборов данных, VizNet [1], четыре корпуса данных Plotly, ManyEyes, Webtables, Open data portal, собранных из этих источников. По сути VizNet содержит большой срез данных высокого качества из открытого доступа и позволяет проводить исследования по визуализации, анализу, аннотированию и машинному обучению на данных.

Проект создан внутри MIT Media Labs и, например, используется в системе Sherlock [2] для идентификации семантических типов данных.

Ссылки:
[1] https://github.com/mitmedialab/viznet
[2] https://github.com/mitmedialab/sherlock-project

#opendata #datasets
Postman опубликовали обновление API Platform Landscape [1] с перечнем продуктов и трендов в мире API.

Ключевые тезисы оттуда:
1. Компании переходят к модели API-first
2. Гибридная архитектура и многооблачность
3. API как продукт
4. Взрывной рост продуктов API Gateway
5. Всё больше протоколов для API в активном использовании.
6. Всё больший сдвиг в сторону безопасности доступа к API.

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


Ссылки:
[1] https://blog.postman.com/2022-api-platform-landscape-trends-and-challenges/

#api
Из важного, Microsoft серьёзно пересматривают подход к этике ИИ, о чём пишут у себя в блоге [1], а также анонсируют вторую версию стандарта ответственного ИИ [2].

В контексте этого стандарта они закрыли для доступа их API распознавания лиц и эмоций [3] и это, также, весьма важный шаг саморегулирования ответственности корпораций.

И здесь я не могу не кинуть камень в огород российского кодекса этики ИИ [4] и важной разнице между ним и то в каком направлении сейчас движутся международные корпорации вроде Microsoft.

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

В стандарте Microsoft и иных подобных документах декларируется позиция корпорации которая и предполагается как будущая основа для законов.

Поэтому стандарт Microsoft будет иметь влияние на нашу с Вами жизнь, а российский кодекс этики ИИ не будет.

Ссылки:
[1] https://blogs.microsoft.com/on-the-issues/2022/06/21/microsofts-framework-for-building-ai-systems-responsibly/
[2] https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf
[3] https://www.theverge.com/2022/6/21/23177016/microsoft-retires-emotion-recognition-azure-ai-tool-api
[4] https://bit.ly/3nfk7Lz

#ai #dataethics #aiethics #microsoft
Полезное чтение о методике JTBD (jobs-to-be-done) для дата-команд [1]

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

Если Вы работаете в команде работающей с данными как с продуктом - это текст точно про Вашу работу.

Ссылки:
[1] https://locallyoptimistic.com/post/building-more-effective-data-teams-using-the-jtbd-framework/

#readings #data #datateams
Мало кто знает что многие файлы с данными находятся не на порталах открытых данных, не в поисковиках вроде Google Dataset Search или DataCite, а на крупнейших хостингах кода таких как Github.

Поисковая система Github'а поддерживает запросы с указанием части названия файла, простым поиском можно найти десятки миллионов файлов в форматах .json, .csv, .xml, .sqlite.

Пример запроса filename:.csv [1] конечно, надо помнить что у Github'а нет сбора метаданных как в других поисковиках, но, при этом, объём хранимых данных количественно превосходит все остальные источники вместе взятые. Хотя и по объёму, наверное, меньше чем реестр открытых данных Amazon.

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

Также у Github'а много других, расширенных опций для поиска [2] которыми, на удивление, многие редко пользуются

Ссылки:
[1] https://github.com/search?q=filename%3A.csv&type=code
[2] https://github.com/search/advanced

#opendata #github #opensource
Кажется я ещё ни разу об этом не писал, о том как сопоставить метрики качества данных используемые в Modern Data Stack и в порталах открытых данных. Во многом там разные подходы, я писал о разнице между разными типами каталогов в большом тексте на Medium.

В блоге Towards Data Science полезный текст от Prukalpa, сооснователя стартапа Atlan, про методику 5WH1

5WH1
- это список вопросов по качеству данных на которые нужны ответы: What, Why, Where, Who, When, and How.

Или, по русски։ Что, Почему, Где, Кто, Когда и Как

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

Тем не менее, наиболее продуманный стандарт мониторинга качества метаданных - это европейский MQA (Metadata Quality Assurance). Но критерии там иные: Findability, Accessibility, Interoperabilty, Contextuality, Reusability.

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

Подробнее и со ссылками в моей заметке на Medium на английском [1]

Ссылки:
[1] https://medium.com/@ibegtin/data-catalogs-part-3-metadata-quality-observation-c49be890f6ff

#opendata #metadata #dataquality
В рубрике больших наборов данных GitTables [1], огромная коллекция CSV файлов собранных с Github методом поиска о котором я ранее писал совсем недавно [2] и преобразованных в формат Parquet.

Авторы - исследователи из The INtelligent Data Engineering Lab [3] и MIT Media Lab в Университете Амстердама, довольно известная команда учёных работавших над темой семантических типов данных и понимания данных. Они разрабатывали такие инструменты как Sherlock, Sato, AdaTyper и тд по идентификации типов данных. Инструменты скорее академические чем практические, но небесполезные.

GitTables - это интересная идея по сбору данных, с оговоркой что авторы продекларировали сбор и аннотирование данных с массой допущений, ключевое из которых в том что CSV файлы обычно содержат заголовки в первой строке и в том что данные в Github'е хорошо диверсифицированы.

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

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

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

Ссылки:
[1] https://gittables.github.io/
[2] https://t.me/begtin/3994
[3] https://indelab.org/

#opendata #datasets
Полезное чтение про данные, для разнообразия свежие статьи про открытость данных
- Ethics of Open Data за авторством N. Weber, Brandon T. Locke [1] о этике открытости данных, в каких случаях открытость может наносить вред (подсказка - нарушение приватности) и как это решается. Полезное, хотя и очень неполный перечень кейсов рассмотрен.

- How open is open? A study of two Irish open government data websites [2] обзор двух ирландских сайтов с открытыми данными за авторством 3-х исследователей из Саудовской Аравии (!) опубликованное в журнале Вопросы государственного и муниципального управления НИУ ВШЭ. Очень необычная комбинация. Статья скорее любопытная, чем интересная.

- The role of open data in transforming the society to Society 5.0: a resource or a tool for SDG-compliant Smart Living? [3] о том как с помощью открытых данных достигать общества 5.0 и SDG. Фактически это про доступность данных о качестве жизни

- Open Data: A Stepchild in e-Estonia’s Data Management Strategy? [4] по факту критика Эстонской госполитики по открытию данных под видом предложений по её улучшению.

- A Review of Open Research Data Policies and Practices in China [5] обзор политики открытости научных данных в Китае, много примеров, ссылок на порталы и публикации. Если кратко - то открытость исследований активно в Китае развивается, проектов много и они весьма велики. Например, Science DB [6] - это более 5 миллионов открытых наборов данных.

Ссылки:
[1] https://arxiv.org/pdf/2205.10402.pdf
[2] https://vgmu.hse.ru/en/2022--5/606167949.html
[3] https://arxiv.org/pdf/2206.11784.pdf
[4] https://www.sciendo.com/article/10.2478/bjes-2022-0006
[5] https://pdfs.semanticscholar.org/935c/1f6d25b282e53474b1ac55579a135a6ea95f.pdf
[6] https://www.scidb.cn/en

#opendata #data #readings
State of data engineering 2022 [1] обзор инженерии данных в 2022 г. от LakeFS. На мой взгляд составители так сильно поленились, в отличие от других отчетов в стиле state of они просто написали текст с описанием текущих продуктов. При этом, не сравнили с прошлым годом, не использовали опрос пользователей/клиентов, не обосновали почему сделали акцент на этих, а не на других технологиях.

Картинка симпатичная, текст по полезности далек от совершенства. Особенно если сравнить с другими технологическими масштабными исследованиями от Postman и Jetbrains.

Тем не менее что-то полезное и здесь можно найти.

Ссылки:
[1] https://lakefs.io/the-state-of-data-engineering-2022/

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

Например, DataStax, стартап с продуктом Astra DB на базе Apache Cassandra [1]. Для тех кто не помнит, Apache Cassandra - это такая NoSQL база данных с хорошей масштабируемостью. Не такая удобная, ИМХО, из коробки как MongoDB, но гораздо лучше масштабируется горизонтально.

Особенность Apache Cassandra в языке CQL, очень похожем на SQL. Он, с одной стороны, довольно привычен, но с другой не так удобен для работы со схематичными объектами. И вот DataStax в Astra DB [2] добавили почти MongoDB совместимое Document API. Это возможность работы с режиме CRUD.

В общем удобная и полезная возможность. Но, существующая только в облачном виде. Даже Enterprise версия тоже облачная. Этого, в последнее время всё больше, появление cloud-only продуктов. С одной стороны они дают возможность крайне высокой скорости развертывания и управляемости инфраструктуры, а с другой, зависимость от облачных сервисов становится огромной. Впрочем это не только про этот продукт, а про многочисленные другие также.

Ссылки:
[1] https://www.datastax.com/products/datastax-astra
[2] https://docs.datastax.com/en/astra/docs/develop/dev-with-doc.html

#data #startups
Я люблю коллекционировать разные термины и сочетания касающиеся данных, благо комбинации выдумывают самые разнообразные, у меня даже словарик есть примерно на 200 терминов включая такие экзотические как data pollution, data liquidity и data laborers. Давно не встречал новых терминов и вот пополнение.

data stations - станции данных. Термин придуманный в DANS, голландским исследовательским центром работающим над инфраструктурой раскрытия научных данных.

Термин - это по сути аналог dataverse (data universe), тематическая коллекция и правила сбора данных используемое в одноименном продукте сделанном командой Гарварда.

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

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

Ссылки:
[1] https://dans.knaw.nl/en/data-stations/archaeology/

#opendata #openresearchdata #openaccess #data