Многие уже написали о просрочке сертификата домена у cert.gov.ru [1], официального сайта Национального координационного центра по компьютерным инцидентам. В котором, казалось бы, должны быть люди как никто понимающие про безопасность, сертификаты, HTTPS, TLS и так далее, а, тем не менее, вот уже 8 дней с 19 января их сертификат просрочен.

Здесь можно задаваться вопросом и о том что сайт cert.gov.ru почему-то до сих пор сайт-визитка, на нём нет даже методических рекомендаций, а контактный номер - номер мобильной связи.

Но я о другом. Мониторинг состояния доменов, недоступность сайтов, просрочка сертификатов и тому подобное - это всё то что должно быть часть мониторинга государственной инфраструктуры. Как минимум публичной инфраструктуры и который не ведётся и даже не планируется. Нет даже реестра госдоменов и сайтов относящихся к государственным. Я регулярно напоминаю что мы такой реестр ведём в виде открытых данных [2] в частном порядке, для целей архивации сайтов в Национальный цифровой архив [3], но за все эти годы никто из госорганов даже не связывался о том чтобы взять его за основу или иначе повторно использовать для создания государственной системы мониторинга.

Ссылки:
[1] https://cert.gov.ru
[2] https://github.com/infoculture/govdomains
[3] https://ruarxive.org

#security #domains #government

Полезное чтение про данные и не только:
- Document Your Dataset Using Apache Parquet [1] о том что формат данных Parquet позволяет хранить метаданные к полям таблиц и к набору данных. Можно использовать его для хранения метаданных пакета данных и документации.
- AutoDoc - a project to document automatically your data warehouse [2] от CastorDoc об автоматизации написания документации к данным. То и чем я тоже занимаюсь и очень связано с автоклассификацией данных. Жаль коротко об этом пишут.
- MDS 18 [3] - 18-я рассылка Modern Data Stack, внутри интересное про low code data engineering, тоже интересный тренд и стартап Prophecy [4] который превращает сложные задачи по настройке сложного ПО в упрощённый интерфейс доступный юниору.

Ссылки:
[1] https://medium.com/geekculture/add-metadata-to-your-dataset-using-apache-parquet-75360d2073bd
[2] https://medium.com/castor-app/docmaster-a-project-to-auto-document-your-data-warehouse-castor-blog-69005927c4c3
[3] https://letters.moderndatastack.xyz/mds-newsletter-18/
[4] https://www.prophecy.io/

#reading #data #datatools

Весьма интересный Block Protocol [1] стандарт/протокол про интеграцию между данными и интерактивными элементами. Позволяют через данные и схемы стыковать таблицы, загрузки файлов, отображение карточек персон и так далее по заранее готовым шаблонам. Большая работа и интересная идея, стоит отслеживать его развитие. За стандартом находится команда Hash.ai [2] стартапа по созданию "Github'а для симуляций", также любопытный продукт. Немного за пределами моих интересов, но их подход к учёту и систематизации данных очень любопытен.

Ссылки:
[1] https://blockprotocol.org
[2] https://hash.ai

#protocols #standards #data

Ещё один аналог/замена Airflow, Airbyte и др. data pipeline orchestration инструментов - Estuary [1]. Сейчас в виде открытого кода продукта flow [2] и обещают облачную версию, предлагают присоединяться в листу ожидания беты. В качестве коннекторов к источникам данных используют совместимые с Airbyte. Внутри всё на Go и Rust, с конфигами на Yaml и с активным использованием JSON schema.

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

Ссылки:
[1] https://estuary.dev
[2] https://github.com/estuary/flow

#datatools #opensource

Неприятный факт в том что почти все порталы открытых данных, не только российские, а в мире - это редкостные дата-помойки. Ещё более менее там где данные загружены в сервисы вроде Socrata или в OpenDataSoft и хранятся таблицами. А там где публикуются просто файлы, особенно CSV, всё в разнобой.

Я смотрю сейчас data.gov.uk [1] и там та же беда с CSV файлами что и российских порталах открытых данных:
- разные кодировки файлов
- отсутствие заголовков
- разные разделители значений в строках
- мусорные значения из-за экспорта из Excel (ломают автоматическую обработку данных)

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

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

Но, что надо отметить в Великобритании, это правовая проработка раскрытия данных, раскрытие данных в рамках политической транспарентности и в целом модель open by default у них работает. Публикуют много мусора, но работает. Эдакий open garbage by default.

Надо об этом написать статью на английском языке и так и назвать Open garbage by default. Data.gov.uk as an example.

Ссылки:
[1] https://data.gov.uk

