Регулярное полезное чтение про данные, технологии и не только:
- IKEA’s Knowledge Graph and Why It Has Three Layers [1] о том как устроен граф знаний в ИКЕА с точки зрения хранения данных. Актуально для всех кто работает с похожими системами и проектами
- Presto Parquet Column Encryption [2] о том как устроено колоночное шифрование в файлах Parquet в Presto, со ссылками на другие продукты, тексты, описания и тд. про это же.
- MLPerf Results Show Advances in Machine Learning Inference [3] обновление результатов MLPerf по сравнению моделей машинного обучения
- Unsung Saga of MLOps [4] про MLOps в Walmart, в основном про всякое организационное, и тем интереснее.
- In conversation with AI: building better language models [5] научная статья о том как могут развиваться способы коммуникации человека и ИИ, с оглядкой на языковые модели, но с рассмотрением других способов коммуникации также.

Ссылки:
[1] https://medium.com/flat-pack-tech/ikeas-knowledge-graph-and-why-it-has-three-layers-a38fca436349
[2] https://prestodb.io/blog/2022/07/10/presto-parquet-column-encryption
[3] https://mlcommons.org/en/news/mlperf-inference-v21/
[4] https://medium.com/walmartglobaltech/unsung-saga-of-mlops-1b494f587638
[5] https://www.deepmind.com/blog/in-conversation-with-ai-building-better-language-models

#data #machinelearning #readings

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

Аналогично со специалистами которые меняют специализацию. Сложно интервьюировать людей претендующих на позиции не совпадающие с их предыдущим опытом. Недостаточно просто перечислить 5-10-20 языков программирования, фреймворков и баз данных чтобы показать свои знания.

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

Я собрал курсы и программы не на русском языке которые могу порекомендовать, которые прохожу сам и на которые обращаю внимание в резюме которые читаю․ Всё это с акцентом на данные и инженерию данных:
- DataCamp - интерактивная образовательная платформа с акцентом на data science, data engineering, data analytics и языки Python, R и Julia. Организовано очень грамотно, с постепенным повышением сложности и так что не пройти курсы просто невозможно. Стоит максимум $180 за годовую подписку, много бесплатных курсов.
- dbt courses - курсы по инструменту dbt по инженерии данных, бесплатные, дают погружение в то что такое ELT, Modern Data Stack, обработку данных и тд. Требуют базовых знаний программной инженерии, SQL и хотя бы одной SQL СУБД.
- Scylla University - бесплатные курсы по NoSQL СУБД Scylla. Для понимания что такое NoSQL, как устроена Scylla (аналог Apache Cassandra) и многие другие NoSQL связанные темы. Курсов много, все бесплатные.
- Pluralsight - большая платная платформа курсов, я рекомендуют там Core Python, но кому-то может быть интересно что-то другое. Платформа стоит небольших денег, $160 в год, многое бесплатно. Например, тестирование знания. Я раз в полгода тестирую там своё знание Python.
- Redis University - подборка бесплатных курсов от компании Redis по продуктам их Redis Stack включая NoSQL базу данных и другие продукты. Redis - это большая NoSQL экосистема, курсы там весьма полезны для тех кто хочет погружаться в эту тему. Но требует, базовых навыков программирования

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

#data #education #studies

Кстати, есть такой вопрос, а в какой момент Sber AI стал AI Forever, а ru-gpt переместился в Ереван?

Поясню, в 2020 году на Хабре была заметка в блоге Сбербанка о том что Сбер выложил русскоязычную модель GPT-3, она была выложена на Github'е в аккаунте sberbank-ai по ссылке sberbank-ai/ru-gpts. Сейчас эта ссылка редиректит на аккаунт ai-forever без какого-либо упоминания Сбера с указанием что это НКО (non-profit) в Армении.

Какой реальный статус этой модели, Сбербанк её реально передал какой-то НКО под развитие, тогда где анонс, или это мимикрия под то чтобы не заблокировали на Github'е, тогда почему не перенесено на какую-то другую платформу в России?

