Подборка ссылок про данные, технологии и не только:
- 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

Полезное чтение про данные, технологии и не только:
- SQL Vs. NoSQL: Choose The Most Convenient Technology [1] полезное чтение для начинающих о разнице между SQL и NoSQL базами данных. Почему для начинающих? Потому что в реальности выбор зависит от того насколько выбранный продукт соответствует компетенциям команды и выбранному технологическому стеку.
- Evolution of data companies [2] о том как развиваются компании на рынке инструментов работы с данными.
- Penpot - The Open-Source design & prototyping platform [3] открытая и свободная альтернатива Figma. Для тех кто хочет проектировать приложения и не хочет платить сервисам за эту возможность
- Devops excercises [4] каталог ресурсов, документов, вопросов и ответов и упражнения для DevOps'ов. Полезно, как начинающим, так и углубляющим знания.
- ZincSearch [5] альтернативная поисковая система декларируемая как более быстрая чем Elastic
- The Production-Grade Data Pipeline [6] о том почему трубы данных надо делать сразу как продукты и о рисках накопления технического долга

Ссылки:
[1] https://pub.towardsai.net/sql-vs-nosql-choose-the-most-convenient-technology-4506d831b6e4
[2] https://medium.com/coriers/the-evolution-of-data-companies-167ff4b65e1d
[3] https://github.com/penpot/penpot
[4] https://github.com/bregman-arie/devops-exercises
[5] https://github.com/zinclabs/zinc
[6] https://dataproducts.substack.com/p/the-production-grade-data-pipeline

#opensource #datatools #data #readings #dataengineering

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

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

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


#thoughts #rants #opinion #dataengineering

В Великобритании Министерство юстиции (российский аналог - Министерство внутренних дел) анонсировало [1] подготовку стратегии по работе с данными, data strategy, которую пока описали одним слайдом из 3 пунктов на этом же слайде.

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

Ссылки:
[1] https://mojdigital.blog.gov.uk/2022/08/30/becoming-a-truly-data-led-justice-system/

#opendata #data #uk #datastrategies

В рубрике интересного чтения про данные, технологии и не только:
- The Vector Database Index [1] сравнение нескольких векторных баз данных. Полезно для понимания как устроен этот рынок и того между чем можно и стоит выбирать. Не все продукты рассмотрены, но достаточно многие. Для тех кто не знает или подзабыл - векторные базы данных используются для построения нейросетей и, например, для поиска по подобиям, поиска аномалий и пользовательских рекомендаций и скоринга. Этот рынок растёт и в нём довольно много инвестиций уже есть и приходит.
- What I've learned from users [2] свежий текст Пола Грэхема о том чему научился от основателей стартапов профинансированных Y Combinator. Как и все тексты автора - почитать его стоит. Пишет он редко и всегда по делу.
- Modern COBOL Tooling [3] для тех кто хочет погрузится в вечность или даже не знаю как это описать, но набор инструментов в современных средах разработки и курсов по COBOL.
- Instant MD5 Collisions [4] всё ещё используете хэш функции MD5? А их уже подменяют моментально, на примере пары картинок и большой текст.
- Faster CPython ideas [5] репозиторий идей по ускорению языка Python реализованного на С. Python никогда не отличался высокой скоростью, но был и есть гибок. Интересно то как думают о его ускорении.
- SQLite: Past, Present, and Future [6] об устройстве и судьбе СУБД Sqlite. Важно потому что не стоит недооценивать масштабов её использования особенно в мобильных устройствах и IoT.
- Document Foundation starts charging €8.99 for 'free' LibreOffice [7] этот момент настал и LibreOffice в магазине для Mac'ов продается за 8.99 евро. Обещается что сумма пойдет на разработку ПО. Напомню что LibreOffice - это ответвление (форк) OpenOffice.

Ссылки:
[1] https://gradientflow.com/the-vector-database-index/
[2] http://paulgraham.com/users.html
[3] https://www.openmainframeproject.org/all-projects/cobolprogrammingcourse
[4] https://github.com/corkami/collisions
[5] https://github.com/faster-cpython/ideas
[6] http://muratbuffalo.blogspot.com/2022/09/sqlite-past-present-and-future.html
[7] https://www.theregister.com/2022/09/20/libre_office_macos_fees/

#opensource #readings #rdbms #data

В рубрике интересных наборов данных открытое API проекта Metaculus [1] по краудсорсингу предсказаний.

Проект позволяет регистрировать предсказания, собирать оценки от пользователей и измерять точность предсказаний.

Все эти сведения доступны в формате JSON через API проекта [2].

Всего в проекте более 1 миллиона предсказаний [3] что очень даже немало.

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

Ссылки:
[1] https://www.metaculus.com
[2] https://www.metaculus.com/api2/
[3] https://twitter.com/fianxu/status/1569537658103431168

#opendata #predictions #datasets #API

The right to privacy in the digital age

Свежий доклад представителя по правам человека ООН [1]. Документ короткий, на 17 страниц. Там про всё, взломы телефонов правительствами (спецслужбами), массовую слежку, ограничения в использовании шифрования, нарушениях прав человека и так далее.

То о чём писали многие, но изложено сжато и в докладе ООН.

Ссылки:
[1] https://documents-dds-ny.un.org/doc/UNDOC/GEN/G22/442/29/PDF/G2244229.pdf?OpenElement

#privacy #reports

Полезное чтение про управление командами данных. Onboarding for Data teams [1] о том как собирать команды дата специалистов и погружать их в работу. Онбоардинг - это быстрое погружение в работу. Много полезных советов и рекомендаций.

Мне понравилась идея в том что новичок в первый день должен сделать коммит в промышленный код (production). Что-то в этой идее есть.

Ссылки:
[1] https://seattledataguy.substack.com/p/onboarding-for-data-teams

#data #datateams

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

Поддерживает стандартный интерфейс датафреймов а-ля Pandas и позволяет выполнять комплексные запросы.

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

Ссылки:
[1] https://www.getdaft.io/

#data #datatools