Не так давно я писал про распознавание классов данных в DataCrafter'е и про небольшой движок с открытым кодом metacrafter [1], но не все и не всегда понимают зачем это нужно и для чего вообще используются подобные инструменты и нужно понимание того что содержится в таблицах с данными. Я постараюсь об этом рассказать в подробностях.

То что я ранее упоминал как классы данных, иногда называют метки данных (data labels), но самое распространённое название - это semantic type (семантический тип данных). В отличие от простых типов данных таких как числа, числа с плавающей запятой, строки, даты, бинарные блоки и так далее, семантические типы определяют смысл и предназначение именно этих данных. Смысл и предназначение как в содержании, так и в последующих вариантах применения.

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

Многие инструменты умеют определять семантические типы весьма неплохо. Например, Talend ETL поддерживает несколько десятков семантических типов данных [2] что используется в преобразованиях данных. Некоторые семантические типы понимает и распознает Google DataStudio [3] что позволяет сразу размечать данные в наборе для разных видов визуализации. А в таком инструменте как Dataprep [4] семантические типы данных используются в задачах очистки наборов данных. И таких применений ещё много.

Поэтому отвечая на вопрос: зачем это нужно, перечислю наиболе очевидные области применения:
1. Идентификации персональных данных в целях комплаенса и соответствия требованиям.
2. Автоматизация обработки данных включая (сопоставление схем, обогащение данных, автоматизация преобразований)
3. Обеспечение качества данных: автоматизация проверки на соответствие данных шаблонам и подсказки для инженеров QA.
4. Автоматизация документирования данных автоописанием полей данных на основе их смысла
5. Улучшение визуализации в BI системах за счёт того что система начинает понимать природу данных и предлагать разные способы их визуализации
6. Повышение находимости данных (data discoverability) через доп фильтры для поиска и через дополнительный способ навигации по данным.

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

Ссылки:
[1] https://github.com/apicrafter/metacrafter
[2] https://help.talend.com/r/en-US/Cloud/data-preparation-user-guide/predefined-semantic-types
[3] https://developers.google.com/datastudio/connector/semantics
[4] https://docs.dataprep.ai/user_guide/clean/clean_df.html

#data #datatools #dataconcepts

В рубрике полезных инструментов с открытым кодом для работы с данными Datasette [1]. Незаменим когда надо очень быстро и простым образом опубликовать данные так чтобы можно было их не просто скачать, но и связывать с другими данными, делать SQL запросы и просматривать онлайн.

Инструмент автоматически создаёт интерфейс поверх набора данных и даёт возможности поиска по нему разными способами. Его особенность в том что он работает поверх базы SQLlite, которую также можно скачать.

Примеры публикаций датасетов с помощью datasette:
- global-power-plants.datasettes.com [2] - база электростанций по всему миру
- fara.datasettes.com [3] - реестр инагентов в США (FARA)
- covid-19.datasettes.com [4] - база кейсов по COVID-19
И многие другие.

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

Ссылки:
[1] https://datasette.io/
[2] https://global-power-plants.datasettes.com/
[3] https://fara.datasettes.com/
[4] https://covid-19.datasettes.com/

#datatools #opendata #data #opensource

Коллекция полезных размышлений о том как считать ROI у команд работающих с данными [1] [2] [3] и о разнице в работе между data engineer, data scientist, analytics engineer, data analyst и machine learning scientist. Размышления полезны, и с точки зрения стратификации задач, и с точки зрения понимания как оценивать результат от каждого специалиста.

Например, ставить KPI дата-инженеру или analytics engineer довольно бессмысленно, инженеры работают на основе тикетов, можно обеспечивая работу систем и инфраструктуры. А вот работу data scientist'ов можно и, некоторые утверждают, обязательно измерять в KPI.

Но, здесь конечно, надо оговориться что всё это ролевое разделение в первую очередь относится к in-house командам, включая команды на аутстаффе. Для команд которые работают как внешние подрядчики существуют разные KPI для заказчики и внутри для руководства.

Ссылки:
[1] https://medium.com/data-monzo/how-to-think-about-the-roi-of-data-work-fc9aaac84a3c
[2] https://benn.substack.com/p/method-for-measuring-analytical-work?r=7f8e7
[3] https://hex.tech/blog/data-team-roi