#opendata #datasets #sberbank #questions #ai #gpt3

В рубрике интересных стартапов Mem.ai [1], система для личной и персональной самоорганизации. Главное отличие от других подобных продуктов - это декларируемое подключение ИИ Mem X [2] через автоматическое понимание написанного текста и подсветку ресурсов, тем и участников. Хорошо для автоматического написания контекста, структуризации заметок о встречах, задач для команды и тд.

Существуют с 2019 года, подняли инвестиций на $5.6M [3].

Один из тех продуктов которому, мне лично, не хватает опенсорс альтернатив. Потому что хранить личные заметки в облаке не то чтобы совсем плохо, но чревато тем что потом можно всё потерять.

Ссылки:
[1] https://get.mem.ai
[2] https://get.mem.ai/mem-x
[3] https://www.crunchbase.com/organization/mem-labs/company_financials

#ai #startups #notes

К вопросу о том как исчезает официальный контент государственных инициатив приведу в пример сайт открытого пр-ва open.gov.ru [1]. Сайт перестали обновлять с 2018 года, после смены состава фед. правительства. Какое-то недолгое время он был онлайн, а с января 2021 года у него "протух" сертификат который ещё и был сделан с поддержкой только TLS 1.0 [2] поэтому сейчас рядовому пользователю его не открыть.

При этом он остался в проиндексированным в Гугле [3], а с помощью консольных и программных инструментов его можно сохранить и получить конкретную страницу, но это, видимо, тоже пока что временно.

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

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

Ссылки:
[1] https://open.gov.ru
[2] https://www.ssllabs.com/ssltest/analyze.html?d=open.gov.ru
[3] https://www.google.com/search?q=site%3Aopen.gov.ru

#digitalpreservation #openness #opengov #archives

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

Для тех кто не знает, OpenAlex - это открытый продукт базы данных ссылок на научные публикации созданный НКО OutResearch на базе Microsoft Academic Knowledge Graph, большого набор данных опубликованного компанией Microsoft для помощи в развитии инструментов анализа библиографических данных.

DBLP - это проект университета Триера существующий с 1993 года и ведущий крупнейшую в мире систематизированную базу научных публикаций в области компьютерных наук.

Интеграция даёт возможность увидеть категории/концепты к которым относится данная публикация, а ранее уже DBLP интегрировали с базами Semantic Scholar, Crossref и OpenCitations.

Пока это всё происходит на уровне веб-интерфейсов, но, ничто не мешает использовать открытые данные DBLP [2] что автоматизации анализа в нужных областях.

Лично мне в DBLP всегда не хватало возможности подписаться на новые статьи по конкретной теме, исследователю, исследовательскому центру, ключевым словам, но это то что можно делать в других сервисах вроде Semantic Scholar.

Я читаю на регулярной основе ключевые научные работы по цифровой архивации, открытым данным и "пониманию данных" (семантическим типам данных, идентификации шаблонов и тд.). Удобные инструменты для поиска таких публикаций очень помогают.

Ссылки։
[1] https://blog.dblp.org/2022/08/31/openalex-integration-in-dblp/
[2] https://dblp.uni-trier.de/xml/

#opendata #research #openaccess #datasets

Если вам кажется что только в Вашей стране, где бы Вы ни были, всё делают через одно место и это не голова, то это не так. Например, Chaos Computer Club (CCC), старейшая хакерская команда в Германии, пишут о том что германская компания Gematik отвечающая за информатизацию здравоохранения плохо понимают в информационной безопасности того что они делают [1].

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

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

Это не единственный "косяк" от Gematik, но достаточно яркий.

А если вернуться к российским реалиям, то для авторизации на российском портале ЕМИАС [2] достаточно номера карточки медицинского страхования и даты рождения. После этого доступны данные о записях к врачам, рецептам и направлениям (хорошо хоть не самой медкарты).

