Я достаточно давно не публиковал данные над которыми работаем мы сами, а не просто выложенные где-то ещё. Поэтому пора уже разместить такой набор данных - это данные по социально ориентированным НКО в репозитории datacrafter-sonko [1]

Это одновременно пример работы datacrafter'а [2] с кодом выгрузки данных в datacrafter.yml и сам набор данных в виде слепков первичных данных выкачанных с портала Минэка РФ data.economy.gov.ru и уже в обработанном виде в виде файла sonko_fin.bson.gz в котором данные Минэка обогащены частью данных с портала openngo.ru. Той частью что относится к классификации НКО.

Несколько лет назад мы в openngo.ru разметили все НКОшки по 320 классификационным категориям среди которых есть православные НКО, госНКО, НКО относящиеся к структурам ДОСААФ и ещё много каких. Все это время не доходили и не доходят руки загрузить это на сайт openngo.ru в основном потому что общественного заказчика на некоммерческую аналитику мы так и не нашли.

Поэтому эти классификационные признаки я сейчас перенес на эту малую базу СОНКО из 45+ тысяч организаций. Там получилось 213 категорий по которым размечены приtмрно 2/3 всех организаций.

Так что если хотите поработать с данными в формате MongoDB, про социально ориентированные НКО и проанализировать их, то в репозитории код, вот тут финальные дампы [3] в которые добавлены статус в ЕГРЮЛ, статус в Минюсте, классификационные группы (orglists) к которым относится организация.

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

Вопросы лучше писать в issues репозитория или по контактам указанным в репозитории, предварительно представившись кто Вы и что делаете.

Я чуть позже также выложу некоторые метрики и аналитику.

Ссылки:
[1] https://github.com/datacoon/datacrafter-sonko
[2] https://github.com/apicrafter/datacrafter
[3] https://github.com/datacoon/datacrafter-sonko/tree/main/output/dump/openngo

#ngo #datasets #govngo #opendata

«Торговля страхом»: как нас убедили, что всем нужна система распознавания лиц

https://youtu.be/hxxVFdUPoN4?t=1

«Если ничего не нарушаешь, нечего и боятся» — так говорят безгрешные люди, которые никогда не переходили улицу на красный свет. Но какую цену нам всем придется заплатить за удобные технологии?

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

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

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

Гости подкаста – Иван Бегтин, директор АНО «Инфокультура», эксперт в области открытых данных, и Саркис Дарбинян, киберадвокат, со-основатель «Роскомсвободы».

Давно хочу написать про обработку документальных структурированных данных в NoSQL. Я затрагивал эту тему в англоязычной заметке Future of NoSQL in Modern Data Stack [1], но проблема, гораздо глубже, она связана со спецификой данных.

Классические наиболее распространенные подходы к обработке/очистке данных сейчас - это, или SQL запросы, или датафреймы вроде того же pandas, или инструменты вроде OpenRefine и Trifacta. Они все оперируют простыми плоскими таблицами и умеют по этим таблицам проводить относительно простые операции: переименовать колонку, разделить её, создать новую на основе имеющейся, изменить значение и тд.

В SQL это делается относительно просто, с учётом ограничений языка, конечно. В OpenRefine, Trifacta - это внутренние индексы для табличных данных и встроенные функции или внешний код. А для pandas и подхода через датафреймы - это код Python (или похожий в других языках).

Для данных с вложенными документами вроде тех что сериализуются в JSON или хранятся в MongoDB так не получится. При переносе из MongoDB в pandas вложенные объекты автоматически не нормализуются. А если их нормализовать, то потом назад в СУБД не перенести так просто. Будут потери, или в данных, или в возможности их обработки. И так со всем остальным, OpenRefine и аналоги также такой тип данных не поддерживают, только "уплощают" их в таблицы, но обратно могут отдать уже только плоскую таблицу.

Как работать с JSON подобными структурами? Например, используя языки запросов у NoSQL баз данных предварительно загрузив данные в саму СУБД.

А тут у нас начинают возникать уже ограничения другого рода. Ключевая NoSQL СУБД MongoDB не поддерживает большую часть операций по модификации данных иначе как запуском операций по перебору значений запроса итератором forEach. Самый банальный пример - это преобразование значений в полях в нижний или верхний регистр. То что в SQL решается простейшей командой UPDATE MyTable SET MyColumn = UPPER(MyColumn)
для MongoDB требует команды вроде
db.MyTable.find([find_criteria]).forEach(function(doc) {
db.MyTable.update(
{ _id: doc._id},
{ $set : { 'MyColumn' : doc.MyColumn.toUpperCase() } },
{ multi: true }
)
});

Похоже со многими другими операциями по преобразованию данных которые просты в табличных структурах, особенно в SQL и крайне затруднены в MongoDB. При том что MongoDB наиболее популярная NoSQL СУБД.

Можно ли такие операции проводить не в MongoDB, а, например, в другой NoSQL базе? Их поддерживает, например, ArangoDB. Там также есть циклы на выполнение операций, но они могут проводится внутри движка СУБД. Например, вот так.

FOR u IN MyTable
UPDATE u WITH {
MyColumn: UPPER(MyColumn)
} IN MyTable

Будет ли это быстрее чем если эту операцию делать извне? Непонятно, требует проверки.

Альтернативой использования СУБД является написание аналога pandas DataFrame для не-табличных документов. У Python есть библиотека glom [2] которая позволяет что-то подобное и может быть расширена, но имеет довольно серьёзные ограничения по объёмам данных и по скорости их обработки.

В итоге, если честно, я до сих пор не вижу оптимальный бэкэнд для data wrangling для NoSQL. Лучший кандидат как СУБД - это ArangoDB, но без интенсивного тестирования это неточно.
Наиболее эффективным способом обработки JSON/JSONlines всё ещё является программная обработка за пределами СУБД и инструментов ручного data wrangling вроде OpenRefine.


Ссылки:
[1] https://medium.com/@ibegtin/future-of-nosql-in-modern-data-stack-f39303bc61e8
[2] https://glom.readthedocs.io

#data #datatools #thoughts #nosql #dataengineering #datawrangling

В продолжение того о чём я писал тут в телеграм канале про обработку данных [1] написал короткую технологическую заметку NoSQL data wrangling [2] про проблему обработки NoSQL данных и о дефиците инструментов позволяющих обрабатывать JSON/JSON lines.

Правда заметка пока в формате размышлений вслух, готового решения у меня нет. Пока нет.

Ссылки:
[1] https://t.iss.one/begtin/4255
[2] https://medium.com/@ibegtin/nosql-data-wrangling-50b5a2898a83

#datatools #datawrangling #dataengineering