#data #datamarket #roi #kpi

Я ранее писал о headless BI [1] и headless CMS [2], так называемых безголовых (headless) продуктов, не имеющих интерфейсов для конечных пользователей. В случае CMS это достаточно давнее изменение в подходе, его смысл в том что разделить интерфейсы редактирования текста и интерфейсы его представления. А важно это потому что каналы дистрибуции контента могут быть множественными: веб сайт, приложение для телефона, сайт для планшета, канал в Telegram, канал в Slack и ещё много чего. Поэтому headless CMS довольно неплохо развиваются, своя ниша у них уже давно есть.

С headless BI все чуть сложнее, но несколько стартапов в этой области уже существуют. Отделить создание аналитической базы и базы метрик от пользовательского интерфейса также важно в некоторых случаях поскольку систем интерфейсов может быть много и разных, а метрики нужны одни и те же.

Другой пример headless продуктов это Netlify, Fly.io, Appfleet и ещё с десяток других FaaS провайдеров (Functions-as-a-Service), где от веб интерфейса остаётся только биллинг, а вообще вся работа идёт через командную строку или API. Для работы с этими платформами можно использовать любой инструмент, свой, из экосистемы, сделать на заказ и тд. Эти продукты тоже можно отнести к headless.

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

Интересный вопрос в том какие headless продукты будут следующими? Headless CRM, ERP, CDP? Такого пока нет. Headless mobile apps пока подпадает под headless CMS. Продукты в области data engineering и data science почти все безголовые от рождения, кроме старых ETL систем разве что.

Если есть идеи куда может развиваться эта концепция и какие продукты можно создавать то поделитесь своими мыслями в чате @begtinchat.

Ссылки:
[1] https://begtin.substack.com/p/19
[2] https://t.me/begtin/1902

#headless #data #products #startups

Pinterest заопонсорсили MemQ [1], высокопроизводительную PubSub платформу которую они сделали на замену Kafka. Они ранее писали про неё осенью 2021 г. о том что после замены Kafka на MemQ получили экономию в 80%, правда применяют его для передачи логов и тестировали на AWS, но как бы это показательно.

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

Ссылки:
[1] https://github.com/pinterest/memq
[2] https://medium.com/pinterest-engineering/memq-an-efficient-scalable-cloud-native-pubsub-system-4402695dd4e7

#data #datatools #opensource

Возвращаясь к теме обнаружения данных (data discovery) то более всего она актуальна когда у компании/организации очень много разных систем и данных и есть потребность ответить себе на вопрос как узнать что и где хранится. Я ещё в допандемийное время много читал лекций про карты данных систематизацию источников данных, в первую очередь, в органах власти и госучреждениях. Но в основном я рассказывал про нетехнические методы, а есть и вполне технические, и разного рода ПО и сервисы каталогизации данных - это именно про такое.

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

А есть и гораздо более системные масштабные проекты и это Egeria [1], продукт с открытым кодом от The Linux Foundation, в котором сложно найти удобный UI, зато есть дотошнейшее описание более 800 понятий который относятся. Например, то о чём я ранее рассказывал как "semantic types" (cемантические типы данных), там определено как Glossary Terms [2] и приведена их структура, значительно сложнее чем в большинстве коммерчески доступных сервисах.

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

По моим ощущениям всё скорее движется к систематизации стандартов OpenMetadata [3] и OpenLineage [4] или появлением нового стандарта, потому что OpenMetadata слишком ассоциировано с одноименным продуктом, а OpenLineage даёт чрезмерную вариативность, очень упрощён.

Ссылки:
[1] https://egeria-project.org/
[2] https://egeria-project.org/types/3/0330-Terms/
[3] https://docs.open-metadata.org/openmetadata/schemas/entities
[4] https://openlineage.io/

#datadiscovery #opendata #data #datatools #standards

Даже не знаю как такое прокомментировать. А сколько "взломов" может происходить прямым подкупом админов? А кто в нашей стране отвечает за аудит информационных систем?

