Кроме того что я тут пишу довольно много про данные, регулярно пишу колонки для СМИ и ещё много чем занимаюсь, я не перестаю программировать. Чаще в режиме ведения 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

В рубрике очень больших наборов данных OpenAlex [1] крупнейший каталог всех научных работ, научных организаций, конференций и авторов работ. Похожий на Microsoft Academic Graph, другой очень крупный набор данных со схожим составом. OpenAlex распространяется в виде слепков на Amazon AWS и через API. А также обещают в феврале 2022 года запустить веб-сайт.

Всё распространяется под лицензией CC0, так что это true open data, можно использовать для любых целей и задач. Например, если кто-то задумает реконструировать карту российской науки или отслеживать публикации по какой-либо редкой теме, этот датасет хорошо подойдет для затравки.

Ссылки:
[1] https://docs.openalex.org/

#bigdata #datasets #data #academic #research

В блоге Uber Engineering полезная заметка об оптимизации формата Parquet [1] с точки зрения сжатия, хранения и скорости работы. Автор рассказывает как они используют Parquet в экосистеме Hadoop'а у себя внутри для обработки и хранения данных измеряемых петабайтами и том что хранение в таких объёмах обходится дорого и после многих экспериментов они остановились на формате Parquet со сжатием через ZSTD и что это значительно эффективнее чем Snappy/Gzip по балансу скорости обращения к данным и уровню сжатия.

Но что интереснее автор приводит ещё и трюк с сортировкой данных который позволяет значительно улучшить сжатие предварительно проведя сортировку данных в колонках. Причём очень многое зависит от порядка сортировки полей, в их случае при порядке начинающегося с поля uuid достигается наилучший результат. В основе этого эксперимента статья Reordering Rows for Better Compression: Beyond the Lexicographic Order [2].

Случай Uber'а с хранением таких объёмов, конечно, довольно редкий, такое есть только в крупнейших стартапах/корпорациях. Есть много задач сильно меньше, до терабайтов, где также надо работать с разными форматами данных и Parquet выглядит всё более привлекательным для хранение и распространения данных для аналитической работы.

Ссылки:
[1] https://eng.uber.com/cost-efficiency-big-data/
[2] https://arxiv.org/pdf/1207.2189.pdf

#parquet #data #reading #dataengineering

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

Напомню что @DataClassifierBot анализирует структуру файла и на основе данных определяет содержание поля возвращает информацию о том что там содержится. Бот умеет определять такие виды данных как:
- Ссылки
- Email адреса
- ФИО и по отдельности фамилии, имена и отчества
- названия организаций
- Коды организаций ИНН/КПП/ОГРН/ОКПО
- Дату и время в любом формате
- Коды ОКВЭД, ОКПД, ОКВ, ОКФС и другие
- Названия городов
- Названия стран
- Адреса

и многое другое, полный перечень выявляемых идентификаторов и видов полей на сайте DataCrafter https://data.apicrafter.ru/class

#datatools #data

Коммерсант пишет [1] что
Правительство поручило Минцифры к февралю разработать план по предоставлению бизнесу доступа к государственным обезличенным данным для обучения искусственного интеллекта (ИИ). На первом этапе откроют информацию Россельхознадзора, ФНС, Росстата, Минвостокразвития и Росреестра.

и что По данным Минцифры, в 2021 году сформировано 26 ведомственных дата-сетов: 4 (Россельхознадзор, ФНС России, Росстат, Минвостокразвития, Росреестр) — с возможностью использования сторонними разработчиками для бизнес-решений и 22 — для внутренних нужд ФОИВов в рамках цифровой трансформации.

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

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

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

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

#opendata #data #ai #datasets

☝️Запись трансляции Privacy Day 2022

В пятницу мы провели конференцию о приватности и персональных данных, где объединили экспертов из разных сфер, чтобы обсудить насущные проблемы и последние события: сбор биометрии в разных целях, шатдауны в Казахстане, использование шпионского ПО и громкие блокировки. А ещё взяли интервью у представителей The Tor Project.

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

Запись трансляции вместе с таймкодами сохранили на нашем YouTube-канале:
➡️ https://youtu.be/FixkV69x5yA