#opendata #opengarbage #dataportals

The Future history of data engineering [1] активно цитируемый сейчас текст от Matt Arderne в котором он описывает развитие текущих платформ по инженерии данных и их будущее. Рассуждения интересные, практические и автор пишет про новое понятие и роль Data Platform Engineer (DPE). Это инженер данных который знает как устроены платформы для работы с данными и знает как правильно их применять для конкретых, как правило сложных, случаях.

Ссылки:
[1] https://groupby1.substack.com/p/data-engineering

#data #readings #dataenginering

Сегодня в 11:10, в рамках Privacy Day 2022 модерирую сессию Биометрия и другие персональные данные в школах: в чем опасность единой базы данных о детях.

Подключайтесь к трансляции https://privacyday.ru

#privacy #biometrics #vents

В рубрике больших наборов данных команда Microsoft Bing опубликовала наборы данных со сведениями о зданиях [1] под открытой лицензией Open Data Commons Open Database License (ODbL) используемой в OpenStreetMap.

Наборы данных включают:
- США - 129.6 миллиона зданий
- Нигерия и Кения - 50.5 миллиона зданий
- Южная Африка - 44.5 миллиона зданий
- Уганда и Танзания - 17.9 миллионов зданий
- Канада - 11.8 миллионов зданий
- Австралия - 11.3 миллионов зданий

Это очень большое раскрытие данных, около сотни гигабайт в распакованном виде в формате GeoJSON.

P.S. Хотелось бы чтобы они так разметили и законтрибьютили данные по России, но подозреваю что в России так много конфликтов вокруг секретности геоданных что на это Microsoft не пойдет.

Ссылки:
[1] https://blogs.bing.com/maps/2022-01/New-and-updated-Building-Footprints/

#opendata #microsoft

Кроме того что я тут пишу довольно много про данные, регулярно пишу колонки для СМИ и ещё много чем занимаюсь, я не перестаю программировать. Чаще в режиме ведения pet-проектов, помогающих в работе, обработке и анализе данных вручную и автоматически.

Один из таких проектов которые я веду и обновляю - это undatum [1] утилита командной строки с открытым кодом для Python написанная изначально как швейцарский нож по обработке данных JSON lines и BSON. Для тех кто не знает, JSON lines и BSON - это форматы используемые активно в NoSQL document-oriented базах данных. Они могут содержать вложенные объекты: словари, массивы данных и тд. Это довольно сильно отличает их от форматов для плоских таблиц таких как CSV/TSV. И для их обработки инструментов гораздо меньше. Особенно для BSON, который применяется преимущественно в MongoDB и мало где используется. Но, поскольку у нас в DataCrafter (data.apicrafter.ru) внутри используется MongoDB, то BSON оказывается нативным и нечеловекочитаемым форматом и для него инструменты работы с данными нужны.

Undatum умеет:
- преобразовывать между форматами файлов CSV, XLS, XLSX JSON lines, BSON, а теперь ещё и Parquet
- печатать поля (headers) файлов и структуру для CSV, JSONl, BSON
- делать дамп уникальных значений конкретного поля
- делать дамп частот значений конкретного поля
- генерировать схему структуры данных
- анализировать статистику по набору данных: тип поля, является ли уникальным, частоты значений и тд.
- разрезать файлы на множество по значению поля или по числу записей в каждом
- применять к каждой записи файла скрипты на Python
- проверять значения в полях файла на одно из правил валидации: сейчас это проверка email, url, кодов ИНН, ОГРН и др.

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

Ссылки:
[1] https://github.com/datacoon/undatum

#datatools #opensource

Вышла свежая версия OpenMetadata 0.80 [1] инструмента сбора метаданных о таблицах, дашбордах, трубах данных и тд. Аналог Datahub, Amundsen, но с прицелом на открытый общедоступный стандарт описания данных.

В новой версии:
- политики контроля доступа (access control policy)
- ручное добавление происхождения данных (manual linage)
- уведомления о событиях (event notification)
- контроль качество данных (data profiler) на базе Great Expectations

и ещё много чего.

Главный недостаток, на мой взгляд, в том что OpenMetadata не поддерживает NoSQL базы данных такие как MongoDB или Elasticsearch. Например, Datahub умеет данные о MongoDB собирать.

Об этом я как-нибудь отдельно напишу, о том как существующая среда Modern Data Stack тяжело стыкуется с NoSQL продуктами и что с этим делать.

А пока стоит изучить новые возможности OpenMetadata.

Ссылки:
[1] https://blog.open-metadata.org/openmetadata-0-8-0-release-ca09bd2fbf54

#opensource #datatools #metadata