Это означает что любой врач в системе ОМС имеющий доступ к Вашему анамнезу может увидеть всю эту информацию на сайте ЕМИАС и Вы никогда об этом не узнаете. Но, всё интереснее. В медицинских полисах последние 6 цифр - это и есть дата рождения. Если у кого-то есть номер вашего мед полиса и даже если этот кто-то не знает даты Вашего рождения он/она может получить доступ к этому же личному кабинету.

Страны разные, проблемы похожие.

UPD: Речь, в первую очередь, про московский портал ЕМИАС. Как организовано в других регионах надо разбираться отдельно.

Ссылки:
[1] https://www.ccc.de/updates/2022/erezept-mangelhaft
[2] https://emias.info/

#security #privacy #germany #russia

Я достаточно давно не публиковал данные над которыми работаем мы сами, а не просто выложенные где-то ещё. Поэтому пора уже разместить такой набор данных - это данные по социально ориентированным НКО в репозитории 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

Подборка ссылок про данные, технологии и не только:
- PySearch [1] поисковик по документации библиотек Python поддерживающий запросы на естественном языке. Пока скорее простые запросы вроде "take a tensor and adds a dimension" [2], но автор обещает и более глубокое применение NLP алгоритмов.
- The Difficult Life of the Data Lead [3] тяжела и неказиста жизнь простого дата лида, руководителя дата команды. О чем автор и пишет, с картинками о том сколько времени надо проводить в коммуникациях, а не в технической работе. Полезно для тех кто думаете о своей карьере в этом направлении
- Want a DS project? There's health insurance data out there [4] в США на поляну дата-сайентистов привалило радости, вышел закон требующих от медицинских организаций и мед. страховщиков публиковать цены в больницах в машиночитаемых форматах. Автор пишет о том где эти данные взять и что с ними можно делать. Это реально 100TB+ хорошо структурированных данных!
- What is Data Engineering? Part 1. [5] обзор инженерии данных в блоге Pragmatic Programmer. Что называется, найди себя, хороший текст для описания этой роли и возможности себя с ней идентифицировать.
- How does column encoding work? [6] в блоге dbt как работает кодирование данных в колоночных структурах вроде файлов Parquet и некоторых СУБД. Текст в предверии их конференции Coalesce и запуска dbt semantic layer [7] по работе с метриками.


Ссылки:
[1] https://www.pysearch.com
[2] https://www.pysearch.com/search?q=take+a+tensor+and+adds+a+dimension&l=pytorch
[3] https://mikkeldengsoe.substack.com/p/the-difficult-life-of-the-data-lead
[4] https://counting.substack.com/p/want-a-ds-project-theres-health-insurance
[5] https://newsletter.pragmaticengineer.com/p/what-is-data-engineering-part-1
[6] https://roundup.getdbt.com/p/how-does-column-encoding-work
[7] https://www.getdbt.com/blog/dbt-semantic-layer/

#readings #data

По поводу свежего постановления российского федерального Пр-ва [1] по поводу того что все госорганы и госструктуры должны использовать только домены в зонах .RU, .SU и .РФ я не могу не напомнить что пока жареный петух в жопу не клюнет, поп не перекрестится. В Инфокультуре (@infoculture) мы уже несколько лет ведем реестр всех госдоменов [2]. Может не самый полный, но полней его нет. Там почти все домены ФОИВов, части РОИВов, некоторых бюджетных учреждений - это 7711 записей, включая не работающие сайты, "потерянные" и разделегированные домены и так далее.

Так вот только у нас в базе 16 доменов в зонах .COM, .NET, .ORG, .INFO. Реально их, конечно, больше потому что есть 150+ тысяч госучреждений.

Я тут не могу в очередной раз не кинуть камень в адрес Минцифры РФ которые за все эти годы так и не сподобились инвентаризацию госдоменов провести.

Мы то свой реестр ведём для цифровой архивации содержания сайтов, а им теперь надо инвентаризировать для мониторинга. Или так, очередное постановление фед. Пр-ва для галочки, а исполнять планов не было?;)