Для тех кто недавно подписался и в качестве многочисленных напоминания о том кто я, чем занимаюсь и о чём тут пишу.

Я больше 12 лет занимаюсь занимаюсь тематикой открытости государства и открытыми данными, возглавляю АНО "Инфокультура" (@infoculture) [1] внутри которого мы создавали и поддерживаем такие проекты как Госзатраты [2], Открытые НКО [3], Хаб открытых данных [4], Простой язык [4] и многие другие [5], а также День открытых данных в Москве [6].

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

С 2019 г. по май 2021 г. я был соавтором проекта Госрасходы [7], по мониторингу бюджетных средств. Этот проект был поддержан Алексеем Кудриным (главой Счетной палаты) и я работал над ним в Счетной палате, а сейчас этим проектом продолжает заниматься моя коллега Ольга Пархимович, в телеграме @ahminfin.

Уже более полугода я сделал фокус на коммерческие проекты, наша команда разрабатывает проекты в области сбора и анализа данных, инженерии данных и комплаенса. В частности мы делаем проект APICrafter [8] в виде высокопроизводительного API к ЕГРЮЛ, базе госконтрактов и другим сведениям о юр лицах с гибкой тарификацией, а также создаём продукт DataCrafter [9] в котором собираем крупнейший каталог данных в России, преимущественно открытых данных и преимущественно открытый каталог.

Параллельно я возглавляю Ассоциацию участников рынка данных АУРД (@AURData) [10] выступающую в интересах малого и среднего бизнеса, преимущественно и доступности данных для бизнеса.

А также я много пишу про данные, открытые данные, государственные данные и, в последнее время, всё больше пишу про технологии работы с данными у себя в телеграм канале @begtin, в блоге begtin.tech тексты среднего размера [11] и в рассылке на Substack лонгриды [12]. Раньше я писал больше про гостехнологии, госзакупки и государство в целом, сейчас тоже иногда, но уже реже. Поэтому если Вы подписались, то будьте готовы что про данные и технологии я буду писать много, про остальное реже.

Ах да, я совсем забыл, что веду ещё и проект Национального цифрового архива по архивации сайтов и иных digital-born объектов [13] с фокусом на сайты в зоне риска исчезновения. Самое главное дело, жаль времени на него уходит мало.

Cсылки:
[1] https://infoculture.ru
[2] https://clearspenging.ru
[3] https://openngo.ru
[4] https://plainrussian.ru
[5] https://infoculture.ru/projects
[6] https://opendataday.ru
[7] https://spending.gov.ru
[8] https://apicrafter.ru
[9] https://data.apicrafter.ru
[10] https://aurd.ru
[11] https://begtin.tech
[12] https://begtin.substack.com
[13] https://ruarxive.org

#data #reading #blogging

Кстати, для тех кто ищет познавательного чтения, могу порекомендовать блоги чиновников правительства Великобритании [1]. Если в России блоги остались только у какого-то небольшого числа топовых чиновников вроде глав регионов и скорее они инструменты "поддержания медийности", хотя до этого, в 2010-2014 годах был расцвет госблоггинга, быстро угасшего после увольнений, введения мониторинга того что люди государства пишут и тд.

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

Например, я там читаю Data in Government [2] о том как работают с данными внутри Civil Service, а также блог Companies House [3] которые ведут реестр юр. лиц, они регулярно выкладывают интересную аналитику и ещё многие другие, там много постов про data science, data modelling, data policy и чуть-чуть про data engineering.

Ссылки:
[1] https://www.blog.gov.uk/
[2] https://dataingovernment.blog.gov.uk/
[3] https://companieshouse.blog.gov.uk

#opendata #data #government #uk

У ORelly свежий отчет What Is Data Observability? [1] написанный Andy Petrella, основателем платформы Kensu.io, как раз по data observability. Отчёт, при этом, совершенно не рекламный, а как раз с разъяснением что такое наблюдаемость данных, кому это нужно и в каких ситуациях. Сравнений платформ, продуктов и решений нет, но есть аргументы, архитектура и описание DataOps без упоминания термина, вместо него, Applying DevOps Practices to Data, но смысл не меняется.

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

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