Тем временем как минимум с прошлого года идёт большая кампания [1] по поводу раскрытия данных Международным энергетическим агенством (IEA) и 6 января они анонсировали что предложение по раскрытию данных внутри агентства было прдставлено совету директоров [2] что уже большой прогресс и даёт надежду что данные будут раскрываться.

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

Почему это не так просто? Потому что данные передаваемые в IEA часто не раскрываются на национальном и корпоративном уровне и рассматриваются как данные ограниченного использования и корпоративные тайны.

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

А у нас появятся новые интересные данные для серьёзного и не очень серьёзного анализа.

Ссылки:
[1] https://ourworldindata.org/free-data-iea
[2] https://www.qcintel.com/article/correction-iea-proposes-to-make-all-its-data-freely-available-3540.html
[3] https://thebreakthrough.org/blog/urge-iea-to-make-energy-data-free

#opendata #iea #energy #climate #climatechange

Как командам по работе с данным документировать свою работу? Большая часть заметок и описаний являются внутренними, но у команды Gitlab есть огромный детальный и интересный раздел Data team [1] описывающий буквально все аспекты работы с данными внутри Gitlab: взаимодействие команд, инфраструктуру данных, используемые инструменты, решаемые задачи, перечень дашбордов и источников данных, правила программирования на Python, правила настройки dbt и ещё много чего другого.

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

А я бы обратил в этом гайде на два аспекта:
- Trusted Data Framework [2] создание в корпоративной системе данных "доверенной зоны" которая настроена на многочисленные проверки. Она должна покрывать те области в которых принимаются наиболее критически важные решения.
- Data Pumps [3] другое название для Reverse ETL, инструменты возврата в маркетинговые и транзакционные системы результатов анализа для улучшения работы этих систем.
- Data Spigot [4] краны данных. Это когда каждое приложение получает данные по индивидуальным реквизитам доступа (своему ключу) и только в минимальном объёме необходимом ему для работы. В Gitlab'е всё построено вокруг хранилища в Snowflake, но сама идея универсальна.

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

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

Ссылки:
[1] https://about.gitlab.com/handbook/business-technology/data-team/
[2] https://about.gitlab.com/handbook/business-technology/data-team/platform/#tdf
[3] https://about.gitlab.com/handbook/business-technology/data-team/platform/#data-pump
[4] https://about.gitlab.com/handbook/business-technology/data-team/platform/#data-spigot

#data #datainfrastructure #datadocumentation #dataengineering

В Forensic News статья [1] о том что российский интегратор Infotecs помещён в ban list (чёрный список) Министерством торговли США и теперь американские компании не могут поставлять им продукцию двойного назначения.

Издание делает особенный акцент на особенностях компании:
- Infotecs производит средства безопасности и криптографии
- учредитель Андрей Капчаев десять лет проработал в исследовательском подразделении КГБ и назван shadowy engineer and businessman и основным владельцем
- у компании есть лицензии от многих госорганов, в том числе от ФСБ для защиты гостайны
- большая часть бизнеса компании в России
- при этом у компании есть несколько партнерств и юридических лиц в США, более 20 лет
- компания поставляет продукты и услуги Сбербанку, РЖД, Ростелекому и другим госструктурам

И там ещё много всего, не буду всё перечислять. В статье в Commnews делают акцент на том что лицензии на работу с гостайной [2] и СКЗИ [3] - это просто нормы российского рынка, судить по их наличию о связях с ФСБ это, несколько, скажем так, натянуто. Я полагаю что здесь присутствовал набор факторов, а не только этот, но, конечно, всё это очень похоже на охоту на ведьм. То что написано про Инфотекс можно сказать про многие бизнесы.

Российские ИТ компании со специализацией на инфобезе как и другие активно пытались выйти на зарубежные рынки, некоторые туда уходили совсем, вроде Лаборатории Касперского которые в России российские, а за рубежом давно позиционируют себя как международный холдинг.

И это нормальная бизнес логика, скажем так в этом ничего противоестественного нет, только деньги, только заработок на новых рынках. А если Министерство торговли США начнет развивать эту практику, то они могут забанить так почти всех российских интеграторов. Не то чтобы бы их очень жалко, но и выглядит это странно. Российские интеграторы всегда были ключевыми проводниками и распространителями железа и ПО как раз преимущественно американских вендоров.

И конечно, важно помнить, текущие ограничения - это не санкционные списки, это ограничения именно на поставку ПО и устройств двойного назначения.

Ссылки:
[1] https://forensicnews.net/russian-cybersecurity-firm-infotecs-draws-u-s-federal-scrutiny-concern-from-national-security-experts/
[2] https://www.comnews.ru/content/218461/2022-01-26/2022-w04/infoteks-napisali-donos