16 февраля 2022 года ГУ МВД по Москве возбуждено дело, которое может стать одним из самых громких за последнее время. Сотрудникам Управления К МВД РФ и УФСБ по Москве и МО удалось выявить хакеров, которые взломали «критическую информационную инфраструктуру Российской Федерации».
 
Речь идет о взломе ГИС РД dom.mos.ru («Дома Москвы»), интегрированной в Государственную информационную систему ЖКХ (ГИС ЖКХ) dom.gosuslugi.ru. С хакерами за работу расплатились криптовалютой (USDT Tether), однако выявить заказчиков атаки на «критическую инфраструктуру» удалось. И ими оказались вовсе не западные враги. Главным подозреваемыми в рамках возбужденного дела по статье 274.1 УК РФ ( Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации) является… группа столичных чиновников, включая руководство Жилищной инспекции по ЗАО Москвы, действовавших вместе с руководителями управляющих компаний (так и сказано в материалах дела) .
 
А услуги хакеров им были нужны, чтобы более 1000 жилых домов, фактически являющихся аварийными, были приняты Мосжилинспекцией к сезонной зимней эксплуатации без соответствующих документов.

Хакеры взломали dom.gosuslugi.ru и внесли ложные отметки в государственной информационной системе ГИС "ЖКХ", будто дома, которые в реальности являются аварийными, готовы и приняты к зиме, без фактической подгрузки документов в систему.  

Пока дело возбуждено в отношении «неустановленных лиц», но вскоре в нем появятся обвиняемые. 

Коммерсант пишет о том что Правительство Москвы в лице ДИТ заказало разработку мобильного приложения "Сводка" [1] которое теперь будет отслеживать ещё и частоты слов в Yandex Wordstat и Googe Trends для мониторинга криминогенной обстановки.

Я прокомментировал в статье и повторюсь сейчас - важнее не получение данных государством из коммерческих систем, а раскрытие данных государством. У Правительства Москвы уже много лет существует система мониторинга преступности использующая не только данные МВД, но и многие другие источники. Нет никаких ограничений, кроме политических чтобы раскрывать эти данные с детальностью до района, а я точно знаю, что там возможно детальность и до улицы, и до блока в 500 метров.

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

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

Ссылки:
[1] https://www.kommersant.ru/doc/5218189

#opendata #police #crimedata

Приглашаем на День открытых данных 2022 — онлайн

4-5 марта 2022 года Инфокультура проведет ежегодную конференцию, приуроченную к международному Дню открытых данных.

Присоединяйтесь ко Дню открытых данных, чтобы узнать:
— Как открывать код, данные, знания, созданные за счет госбюджета.
— Как в 2022 году в России регулируется оборот персональных данных.
— Эволюция открытости: от открытых данных по умолчанию к Data4Good.
— Что известно о доступности медицинских данных в эпоху пандемии.
— Где взять данные о жизни в стране: официальные и альтернативные источники.
— Какие проблемы доступности государственных данных сейчас наиболее актуальны.
— Как решить проблему совместимости открытых лицензий в разных юрисдикциях.

Подробности и регистрация: opendataday.ru/msk. Трансляция будет доступна и бесплатна для всех желающих.

В рубрике как это работает у них, каталог научных данных геологической службы США (USGS) [1], всего более 23 тысяч наборов данных в основном в CSV, XML и Shape форматах, очень много данных с геопривязкой, наверное даже большая их часть.

Большая часть публикуется в ScienceBase [2] цифровом репозитории USGS, а всего агрегируется 8 научных репозиториев.

Сейчас они развивают каталог в сторону публикации научных моделей [3] вместе с указанием данных, ПО и публикаций на их основе.

Главные особенности каталога данных:
- обязательные DOI ссылки для всех датасетов
- детальные метаданные в привязкек теме наук о земле
- обязательная привязка к локации
- условия использования на все данные не ограничивающие
- обязательно с указанием периода наблюдений


Ссылки:
[1] https://data.usgs.gov/datacatalog/
[2] https://www.sciencebase.gov/catalog/
[3] https://data.usgs.gov/modelcatalog/search

#opendata #sciencedata #usa #geology

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

Ссылки:
[1] https://github.com/blutjens/awesome-forests

