Ivan Begtin. Страница 60
3903
@begtin
I am focused on Open Data, Procurement, e-Government, Open Government and other tech stuff
-
Ivan Begtin
В блоге SeattleDataGuy (консультант по дата платформам Ben Rogojan) две публикации про The Baseline Data Stack [1] [2] о том что нет универсального стека ьтехнологий для данных и есть много разных вариантов сборки. Можно сделать полностью на открытом коде, можно на основе ведущих продуктов и можно сделать только на базе облачных продуктов. Реальность, как правило, где-то посередине, достаточно вспомнить Gitlab у которых смешаны open source Airbyte и dbt, коммерческий Fivetran, хранилище в Snowflake и собственноручно написанный Meltano, уже выделенный в отдельную компанию/стартап/продукт. Основная мысль в том что под разные задачи - разные решения и это, конечно, так оно и есть. И я также вижу тренд как вначале появляется/давно существует коммерческий продукт, потом кто-то делает open source продукт который воспроизводит ключевые/значимые возможности этого коммерческого продукта и далее _очень быстро_ получают венчурное финансирование на создание облачного продукта на базе этого open source. Раньше такое тоже было, но сейчас всё ускоряется. Меня, кстати, поражает насколько медленно развиваются Яндекс.Облако и облачные сервисы VK. Фактически если ты работаешь с современным стеком технологий то зарубежные платформы почти безальтернативны. Почти, потому что всегда есть "танцы с бубном", но в целом это так. Вообще в области работы с данными "импортозамещения" очень мало, только замена на open source. Ссылки: [1] medium.com/coriers…b7d49e85 [2] medium.com/coriers…26d8f2f1 #data #readings #thoughts -
Ivan Begtin
Я много раз писал про такое явление как executable papers [1] [2] [3] о том как меняется создание научных статей в сторону написания тетрадок с кодом интегрированных или сопровождающих научный текст. К этому хочу дополнить ещё один похожий и важный проект Executable books (исполняемые книги). Создание интерактивных книг/справочников/руководств по общему стандарту и с сохранением структуры именно книги. Довольно большое сообщество в Github - Executable book [4] вот уже несколько лет как создаёт Jupyter Book [5], специальный движок позволяющий писать руководства используя тетрадки Jupyter Notebook и предоставляя возможность создавать контент пригодный к публикации и с экспортом в HTML, PDF и другие форматы. У авторов собрана большая галерея примеров [6], больше всего примеров с описанием open source пакетов по работе с данными. Авторы же даже создали своё расширение для языка Markdown под названием MyST - Markedly Structured Text для более удобного написания технической документации [7]. Executable books и их продукты происходят из научной среды, с командой из 3-х университетов и большим сообществом и поддержкой Alfred P.Sloan Foundation. На мой взгляд у них есть явно недооценённый коммерческий потенциал. Удобных онлайн сервисов по написанию технической документации и руководств не так много. Есть Readme.io, Gitbook и ещё несколько, со своими достоинствами и недостатками, но не почти не включают часть связанную с "исполнимостью текста". Ссылки: [1] https://t.me/begtin/2147 [2] https://t.me/begtin/2607 [3] https://t.me/begtin/3386 [4] https://github.com/executablebooks [5] https://jupyterbook.org [6] executablebooks.org/en/late…ery.html [7] https://myst-parser.readthedocs.io #executablebooks #executablepapers #opensource #data #datadocumentations #datatools Ivan Begtin В Nature статья о переосмыслении научных статей, и перевод их в формат "исполняемых статей" (executable papers) [1] идея в том что электронная научная публикация должна иметь формат аналогичный цифровым записным книжкам таким как Jupyter Notebook или Wolfram Notebook и должна включать всё необходимое, исходный код и данные для её перепроверки. Эта концепция не нова, и давно присутствует, например, в Codalab [2], но пока ещё она не стала всеобъемлющей. Автор приводит пример с его статьей с анализом данных температуры земли, опубликованными данными и кодом [3]. А также множество примеров проектов готовых шаблонов воспроизводимых проектов [4]. Основной и важнейший, можно сказать инновационный, подход в том что научная статья/публикация - это не документ, а некий интерактивный открытый цифровой продукт, включающий как описания и выводы, так и исходный код, данные и формулы организованные таким образом чтобы можно было максимально упросить работу по воспроизведению результатов. Определение из CodaLab звучит как…
-
Ivan Begtin
У Бэна Стэнсила, основателя и руководителя аналитиками в стартапе Mode, замечательная заметка в его рассылке, с рефлексией о том как компании сейчас потребляют данные и как это возможно в будущем [1]. Основной посыл заметки в том что "фронтэнд разваливается" и приводит в пример десятки разных способов донесения данных через дашборды, тетрадки, сервисы визуализации, разные виды, формы и ориентации BI продукты и так далее. Идея в том что можно ли сделать открытый продукт к которому разные формы потребления данных можно было бы добавлять плагинами? По аналогии с Wordpress'ом и другими аналогичными экосистемными продуктами. Идея интересная, созвучная многим, включая меня. Хотя я пока и не чувствую что разваливается именно фронтэнд и конечное потребление данных, скорее современный стек данных превращается в набор для сборки, а для кого-то и в паззл где своими силами ты делаешь только то что не можешь собрать из кубиков. Или делаешь то что хочешь продать/продавать. Отсюда и растущий запрос не просто на дата-инженеров, а на платформенных дата-инженеров, а может уже пора ввести понятие data-constructor ? Когда я сейчас проектирую стартап и продукт по анализу и/или/или не обработки данных, я, как и многие, не мыслю категориями разработать его с нуля. Я смотрю на open source и облачные продукты и понимаю что: вот тут для ELT можно взять вот это, вот тут для BI вот это, вот тут для хранилища вот это, вот тут для сбора данных в реальном времени вот это, для пользовательского интерфейса вот это и так далее. А рассылка Бэна весьма популярна в среде аналитиков и дата инженеров, всячески его рекомендую. Ссылки: [1] benn.substack.com/p/busin…he-front #data #thoughts #reading #dataengineering #bi -
Реклама
-
Ivan Begtin
Про формат Parquet я многократно писал и давал ссылки, а вот сравнение от Databricks его же с CSV [1]. Если кратко то CSV проигрывает Parquet по всем статьям, сравнение проводилось в экосистеме Amazon AWS: - экономия при хранении данных на 87% - в 34 раза быстрее отрабатываются запросы - на 99% меньше данных надо сканировать - финансовая экономия до 99.7% Недостаток Parquet'а для человекочитаемости компенсируется появлением инструментов для GUI и командной строки которые эту проблему снимают. Она, вообще не так значима как кажется. Лично я считаю что статистику, многие другие данные с временными рядами и иные большие наборы данных которые сразу берут в работу аналитики, можно и нужно публиковать сразу в Parquet. Это даёт не только экономию в хранении, но и сильно облегчает работу аналитиков. Тем более что многие инструменты вроде Power BI и Tableau их его поддерживают. Ссылки: [1] https://databricks.com/glossary/what-is-parquet #fileformats #data #parquet -
Ivan Begtin
Кстати по итогам моего прошлого опроса/голосования о том о чём я пишу, большинство проголосовавших, как оказалось, заинтересовано в материалах про приватности. Постараюсь добавлять об этом больше публикаций. Хотя мои лично самые любимые темы - это технологии работы с данными и доступность/открытых данных. А вот, как ни странно, международные практики мало кому интересны. Может быть, правда, это искажение инструмента голосования где нельзя проголосовать за несколько вариантов. #votes #polls 
-
Ivan Begtin
Нужно ли создание в России '_blank' rel='noreferrer nofollow' href='http://api.gov.ru'>api.gov.ru ? anonymous poll Конечно! Пусть Минцифра его создаст, наконец – 50 👍👍👍👍👍👍👍 70% Нужно, но на госорганы надежды нет, скорее как частный проект – 11 👍👍 15% Не нужно, пусть госорганы сами задокументируют API к своим системами и на этих системах разместят документацию – 3 ▫️ 4% Никому не нужно, некому пользоваться – 3 ▫️ 4% Что? Где? Что такое API? Ничего не понимаю – 2 ▫️ 3% Мне лень отвечать, я просто хочу посмотреть ответы других – 2 ▫️ 3% 👥 71 people voted so far. -
Ivan Begtin
О данных, веб-сайтах и том как с ними работают. Я рассказывал что веду архивацию госсайтов, в том числе самописными инструментами, которые архивируют данные из открытых API которые веб-краулеры не поддерживают. Такая утилита есть APIBackuper для сфокусированной архивации и ещё для 5 популярных CMS у которых такое общедоступное API есть по умолчанию. Некоторые владельцы сайтов это API по умолчанию сразу отключают, но у большинства оно доступно и через него можно скачивать весь тот же контент что есть на сайте, только быстрее, удобнее и автоматически. Но бывают и вопиющие случаи. Не буду называть конкретный орган власти/госорганизацию, но у них на веб-сайт предусмотрена подписка на рассылки СМИ. Подписка реализована встроенными средствами CMS и, барабанная дробь, открытые интерфейсы этой CMS отдают данные о всех подписчиках. К счастью, их там не так много, чуть более 200 человек и данные там хоть и персональные, но не самые чувствительные, только email+ФИО+факт подписки, но картина показательная о том как организована работа с данными в госорганах. В данном случае даже не знаю что лучше, написать им чтобы исправили, или забить на них и пусть сами разбираются с последствиями (там правда, ничего серьёзного нет, обычный контентный сайт). Таких случаев много, много случаев публикации чувствительных данных, просто доступа к данным и тд. Госзаказчики чаще всего просто не знают на каких инструментах создана их инфраструктура и поэтому так много недокументированных API у госсайтов и государственных информационных систем. Это вопрос не только культуры работы с данными, но и обычной технологической культуры и полнейшее отсутствие централизованного аудита и мониторинга государственного технологического сектора. #tech #government #governmentit #privacy #leaks -
Ivan Begtin
Для тех кто ищет больших данных и побольше, Academic Torrents [1] раздает 83ТБ открытых данных, в основном для научного применения - в data science и не только. Например, там есть свежий слепок Wikidata в 109ГБ и множество климатических датасетов, датасетов по распознаванию изображений и многого другого. Ресурс полезный как для поиска интересного так и для публикации собственных больших данных. Ссылки: [1] https://academictorrents.com #opendata #datascience #openacces -
Ivan Begtin
Metadata Guardian [1] [2] свежая утилита для Python, делающая практически то же что и наш движок по идентификации полей и даже теми же самыми способами, только с акцентом на PII (Personally Identifiable Information). Поставляется в виде утилиты командной строки, поддерживает Snowflake, AWS, GCP, MySQL и файлы Avro, Arrow, ORC и Parquet. Все правила оформлены прям как и у меня в виде YAML файлов [3] с регулярными выражениями. Правила также разделяются на те которые применяются к названиям колонок и те которые применяются В общем это хорошая утилита, разница между ней и тем что делаю я тоже есть: 1. Правил нашем классификаторе кратно больше. В metadata guardian их около 20, в нашем боте их уже более 150. 2. В нашем классификаторе правила и идентификаторы разделены. Много разных правил могут указывать на один и тот же идентификатор. Например, отдельное правило для почтовых индексов и их написания на английском языке и общее для всех, такое как "postindex" или "postcode" и отдельно для написания на русском "почтовый_индекс" или "pochtoviy_indeks". Это позволяет разделять правила по контексту языка. 3. Это особенность нашего движка, контекстное и языковое разделение правил. Можно задать фильтр и подгрузить любые правила, а не только преднастроенные. 4. В Metadata Guardian используют регулярные выражения, у нас вместо них три типа правил: прямое сравнение, внешние функции и конечные автоматы на PyParsing через которые также можно запускать регулярные выражения. 5. У нас в движке предусмотрена доп. валидация данных после определения. Для этого можно указать внешнюю функцию. 6. Пока наш движок работает с базовым объектом как словарь для Python (python dict), а в качестве входного потока принимает СУБД MongoDB, JSON lines и CSV. А Metadata Guardian нацелен на базы и форматы для облачного применения и для data science. Причины отличий в том что MG создан для идентификации PII, а наш Data Classifier для задач более общих и, более того, как основа для оценки качества данных и их обогащений. Напомню что наш движок можно потестить вот тут @DataClassifierBot как телеграм бот и скоро будет API. Тем не менее на Metadata Guardian стоит посмотреть и попробовать, потому что направление движения правильное. К тому же он хоть и меньше может, но более production ready и стыкуется с СУБД. Ссылки: [1] medium.com/@floria…9c24f1b1 [2] https://github.com/fvaleye/metadata-guardian [3] github.com/fvaleye…les.yaml #metadata #data #datatools #privacy #opensource -
Ivan Begtin
Стартап Canvas [1] делает возможность превращать работу с данными из технической в визуальную задачу, сделав удобный интерфейс по визуализации и работы с данными в СУБД через веб интерфейс. Сейчас поддерживают Redshift и Snowflake как облачные СУБД и Postgres. Работа с таблицами очень напоминает Google Spreadsheets или Airtable, но, при этом, визуально сформированные таблицы можно увидеть и в виде SQL запросов. Сами данные они не хранят, только дают интерфейс над ними. Берут по $100 в месяц за редактора данных в месяц. Подняли инвестиций в $4.2M и думаю что у них хорошая перспектива быть купленными одним из крупных облачных провайдеров, потому что выглядит как очень хорошее дополнение к облачным СУБД. Ссылки: [1] https://canvasapp.com #startups #dataviz #spreadsheets 
-
Ivan Begtin
В России обсуждали кейс директора XSolla уволившего кучу людей по итогам автоматизированного анализа, а в США и Европе во всю обсуждают риски появления ИИ боссов (AI Bosses) на примере Amazon'а и других компаний. Когда за твоим рабочим процессом следит ИИ и "всё докладывает кому надо". В Tribune статья именно об этом [1] и в России такие кейсы тоже есть. Как говорится все ждали большого брата от гос-ва, а на деле первыми внедряют их работодатели. Чем более оцифруема твоя работа, тем более вероятно что у тебя будет AI Boss. Ссылки: [1] tribunemag.co.uk/2022/01…eillance #ai #aiethics -
Ivan Begtin
Как государства предоставляют данные и сервисы бизнесу? Через систематизированные каталоги API. Эти каталоги иногда интегрированы в порталы открытых данных, но чаще создаются отдельно потому что доступ через API почти всегда требует авторизации и удобного интерфейса тестирования и документации. Такие каталоги API есть во многих странах, кроме Франции и портала api.gouv.fr который я ранее упоминал, они также есть: - В Индии API Setu apisetu.gov.in [1] - 1343 точки подключения всех уровней власти - В Бразилии Catálogo de APIs Governamentais www.gov.br/conecta/catalogo [2] - более 40 точек подключения - В США API Data api.data.gov [3] - сотни API по единому ключу - В Великобритании api.gov.uk [4] более 70 API на едином портале - В Австралии api.gov.au [5] доступно 16 API И так далее. Это список именно национальных каталогов API, а ещё много отдельных API для доступа к конкретным данным. Предоставление API это взаимодействие властей с цифровым бизнесом, например, перепись США доступна через API и многие сервисы обогащения данных в США используют его для получения данных в реальном времени. Ссылки: [1] https://apisetu.gov.in/ [2] https://www.gov.br/conecta/catalogo/ [3] https://api.data.gov/ [4] https://www.api.gov.uk [5] https://api.gov.au #opendata #openapi #api #government -
Ivan Begtin
Профессор Albert Sanchez-Graells в заметке Let’s get real about AI’s potential to end corruption in procurement [1] пишет о применении ИИ для выявления коррупции при госзакупках, ссылается на его же статью Procurement Corruption and Artificial Intelligence: Between the Potential of Enabling Data Architectures and the Constraints of Due Process Requirements [2] и обозначает ограничения у алгоритмов ИИ, в первую очередь ограничениях в данных, их качестве, доступности ретроспективных данных и их оцифровке и юридических сложностях. Заметка и научная статья весьма полезные с системной точки зрения автоматизации анализа госрасходов и того что в зарубежной практике называют Red Flags. критерии определения рисков связанных с госрасходами, обычно договорами и контрактами. Здесь важно помнить что кроме чисто технических проблем, вроде доступности и стандартизации данных, есть проблемы этические и политические. Этические в том что огульные обвинения в коррупции, от ИИ, могут подорвать репутацию вполне приличных людей и компаний, на самом деле ничего не нарушавших, а политические в том что ИИ может автоматически выявить то что человек побоится. Лично я практически прекратил расследования на базе госконтрактов, но не от того что нарушений или подозрений стало меньше, а от того что это журналистская деятельность, а уже выросла плеяда дата-журналистов научившихся работать с официальными источниками данных. Хотя, конечно, мало что от расследовательской журналистики в России сейчас остаётся. Но есть важные особенности. Алгоритмические системы определения нарушений хорошо работают при грамотно спроектированной и работающей системе закупок, а российская система по 44-ФЗ и частично по 223-ФЗ не про качество работы, а про модель гарантированного наличия нарушений у госзаказчиков. Когда сама система выстроена так что, вне зависимости, честные ли госзаказчик и поставщик или коррумпированные, и так и так совершают одни и те же нарушения, то система анализа от формальных нарушений начинает давать сбои. Об этом я могу говорить и писать ещё долго, в последние годы тема госфинансов меня интересует скорее с точки зрения сбора данных. И в качестве небольшой рекламы я добавлю что мы поддерживаем общественный проект Госрасходы (clearspending.ru) с данным госконтрактов, наша команда создавала и продолжает поддерживать проект Счетной палаты Госрасходы (spending.gov.ru), вернее я покинул СП, а команда продолжает его развивать. А также у нас есть коммерческий проект APICrafter.ru где можно подключиться к данным системы госзакупок России через API и с коммерческой поддержкой. Это уже не только данные о госконтрактах, но также данные по поставщикам, заказчикам, планам закупок, закупкам, отчетам и всем остальным сведениям. А в каталоге DataCrafter (data.apicrafter.ru) в том числе есть архивные данные контрактов, сведения из региональных систем закупок и сопутствующие данные. Ссылки: [1] www.open-contracting.org/2022/01…curement [2] papers.ssrn.com/sol3/pa…pers.cfm #opendata #procurement #ai -
Ivan Begtin
В рубрике интересных наборов данных The World Loanword Database (WOLD) [1] в виде базы заимствованных слов. Создатели из Института эволюционной антропологии им. Макса Планка собрали базу слов которые одни языки заимствуют из других на основе 41 источника публикаций исследователей лингвистов. В основном в базе слова заимствованные небольшими и вымирающими языками из языков более распространённых, но для специалистов в лингвистике и это может быть интересно. Общий объёмы базы невелик, около 3.5 мегабайт в ZIP архиве и 15 МБ в распакованном виде. У Института им. Макса Планка есть плеяда проектов по компьютерной лингвистике с открытыми данными [3] включая такие проекты как: The World Atlas of Language Structures, Glottolog, Tsammalex, Dictionaria и многие другие. Во всех случаях данные публикуются, либо на сайте проекта, либо на портале Zenodo. Ссылки: [1] https://wold.clld.org/ [2] https://wold.clld.org/download [3] https://clld.org/ #opendata #data #openaccess #liguistic -
Ivan Begtin
В 2020 году Норвежский потребительский совет выпустил исследование о том как дейтинговые приложения собирают персональные данные и торгуют ими [1]. Несмотря на то что представители компаний всегда утверждали что это обезличенные данные, это оказалось не совсем так, и некоторые из них получили штрафы. Так штраф в $11,7M был наложен на компанию создавшую приложение Grindr для знакомства людей нетрадиционной ориентации. А полгода назад случилась весьма показательная история с высокопоставленным католическим священником, монсеньёром Jeffrey Burrill, в США. Католическое издание The Pillar провело расследование включавшее покупку данных у одного из брокеров данных (его имя они не называют), но называют изначальный источник данных и это как раз приложение Grindr. Издание сопоставило анонимизированные данные пользователей и идентифицировало именно Jeffrey Burill как посетителя многочисленных гей-баров. В исследовании особенно подчеркивается легальность получения этих данных в США. Обо всём этом написали Washington Post [2], уже после того как священник подал в отставку, а The Pillar многие обвинили в скандальных методах проникновения в частную жизнь о чём они даже написали пространный текст объяснения баланса личной жизни, общественного интереса и их позицию [3]. Процесс определения человека по анонимизированным данным называется повторной идентификацией (data re-identification). Об этом явлении хорошая статья в Википедии [4]. В некоторых странах, например, в Австралии даже пытались законодательно ввести уголовное преследование за повторную идентификацию [5], но законопроект тогда не прошёл. На сайте The Markup в статье 2020 г. When Is Anonymous Not Really Anonymous? [6] та же проблема описывается с большим числом примеров. Например, одно из исследований показало что 87% жителей США можно идентифицировать по полу, дате рождения и почтовому индексу. Всё это о том что утечки "анонимизированных данных" или раскрытие государством анонимизированных данных о людях не даёт гарантии невозможности повторной идентификации, возможности обогащения данных, особенно ранее полученных незаконными способами и последующего нанесения людям ущерба. А история вроде истории католического священника показывает что и без государства и без сливов данных, часто жизнь человека может зависеть от того какими приложениями он пользуется и кому его данные продаются. Ссылки: [1] fil.forbrukerradet.no/wp-cont…v1.0.pdf [2] www.washingtonpost.com/technol…s-church [3] twitter.com/jdflynn…/photo/1 [4] en.wikipedia.org/wiki/Da…fication [5] www.aph.gov.au/Parliam…/17bd055 [6] themarkup.org/ask-the…nonymous #privacy #anonymity #mobileapps #stories -
Реклама
-
Ivan Begtin
Продолжая вчерашний пост про засекречивание распоряжений Правительства, публикую диаграмму выпуска приказов Минцифры. Если в Правительстве число "закрытых" (непубличных, ДСП...) распоряжений было на уровне 8-9% с тенденцией к росту, то в Минцифре открытых приказов всего... 6%. Остальные 94% - ДСПшные и иные ограниченного распространения документы. А вы говорите открытость... PS. Спасибо Ивану Бегтину за предоставленные цифры 
-
Ivan Begtin
Знаете ли Вы что в каталоге нормативных документов Минюста РФ [1] сложно/затруднено искать документы Минцифры РФ? В перечне принявших органов в разделе "Нормативные правовые акты федеральных органов исполнительной власти" Минцифры нет в списке (может и ещё чего нет, всё не проверял). По органу власти невозможно найти документы. Хотя по ключевым словам "цифровой" или "цифрового" в названии документа некоторые документы находятся, около 60. В общем выгрузить или получить все документы Минцифры из системы Минюста нельзя. Интересно почему? Приходится смотреть в других местах и сетовать что в России нет единой нормальной системы НПА. Ссылки: [1] pravo-search.minjust.ru/bigs/po…tal.html #legalit #government #data #laws 
-
Ivan Begtin
Кстати, не могу не похвастаться, что более всего из всех площадок где я что-либо писал, получалось на Quora, англоязычной площадке вопросов и ответов. Я там был особенно активен в 2016-2017 годах [1] и до сих пор мои ответы смотрят по 2000 просмотров в неделю, в общем-то там и потребление контента не новостное с резким всплеском, а постоянное. В последние годы как-то стало больше других дел, но в целом приятно что всё ещё читают. А Quora неплохой источник не только ответов, но и ссылок на разного рода продукты/проекты в области открытости и данных. Ссылки: [1] https://www.quora.com/profile/Begtin-Ivan #quora #reading #data 