#russian #it #government #infotecs

В рубрике интересных наборов данных OpenSanctions [1] проект о котором я уже писал в сентябре 2021 года [2] добавил интеграцию с Wikidata [3], одним из проектов фонда Викимедиа. В Wikidata собраны многие профили политиков и теперь эти профили импортируются в OpenSanctions. В пример, ожидаемо, приводят профиль Владимира Путина [4] и Дональда Трампа [5].

Проект активно развивается, раскрывает исходный код и данные в виде наборов данных и API. У него ограничивающая лицензия CC-BY 4.0 NC и коммерческое лицензирование для бизнес пользователей. С оговоркой что для журналистов и активистов лицензия CC BY 4.0 [6]. Это не вполне открытая лицензия, но учитывая плотный рынок due diligence и того что эти правила заданы на старте проекта, вполне приемлемая.

А то что теперь подгружаются данные из Wikidata даёт шанс что проект со временем превратится в большую базу PEPs (персон с политическим влиянием) по аналогии с LittleSis.org [7], но если LittleSis был с самого начала проектом ориентированным на США, то OpenSanctions довольно универсален.

Ссылки:
[1] https://www.opensanctions.org
[2] https://t.iss.one/begtin/3074
[3] https://www.opensanctions.org/articles/2022-01-25-wikidata/
[4] https://www.opensanctions.org/entities/Q7747/
[5] https://www.opensanctions.org/entities/Q22686/
[6] https://www.opensanctions.org/licensing/
[7] https://littlesis.org

#opendata #opengov #sanctions #datasets #openapi

Firebolt, израильский стартап облачной управляемой базы данных, получил очередной раунд финансирования в $100M и общую оценку в $1.4 миллиарда. Firebolt - это аналог Snowflake, Amazon Redshift, Google BigQuery. Главный акцент делают на скорости с позицией что "всем нравится Snowflake, мы делаем не хуже, но быстрее". Имеют хорошие шансы занять свою нишу в корпоративном стеке данных.

Другой стартап DreamIO получили раунд финансирования в $160M при общей оценке в $2 миллиарда. DreamIO предлагают облачное и корпоративное озера данных основанные на Apache Arrow.

Ещё один стартап Minio предоставляющие ПО для создания S3 совместимых хранилищ получили финансирование в $104M при общей оценке более чем в $1 миллиард. В основе Minio их же опенсорсный продукт.


Ссылки:
[1] https://techcrunch.com/2022/01/26/firebolt-a-data-warehouse-startup-raises-100m-at-a-1-4b-valuation-for-faster-cheaper-analytics-on-large-data-sets/
[2] https://www.dremio.com/press-releases/dremio-doubles-valuation-to-2-billion-with-160m-investment-towards-reinventing-sql-for-data-lakes/
[3] https://blog.min.io/ab_seriesb/

#startups #data #dataproducts

В блоге Incident.io хорошая публикация A modern data stack for startups [1]. В отличие от многих рассуждений про современный стек данных в этот раз про случаи когда у Вас не так много данных, не так много связей между ними и в целом простые задачи. К примеру, Gitlab который я приводил в пример, или многие другие публикации о стеках технологии, в основном про крупные корпорации. А тут публикация про малый средний бизнес на собственном примере, когда у тебя из источников данных только продукт, поддержка и CRM, всего две системы извлечения данных, одно хранилище и один инструмент визуализации.

Правда, везде dbt, буквально куда ни ткнись, всюду для трансформации данных используют преимущественно dbt.

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

Ссылки:
[1] https://incident.io/blog/data-stack

#datastack #startups #data #datatools

В США Национальный институт здоровья (NIH), осуществляющий финансирование большей части государственных расходов на исследования в области здравоохранения, анонсировал инициативу GREI по поддержке открытых репозиториев публикации научных данных и приведению их к общим стандартам метаданных необходимых для результатов исследований финансируемых NIH [1]. Это охватывает 6 открытых репозитория таких как:
- Dryad
- Dataverse
- Figshare
- Mendeley Data
- Open Science Framework
- VIvli

Всё это в дополнение к 67 отраслевым предметным научным репозиториям данных поддерживаемых NIH [2], большая часть которых являются государственными.

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

Ссылки:
[1] https://datascience.nih.gov/news/nih-office-of-data-science-strategy-announces-new-initiative-to-improve-data-access
[2] https://www.nlm.nih.gov/NIHbmic/domain_specific_repositories.html

#openscience #opendata #datarepositories