P.S. Не могу не добавить, кстати, что внимательно перечитав бюджетных учреждений там не обнаруживаю. Только органы власти и только для электронной почты. Что только снижает качество этого проекта постановления

Ссылки:
[1] https://www.rbc.ru/technology_and_media/14/09/2022/632080c59a7947878f0bedc1
[2] https://github.com/infoculture/govdomains

#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] в контексте цифровой трансформации.

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

Ссылки։
[1] https://www.osp.ru/os/2022/03/13056266

#opendata #opengov #data

Конгресс США официально открыл API к базе законопроектов [1], а также опубликовал исходный код с примерами работы с этим API [2].

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

Удивительно скорее то что у них это заняло так много времени, поскольку общественные базы данных и API к данным конгресса существуют давно [3]. Но, как бы то ни было, значит число общественных проектов на этих данных только вырастет.

Ссылки:
[1] https://blogs.loc.gov/law/2022/09/introducing-the-congress-gov-api/
[2] https://github.com/LibraryOfCongress/api.congress.gov/
[3] https://projects.propublica.org/api-docs/congress-api/

#opendata #us #congress #api #legislation

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

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

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

#datatools #datawrangling #dataengineering

Регулярное чтение про данные, технологии и не только:
- Complexity: the new analytics frontier [1] в блоге dbt о том что обновление внутренних аналитических моделей у них в компании занимает до 21 часа и о том что сложность работа с аналитическими данными - это новый фронтир. С подробностями проблем. Несомненно актуально
- Data Glossary [2] Airbyte выпустили словарик по инженерии данных с определениями и с графом связей между понятиями и вопросами. Хорошая база знаний для тех кто погружен или погружается в эту тему. В основу взяли тему Quartz [3] для генератора статических сайтов Hugo. Я думал сделать похожий словарь, у меня даже более 200 терминов накопилось, но ребята опередили.
- How python programmers save the environment (by making python run faster)? [4] текст о том как ускорять Python с отсылкой на прошлогоднюю публикацию [5] о том что Python, Perl и Ruby сжигают более энергии в компьютерах. Сравнение, конечно, так себе. Можно задаться вопросом о том сколько нервных клеток экономят развитые языки программирования и насколько эффективнее разработка. Вообще приход климатической повестки в разработку ПО может оказаться неожиданным.
- Go MySQL Server [6] реализация MySQL совместимого SQL сервера написанного на Go и декларируемого как хорошо расширяемого. Делает его команда Dolt, распределенной Git-подобной СУБД. Есть шанс что станет интересным продуктом однажды.
- How Fivetran fails [7] Benn Stancil рассуждает о том что SaaS ETL инструмент Fivetran скоро потеряет лидерство и его заменят Airbyte и владельцы крупнейших облачных хранилищ данных Microsoft, Amazon, Google и др. Не без основательное утверждение. Про Fivetran в России мало знают, а в США - это гигантский стартап с большой корпоративной базой клиентов.
- Connectors catalog [8] таблица в Airtable со списком сервисов к которым есть коннекторы у облачных ETL движков таких как Fivetran, Hevo Data, Airbyte, Whaly, Stitch и тд. Кстати, давно замечаю что российских сервисов в этих движках не было и нет. Есть ли рынок для отдельного ETL движка здесь? Может быть, но скорее нет, потому что нет облачных хранилищ как драйвера таких сервисов

Ссылки:
[1] https://roundup.getdbt.com/p/complexity-the-new-analytics-frontier
[2] https://glossary.airbyte.com
[3] https://quartz.jzhao.xyz/
[4] https://laszlo.substack.com/p/how-python-programmers-save-the-environment
[5] https://medium.com/codex/what-are-the-greenest-programming-languages-e738774b1957
[6] https://github.com/dolthub/go-mysql-server
[7] https://benn.substack.com/p/how-fivetran-fails
[8] https://airtable.com/shrQMzHOF4hWfdTBG/tblA6Jm3vnbGCyLeC/viw2hJa6PanS8GtQa

#datatools #data #readings #opensource #dataengineering