#datasets #opendata

В продолжение темы открытых наборов данных лесе и заодно отвечая на вопрос о том что можно сделать в открытых данных. Например, петиция на Change.org [1] об открытии реестра зелёных насаждений в Москве. До петиции, её авторы запрашивали эти данные у властей города и получили ответ в стиле "граждане у нас малограмотные, а реестр только для нужд чиновников" [2].

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

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

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

Авторы петиции также ведут канал в телеграме @openregistry [3] где можно узнать о её продвижении и результатах общения с городскими властями.

Я со своей стороны напомню что когда-то, 10 лет назад, Москва была лидером по открытости данных в России. Первый государственный портал открытых данных был сделан властями Москвы, они же публиковали наибольшие объёмы данных и сейчас уровень раскрытия данных довольно высок.

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

Ссылки:
[1] www.change.org/p/защити-деревья-в-городе-подпиши-петицию-за-открытый-реестр-зелёных-насаждений-mos-mossobyanin-ditmos-depmospriroda-dpioosmos-ivan-drobotov
[2] https://www.facebook.com/groups/za.travu/permalink/3670269526319188/?app=fbl
[3] https://t.me/openregistry

#opendata #petitions #moscow #ecology #lifequality

В блоге Datahub, open source продукта каталога корпоративных данных пост про то как составлять бизнес глоссарии [1] в привязке к данным. То что в Datahub называется бизнес глоссарием - это просто другой взгляд на те же semantic types, смысловые категории данных. В Datahub всё решают через самостоятельное составление этого глоссария и через тэгирование данных что тоже вполне себе подход для многих задач.

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

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

Вообще же могу сказать что мне лично в этом всём нехватает большого числа разных данных. Всё основное что можно было собрать по российским порталам открытых данных уже или загружено в DataCrafter [2], или лежит большими слепками вроде слепка данных в data.gov.ru или, ещё, с крупных зарубежных порталов данных. В общей сложности около 75 тысяч наборов данных по которым не менее 300 тысяч полей/метаданных доступны. Но это всё общедоступные данные, там почти нет чувствительных персональных данных (кроме некоторых исключений).

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

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

Ссылки:
[1] https://medium.com/datahub-project/creating-a-business-glossary-and-putting-it-to-use-in-datahub-43a088323c12
[2] https://data.apicrafter.ru

#datacatalogs #metadata

Полезное чтение о данных и их регулировании:
- Data saves lives: reshaping health and social care with data (draft) [1] черновик регулирования в Великобритании, с примерами и целеполаганием на использование данных в целях спасения жизни и здоровья граждан. Четко и внятно написанный документ,стоит почитать чтобы понимать как развивается регулирование в UK. Можно обратить внимание на то что кроме данных планируется и раскрытие кода под лицензиями MIT and OGLv3
- Public bodies’ access to private sector data [2] научная статья о том как в 12 европейских локальных юрисдикциях органы власти взаимодействуют с бизнесом для получения данных частного сектора
- Open Data Governance and Its Actors [3] свежая книга о регулировании открытых данных от Max Kassen. Я её ещё не читал, но планирую. Судя по содержанию, похоже книга про систематизацию того как устроено раскрытие данных и кто за это отвечает
- Data Federalism [4] очень систематизирующий и длинный лонгрид о взаимодействии властей между собой через призму данных. Автор юрист, очень много конституционных аспектов и особенностей связанных с работой с данными в госорганах США.
- The Political Philosophy of AI: An Introduction [5] политические аспекты применения ИИ. Любопытная книга, я её также пока не читал, и также планирую прочитать.

Ссылки:
[1] https://www.gov.uk/government/publications/data-saves-lives-reshaping-health-and-social-care-with-data-draft/data-saves-lives-reshaping-health-and-social-care-with-data-draft
[2] https://firstmonday.org/ojs/index.php/fm/article/view/11720
[3] https://link.springer.com/book/10.1007/978-3-030-92065-4
[4] https://harvardlawreview.org/2022/02/data-federalism/
[5] https://www.politybooks.com/bookdetail?book_slug=the-political-philosophy-of-ai-an-introduction--9781509548538

#ai #data #policy #books #reading

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

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