Поработав в избытке с данными и со смыслом публикации разной статистики, в какой-то момент напишу лонгрид на тему того как хорошо и как плохо публикуют статистику в разных странах и территориях, а пока в виде выжимки накопленные мысли. Поскольку я на эту тему несколько раз уже писал в таком формате, то где-то могу и повторяться:
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.
#opendata #api #statistics #thoughts
1. Унификация. Хорошо опубликованные статистические данные практически всегда хорошо унифицированы. У них есть так называется code lists, стандартизированные справочники территорий, видов деятельности и тд. Они унифицированы в единые форматы и с ними можно работать унифицированным образом с любым индикатором. Можно сказать что почти во всех развитых странах базы индикаторов доступны таким вот унифицированным образом. В современных национальных системах управления статпоказателями такая унификация почти всегда увязана на внедрение стандарта SMDX от 2 до 3 версии.
2. Массовая выгрузка. На английском языке она звучит как bulk download, возможность выкачать базу индикаторов целиком с минимальным объёмом усилий. Может выглядеть как 1-2 zip файла со всем содержимым, так делают в FAO, или тысячи csv/csv.gz файлов по одному по каждому индикатору, со всем содержимым индикатора и каталогом ссылок на все файлы. Так делают в Евростате и ILO.
3. Универсальный поиск. Статистические продукты бывают разные, иногда в разных информационных системах, в разных форматах, включая архивные статсборники. Универсальный поиск позволяет искать по ним всем. Начиная с интерактивных таблиц и заканчивая архивными материалами и даёт возможность найти нужные данные в нужном формате за заданный период.
4. Открытые данные по умолчанию. Практика альтернативная возможности массовой выгрузки когда статистические показатели с самого начала публикуются на стандартизированном портале открытых данных с уже имеющимся API этого портала и доступны для выгрузки через это стандартное API. Например, так делают в ЦБ Бразилии с дата порталом на базе CKAN и в Катаре с их госпорталом открытых данных на базе OpenDataSoft
5. Экспорт данных и доступ через API. Не просто экспорт в Excel, а как минимум выбор из 5-6 форматов начиная от самых простых вроде csv, продолжая форматами для Stata и других продуктов, автогенерацией кода для Python или R и наличию SDK к хотя бы паре популярных языков разработки для доступа к данным. У многих европейских порталов статданных есть неофициальные SDK, в других вроде статданных Гонконга автоматически генерируется код на Python на страницах интерактивных таблиц.
6. Технологичность. Тут можно было бы добавить и соответствие лучшим дата-инженерным практикам. Это включает: доступность данных в форматах parquet, документация к API по стандарту OpenAPI, общедоступные примеры работы через Postman или аналоги, общая документация в стиле технологических проектов с интерактивными примерами, а не в форме отчетности подрядчика по контракту в PDF. Технологичность - это про доступ и про документацию, как ни странно, но это самое актуальное для статданных.
#opendata #api #statistics #thoughts
Я уже рассказывал про геоклассификацию данных в Dateno и то что существенная фича в поиске - это возможность поиска по городам/регионам, на субрегиональном уровне. Классификация датасетов по субрегионам основана почти полностью на аннотировании каталогов данных и с этой точки зрения это довольно простая задача с понятным решением.
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
Как оказывается куда менее простой задачей является привязка датасетов к странам и макрорегионам.
Базово привязка эта привязка делается через привязку каталога данных которые, как правило, конкретными странами ограничены. К примеру, если есть национальный портал данных какой-то страны, то и данные почти всегда касаются этой страны. Но это самые простые случаи и в основном про порталы открытых данных и про геопорталы.
Сложности начинаются с научными данными. Большая их часть чёткой геопривязки может не иметь вообще, кроме ну разве что, академического института(-ов) авторов и их местонахождения. Исключение составляют редкие датасеты из наук о земле, лингвистики и ещё ряда научных дисциплин.
Другая сложность возникает со всей статистикой и производными индикаторами. Помимо стат. показателей по странам существует неимоверное число разных групп стран, от простых, до хитровыдуманных. К примеру, группы арабских стран, страны MENA, G20, G7, Андское сообщество, наименее развитые страны, страны без выхода к морю и ещё много какие. Причём, конечно, группы стран пересекаются, но не всегда входят в друг друга.
Внутри Dateno, при этом, для группировки стран используется список макрорегионов из UN M49. Разметить страны по вхождение в эти макрорегионы несложно и внутренний справочник для этого есть. А вот справочника вхождения стран в эти многочисленные группы и их пересечений - нет и его надо составлять де-факто полувручную и нет кого-то кто бы поддерживал такую живую базу данных или программную библиотеку.
Поэтому георазметка реальных мировых статистических данных - это боль, требующая большой ручной работы по привязке к макрорегионам.
Пока что отсутствие привязки каких-то датасетов к странам и макрорегионам не так критичны поскольку другие поисковики даже такого не поддерживают и есть фасеты где разметка куда хуже. К примеру, наличие информации о лицензии есть не более чем у 10% датасетов.
Тем не менее качество фасетов в Dateno влияет на пользовательский опыт и это важная задача для построения максимально достоверного поискового индекса по данным.
#dateno #statistics #indicators #geodata #geo #thoughts
unstats.un.org
UNSD — Methodology
United Nations Statistics Divisin - Methodology
Не так страшны законы как их беззаконное применение (с)
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.
Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?
По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?
Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.
Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.
У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.
Поправьте меня если я неправ.
#blogging #thoughts #telegram #regulation
По поводу свежего законопроекта по которому все телеграм каналы/блоггеры 10 тысячники должны регистрироваться в РКН, я так скажу.
Ключевое в том как его будут применять. Во первых, Россия != русский язык, а русский язык != Россия. Русскоязычные телеграм каналы могут вестись где угодно в мире и ориентироваться на теперь уже особенно широкую диаспору. Их авторы могут иметь паспорта Канады, Испании, Израиля, Армении и десятков других стран. Их авторы могут уже вообще не иметь связи с РФ. Так по какому критерию РКН будет и сможет соотносить их с Россией?
По аудитории? Телеграм не даёт её в разбивке по странам. По гражданству владельца ? А откуда бы у них такая инфа? По коду телефонного номера? Так и он может быть не российским. Более того у телеграм канала может быть много админов и много авторов, иногда десятки авторов, тут то как быть?
Ещё важно помнить что телеграм каналы - это не сайты/домены. Заблокировать их нельзя, платформа не позволяет такое.
Поэтому знаете какой самый основной критерий получается ? По размещению рекламы российских юр. лиц и ИП. Это то что может ударить по карману тех русскоязычных телеграм канало владельцев которые зарабатывают на рекламе из РФ и на аудиторию в РФ.
У меня до 10 тысяч подписчиков немало, но желания размещать рекламу как не было так и нет. Выгода от разговора с профессиональной русскоязычной аудиторией разбросанной по всему миру перевешивает рекламные деньги с лихвой.
Поправьте меня если я неправ.
#blogging #thoughts #telegram #regulation
Довольно давно хочу написать гневный пост о том куда катятся современные цифровые продукты и разработка софта в целом, в целом катятся они далеко от пользователя/клиента/потребителя. Причём чем более массовое ПО, тем хуже. Начиная от "распухания" дистрибутивов где совершенно непонятно зачем нужно ставить несколько гигабайт для данного приложения, продолжая непомерным потреблением CPU и оперативной памяти и утечками памяти и постоянной загрузкой CPU у приложений которым просто незачем это делать.
Но важнее всего это всё больший сдвиг почти всех продуктов к подписочной и облачной модели. Всё больше продуктов которые нельзя купить единожды. При том что устроены они так что в постоянном их использовании нет необходимости.
Впрочем всё это потянет на рассуждения не в одном, во многих лонгридах.
А пока же для размышления, ONCE [1] новая-старая бизнес модель которую пропагандируют 37Signals и называют её Post SaaS. Анонсируют подход к распространению их продуктов за фиксированную цену, без подписки, скрытых платежей и тд.
Дословно их принципы звучат так:
- Платите один раз, владейте навсегда.
- Мы пишем код, вы его видите.
- Мы предоставляем вам программное обеспечение, вы размещаете его у себя.
- Просто и понятно, а не корпоративно и раздуто.
- За одну фиксированную цену. Один раз.
Сейчас по такой модели они продают чат Campfile за $299 [2] однократного платежа и раздают бесплатно Writebook [3], ПО для написания онлайн книг.
Что я могу сказать. Если это станет трендом, то многие SaaS стартапы поломаются или переквалифицируются, но точно потеряют сверхдоходы.
Для квалифицированного пользователя, конечно, подходы вроде ONCE или такие как Local-first, гораздо лучше.
Ссылки:
[1] https://once.com/
[2] https://once.com/campfire
[3] https://once.com/writebook
#thoughts #business #software
Но важнее всего это всё больший сдвиг почти всех продуктов к подписочной и облачной модели. Всё больше продуктов которые нельзя купить единожды. При том что устроены они так что в постоянном их использовании нет необходимости.
Впрочем всё это потянет на рассуждения не в одном, во многих лонгридах.
А пока же для размышления, ONCE [1] новая-старая бизнес модель которую пропагандируют 37Signals и называют её Post SaaS. Анонсируют подход к распространению их продуктов за фиксированную цену, без подписки, скрытых платежей и тд.
Дословно их принципы звучат так:
- Платите один раз, владейте навсегда.
- Мы пишем код, вы его видите.
- Мы предоставляем вам программное обеспечение, вы размещаете его у себя.
- Просто и понятно, а не корпоративно и раздуто.
- За одну фиксированную цену. Один раз.
Сейчас по такой модели они продают чат Campfile за $299 [2] однократного платежа и раздают бесплатно Writebook [3], ПО для написания онлайн книг.
Что я могу сказать. Если это станет трендом, то многие SaaS стартапы поломаются или переквалифицируются, но точно потеряют сверхдоходы.
Для квалифицированного пользователя, конечно, подходы вроде ONCE или такие как Local-first, гораздо лучше.
Ссылки:
[1] https://once.com/
[2] https://once.com/campfire
[3] https://once.com/writebook
#thoughts #business #software
ONCE
Introducing ONCE
Once upon a time you owned what you paid for, you controlled what you depended on, and your privacy and security were your own business. We think it’s that time again.
Про разного рода технически сложные задачи и их решения.
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Я тут регулярно пишу про разные форматы файлов данных и могу сказать что, конечно, файловых форматов как и стандартов какое-то бесконечное количество. Когда-то я и сам делал и периодически обновляю инструменты вроде undatum [1] по работе с некоторыми из них. Так в undatum я недавно добавил работу с множеством алгоритмов сжатия обработкой файлов с минимизацией объёма их хранения и нагрузкой на оперативную память, с быстрым преобразованием из JSON lines / BSON в аналогичные форматы со сжатием xzip, zstd и др. В общем-то из-за банальных задач уменьшения объёма хранения JSON lines файлов, но с возможностью работы с ними.
Однако вот сейчас я смотрю на задачу преобразования данных в условно "диком состоянии", а то есть в большинстве популярных форматов, среди которых, конечно, лидируют CSV и Excel файлы и могу сказать что самые типовые задачи решает DuckDB, а чуть более сложные DuckDB + Polars + Pandas + предобработка некоторых форматов файлов на входе.
Причём именно в такой комбинации. Почему так?
DuckDb - даёт большую скорость в работе с табличными и большей частью иерархичных данных. Но DuckDb не умеет читать файлы Excel, ORC, ORC и тд. Их умеют читать Pandas и Polars. И частично их писать.
Из фундаментальных проблем DuckDB - непонимание кодировок кроме utf-8 для CSV файлов что решается их предобработкой. Вторая проблема в том что DuckDB не умеет определять структуру CSV файлов если заголовки не в начале файла. Это вообще не все инструменты умеют и это, в принципе, умеют немногие инструменты, особенно с открытым кодом.
CSV самый распространённый формат, плохо стандартизированный в "диком виде", слишком часто CSV файлы лежат в открытом доступе после экспорта из Excel.
Еще один недостаток DuckDB при работе с CSV файлами - это отсутствие поддержки алгоритмов сжатия за исключением GZip. Если исходить из эффективности хранения и стоимости хранения - это важный фактор. Например, несколько сотен тысяч CSV файлов в Dateno - это около 4TB данных. Хранить их в оригинальном виде неэффективно, сжатыми GZip лучше, а ещё лучше в чём то вроде zstd или даже сразу в Parquet со сжатием. Что логично поскольку эти данные статичны.
Но в итоге именно DuckDB + Polars + Pandas + предобработка + постобоработка данных + хранение первичных данных в Parquet оказывается наиболее универсальным решением в таких задачах.
Ссылки:
[1] https://github.com/datacoon/undatum
#thoughts #data #datatools #fileformats #dateno
Кому принадлежат языки? Я имею в виду не языки программирования, а я разговорные языки. Вопрос этот одновременно философский, не без политики, и очень практичный.
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 14 по 20 века и тд.
Какие-то языки, такие как английский, французский, испанский, португальский, уже давно имеют меньше носителей речи в странах своего происхождения чем в странах культурной и языковой экспансии.
Одновременно с этим есть узко национальные языки, применение которых почти всегда означает что объект связан с конкретной культурной средой находящейся в конкретной стране. К примеру, японский, малайский, индонезийский, фарси, польский, финский и другие языки имеют почти 100% атрибуцию с конкретной географической территорией.
Всё так, языки можно частично разметить и использовать матрицу сопоставления языка и страны. Но так работает не всегда. Один объект может несколько языковых и территориальных характеристик. К примеру, румынский исследователь на румынском языке пишет о геологических разломах в Иране. Относить его статью к Румынии или к Ирану? Или польский турист публикует GPX трек путешествия по Греции, описывая его на польском языке. Относить ли его к Польше или к Греции? Эти случаи не самые сложные, их можно разбирать по приоритетности геопривязки. Имея несколько геоклассификацией определять несколько или одну приоритетными к контексте.
Самое сложное, пока что, из того что я встречал - это статьи в глобальных энциклопедиях вроде Википедии. Как их классифицировать? Как разметить все статьи в выбранной вики с точки зрения геопривязки? Как вообще превратить Википедию в базу именно геоданных? Понятно что часть статей имеющих координаты или указание территорий легко сопоставляются через Wikidata, но большую часть статей простым образом не разметишь.
Всё это практические, прикладные вопросы взгляда на языки. У меня перед глазами есть несколько задач анализа больших баз данных с содержанием на разных языках где такие вопросы очень актуальны.
А есть ещё те самые философские вопросы. Кому принадлежат языки, буквально? Примерно как некоторые развивающиеся страны пытающиеся отказаться от английского или французского языка, как языка колониального наследия. Потому что в их восприятии это не универсальные языки, а языки конкретных стран Великобритании и Франции.
Или почему, к примеру, у многих есть восприятие что у России монополия на русский язык? Санкционные действия многих создателей контента пошли по пути отказа от русского языка. Хотя кроме РФ у него широкая диаспора, это разговорный язык всей Центральной Азии и значительной части Кавказа.
Национальные регуляторы и цензоры также приоритетом видят для себя языки которые они считают "своими". Что добавляет давления на глобальные проекты знаний с их стороны.
Не должны ли все языки быть достоянием человечества и наступит ли тот момент когда ни одно национальное правительство не будет "владеть" языками тех кто живёт на территории их стран?
#languages #thoughts
К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
Почему я в последнее время много думаю и пишу про геоданные?
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
Есть 4 основных типов общедоступных данных данных которые собираются в Dateno:
- открытые данные (opendata). С ними всё довольно понятно, их много, не не бесконечно много. Большая часть порталов известны, далее просто длительная методическая работа по их систематизации и сбору датасетов
- научные данные. Тут не всё так понятно, и этих данных по объёму более всего в мире, но в каждой науке свои виды каталогов данных, стандарты и тд. За пределами отдельных научных дисциплин у этих данных не так много пользы
- статистика и индикаторы. Нужны всем, чаще стандартизированы, поддаются систематизированному сбору и "расщепляются" на множество поддатасетов в привязке к конкретным странам и территориям. Много усилий требуется по агрегации национальных каталогов статистики.
- геоданные. Их много, чаще стандартизированы, но поиск и каталогизация явно недостаточны. Предыдущие попытки чаше безуспешны.
Остальные типы данных - это данные для машинного обучения, данные из коммерческих маркетплейсов или датасеты из порталов микроданных (социология), все они сильно меньше количественно.
Существенный количественный рост данных в Dateno будет от трёх категорий: научные данные, данные индикаторов и геоданные.
При этом научные данные можно _очень быстро_ загрузить из 3-4 крупных источников и это добавит +20 млн датасетов и создаст огромные пузыри данных по нескольким языкам, категориям и темам.
Данные индикаторов стремительно превратят Dateno в портал по макроэкономике/макростатистике. Их также можно загрузить +5 млн датасетов в короткое время.
А в агрегированных геоданных сейчас есть объективный "пузырь", огромное число датасетов по Германии отчего в любом поисковике по данным доля геоданных их Германии достигает 40-60% от общего числа. Если не больше.
Конечно, в какой-то момент, можно перестать думать про этот баланс и залить в Dateno несколько десятков миллионов датасетов и уже потом заниматься вопросами качества индекса. Так, например, сделали в агрегаторах научных данных типа SciDb и OpenAIRE. Там очень много мусора который создаёт количество датасетов, но который и почти не найдёшь потому что эти мусорные данные даже не подпадают под фасеты. В общем-то там ставка однозначно сделана на количество датасетов, а в этом смысле нет проблемы достигнуть того же.
#opendata #data #dateno #thoughts #geodata
В качестве мини-хобби, очень мини, я время от времени систематизирую ссылки по темам в жанре awesome list на Github с некоторой надеждой что над этими списками не я один буду работать. Надежды, как правило, не оправдываются, за редким исключением.
Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.
Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜
Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.
Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.
Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru
Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.
И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)
В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат
#opendata #datajournalism #data #digitalforensics #readings #thoughts
Список Awesome Digital Preservation, за время существования всего 14 лайков. У цифровой архивации мало фанатов, увы.
Или, например, у меня есть список Awesome Open Data software с ПО и стандартами по работе с открытыми данными. Почти всё ПО из реестра каталогов данных в Dateno, плюс ссылки на форматы файлов и стандарты обмена данными. Звездочек маловато, всего 24, не самая популярная тема.😜
Или вот Awesome Data Takeout со ссылками на сервисы получения всех своих данных из онлайн сервисов. 54 звезды, тоже, очень мало.
Для дата журналистов Awesome data journalism со списками инструментов для визуализации и не только. Набрало, 178 звезд, давно не обновлялось.
Russian Awesome Open data каталог источников открытых данных по РФ. Составлялся очень давно, как-то собрал 200 звездочек, уже практически не пополняется. Вместо него развивали datacatalogs.ru
Побольше в Awesome Forensic Tools с подборкой ресурсов в задачах цифрового дознания. Набрало 472 лайка при том что я почти не прилагал усилий по его пополнению, только один раз собрал всё вместе.
И, наконец, Awesome Status Pages собравшее 2738 лайков. Активное настолько что утомляет, сплошным потоком разработчики создают очередные сервисы проверки и публикации статусов сервисов и используют всякую маркетинговую мишуру чтобы их продвинуть. Дважды предлагали выкупить у меня эту страницу. Чувствую зря я её не продал;)
В общем-то по настоящему выстрелило только последнее, хотя списки составлять я лично люблю. Списки это же частный вид таблицы, можно ещё жанр завести. Awesome table of <something>, но в форматы Github'а или Telegram'а они плохо укладываются. Но может найдется близкий интересный формат
#opendata #datajournalism #data #digitalforensics #readings #thoughts
Я тут тоже думал про всякое применение ИИ, как в продуктовых и рабочих делах, так и общечеловеческих. Рабочие дела - это как применять ИИ для обработки, классификации, повышения качества, поиска, обогащения и тд. в работе с данными. Применений много, о них как-то в другой раз и скорее уже когда будет что показать и рассказать живое.
А вот про рабочее и полезное человечеству.
1. Не теряю всё же надежду что хоть кто-то из разработчиков сделает умный Inbox, AI ассистента нормально работающего с почтой, контактами и документами в рамках корпоративных и личных коммуникаций. Для людей живущих асинхронной жизнью это просто необходимо. Я вот не хочу сортировать почту по папкам, довылавливать спам, дозаполнять контакты после внесения, вспоминать треды переписки и так далее. Это всё совершенно точно поддаётся качественной даже не автоматизации, а глубокой трансформации без потери качества.
2. Есть огромное число малых/не национальных языков, никак не защищаемых государствами или защищаемых незначительно. Какие-то из них стагнируют, некоторые развиваются, большая часть медленно или быстро вымирает. Если по ним есть хоть какая-то устная и письменная история то AI для сохранения и обучения вымирающих языков. Не только как предмет анализа, исследований и научных работ, а по автоматизированному созданию автопереводчиков, словарей, обучающих материалов и так далее. Коммерческой идеи тут, может не быть. Подчеркну что идея тут не в автоматизации перевода, а в автоматизации создания обучающих материалов.
#ai #thoughts
А вот про рабочее и полезное человечеству.
1. Не теряю всё же надежду что хоть кто-то из разработчиков сделает умный Inbox, AI ассистента нормально работающего с почтой, контактами и документами в рамках корпоративных и личных коммуникаций. Для людей живущих асинхронной жизнью это просто необходимо. Я вот не хочу сортировать почту по папкам, довылавливать спам, дозаполнять контакты после внесения, вспоминать треды переписки и так далее. Это всё совершенно точно поддаётся качественной даже не автоматизации, а глубокой трансформации без потери качества.
2. Есть огромное число малых/не национальных языков, никак не защищаемых государствами или защищаемых незначительно. Какие-то из них стагнируют, некоторые развиваются, большая часть медленно или быстро вымирает. Если по ним есть хоть какая-то устная и письменная история то AI для сохранения и обучения вымирающих языков. Не только как предмет анализа, исследований и научных работ, а по автоматизированному созданию автопереводчиков, словарей, обучающих материалов и так далее. Коммерческой идеи тут, может не быть. Подчеркну что идея тут не в автоматизации перевода, а в автоматизации создания обучающих материалов.
#ai #thoughts