Ссылки:
[1] https://www.kensu.io/oreilly-report-what-is-data-observability

#data #moderndatastack

О том как организована работа с данными в разных средах, в научной среде одна из наиболее развитых экосистем работы с данными существует в биоинформатике. Проект Dockstore [1] - это некоммерческий академический проект со многими признаками стартапа, позиционируется как An app store for bioinformatics. В нём сейчас 44 научных организации регистрирует свой код рабочих процессов (workflows) с возможностью перепроверки на различных онлайн платформах: Galaxy, AnVIL, Terra, DNANexus, DNAStack и NHLBI BioData Catalyst. Всего более 1200 рабочих процессов (workflows) и более 250 инструментов (tools) с репозиториями, возможность запуска в Docker'е и тд.

Вообще экосистема для работы в биоинформатике мне чем-то напоминает Modern Data Stack и даже кое-где пересекается, в части использования Github, Docker, Google Cloud как хранилища и ряда других облачных инструментов.

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

Сам проект Docstore существует на гранты государственных научных грантодателей Канады и США, существует с открытым кодом [3] и активной командой разработчиков.

Ссылки:
[1] https://dockstore.org/
[2] https://www.ga4gh.org/
[3] https://github.com/dockstore/dockstore

#opensource #openprojects

Во Франции Государственный совет (Conseil d’État) открыл свой портал открытых данных [1]. Куда уже выложили его решения, к 31 марта 2022 года выложат решения апелляционных судов, а к 30 июня 2022 года решения административных судов. Объём данных обещает быть большим, всё опубликовано под французской свободной лицензией созданной Etalab [2]

Ссылки:
[1] https://opendata.conseil-etat.fr/
[2] https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf

#opendata #france

Языку SQL уже много, очень много лет, но он продолжает быть чуть-ли не основным для аналитиков данных, инженеров и иных специалистов по работе с данными. Разве что дата сайентисты в некоторых задачах могут избежать счастья работать с SQL и используют Python/Java/R и др.

У SQL много достоинств и не меньше недостатков, главным из которых я бы назвал отсутствие удобных способов работы с не-плоскими данными, такими как JSON и тд. Время от времени появляются альтернативы, которые редко выходят за пределы конкретного продукта, но могут быть очень интересными.
Итак:
- SpyQL [1] гибрид SQL и Python, утилита командной строки позволяет выполнять SQL-похожие запросы с выражениями на Python внутри. Умеет работать с CSV, JSON и текстовыми файлами
- LINQ [2] объектный родной для .NET язык запросов придуманный Microsoft. Не используется за пределами экосистемы .NET
- SPARQL [3] язык запросов родом из Sematic Web. Сложен для непосвящённых, так и не получил массового распространения как и сами СУБД которые его поддерживает, но имеет немало, в первую очередь научных внедрений и использования.
- GraphQL [4] изначально язык API, но есть немало СУБД для которых он уже стал нативным. Малопопулярен в среде обработки данных, но популярен для веб-продуктов, стыковки бэкэнда и фронтэнда.
- Pony [5] специальный маппер выражений из своего синтаксиса в синтаксис SQL. Изначально написан для Python для работы с объектами для задач ORM.
- LookML [6] язык запросов сервиса по визуализации Looker, свой формат, свой синтаксис. Пока мало где используемый за пределами Looker'а
- Malloy [7] ещё один язык от Looker, относительно свежий
- Prql [8] язык запросов ориентированный на преобразование данных.

И многие другие. Защитники SQL возразят что современные SQL базы давно уже поддерживают JSON объекты и функции по работе с ними, а для гибкости пользовательские функции (UDF) можно реализовывать хоть на Python, хоть через .NET, хоть на других языках в зависимости от движка СУБД.

Появится ли у SQL стандарта достойная признанная замена? Пока непонятно, но можно экспериментировать.

Ссылки:
[1] https://github.com/dcmoura/spyql
[2] https://en.wikipedia.org/wiki/Language_Integrated_Query
[3] https://www.w3.org/TR/rdf-sparql-query/
[4] https://graphql.org/
[5] https://github.com/ponyorm/pony/
[6] https://docs.looker.com/data-modeling/learning-lookml/what-is-lookml
[7] https://github.com/looker-open-source/malloy
[8] https://github.com/max-sixty/prql

#sql #nosql #queries #datatools

Я много критиковал и критикую российский федеральный портал открытых данных data.gov.ru [1], но как-то без цифр. Сейчас, когда наконец-то докачались все доступные данные 26490 наборов данных с этого портала я могу цифры привести и дать некоторую картину его текущего состояния:
1. 29 гигабайт - это общий объём данных в федеральном портале открытых данных data.gov.ru. Большая часть этих данных несжаты, после сжатия их объём составит около 15-20 гигабайт, а может быть и меньше, сжатие этого архива ещё не закончилось.
2. Из них 6.8 гигабайт - это однократный слепок данных в ZIP архиве из системы ФИАС не обновлявшийся с октября 2019 года [2]. Вернее ссылка на этот слепок на сайте ФНС [3].
3. Всего на 5 крупнейших наборов данных приходится 50% хранимого объёма. Это данные ФИАС, вакансий и юр. лиц Роструда и сведения о малом и среднем бизнесе с сайта ФНС.
4. 3839 наборов данных имеют размер менее 1 килобайта. Это 14.5% всех наборов данных, всех уровней власти. Федерального, регионального и муниципального.
5. На самом деле даже текущие цифры являются завышенными потому что многие ссылки указывают на внешние сайты и протухли из-за реформы органов власти. Наглядный пример, данные ФСТ РФ присоединённой к ФАС РФ. Набор данных "Информация об обращениях граждан" [4] указывает на сайт fstrf.ru которые редиректит на рекламу на meta.ru.
6. Аналогично наборы данных со многих сайтов были перенесены или удалены, метаданные на data.gov.ru не обновлялись. Так не работает ссылки на все наборы данных ФТС (Таможенной службы), например тут [5].

Для сравнения:
1. 950+ наборов данных из портала data.mos.ru - это 17 гигабайт несжатых данных. Частично эти наборы импортированы в data.gov.ru, но лишь частично.
2. Данные системы ЕМИСС (fedstat.ru) это 3.4 гигабайт несжатых XML файлов, данных неполными в выгрузке на сайте и проиндексированных в data.gov.ru. Если собрать их же в полных Excel файлах, экспортируя через веб интерфейс, то это около 24 ГБ
3. В системе budget.gov.ru данных по госфинансам 31 ГБ в сжатом виде. Если их распаковать то это около 200 ГБ и с оговоркой что это далеко не все данные, поскольку ряд крупнейших датасетов мы не скачивали, это слишком долго через их API.
4. 9200+ наборов данных из системы ЕСИМО (портал о мировом океане) - это 10 ГБ данных в несжатом виде. Их никогда не было на портале data.gov.ru

Это не полный список, только самое очевидное.

Все сравнения не в пользу федерального портала открытых данных. И это с оговоркой только количественного, не качественного сравнения. Если сравнивать федеральный портал по качеству документированности данных, удобства доступа, форматам и метаданным и тд. с другими порталами, то федеральный портал оказывается бесполезен. Он не выполняет функции поисковика по данным размещённых в других порталах, как минимум к особо крупным и ценным наборам данных. Технологически data.gov.ru также сильно отстал, и от того что делают зарубежом, и от лучших российских практик. Многие региональные и ведомственные порталы данных устроены куда лучше и профессиональнее.

Сейчас я изучаю можно ли хоть что-то из data.gov.ru автоматически загрузить в DataCrafter [6] или лучше работать только с первоисточниками.

Архив данных этого и других порталов данных мы также сохраняем в рамках Национального цифрового архива [7] и он будет сохранён и доступен для выгрузки.

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

Ссылки:
[1] https://data.gov.ru
[2] https://data.gov.ru/opendata/7707329152-fias
[3] https://fias.nalog.ru
[4] https://data.gov.ru/opendata/7705513068-CitizensRequest
[5] https://data.gov.ru/opendata/7730176610-p5statimpvajneytov
[6] https://data.apicrafter.ru

#opendata #dataportals #russia #datasets #datagovru