Кому принадлежат языки? Я имею в виду не языки программирования, а я разговорные языки. Вопрос этот одновременно философский, не без политики, и очень практичный.
Практичный потому что во многих задачах связанных с аттрибутированием объектов, будь то документы, данные, тексты, изображения и тд. можно идентифицировать язык его содержания, то далеко не всегда содержатся сведения о его географической привязке/происхождении. К примеру, если содержание на испанском языке, то как понять связан ли объект/происходит ли из Испании, а может он из Мексики, или из Чили?
Аналогично, если содержание на арабском языке, то то есть десяток стран откуда оно может происходить. И так довольно много разных языков, в первую очередь межгосударственных языков, официальных языков ООН, языков распространившихся в результате культурной/колониальной экспансии с 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
Мысли вслух о индексировании датасетов
Я как то уже писал о том что потратил в своё время немало сил и времени на то чтобы научиться создавать данные из неструктурированных источников. Развивая мысль "всё таблица" в мысль "всё данные". Самое очевидное применение - это сайты к которым пишут многочисленные парсеры, но число сайтов бесконечно, а число парсеров конечно. И писать множество парсеров для каждого сайта не хватит и тысячи жизней.
Можно ли это автоматизировать? Можно ли автоматически понимать разметку страниц и извлекать из них смысл. Самый очевидный путь - это использовать микроформаты и разметку контента через Schema.org и вытаскивать объекты из индекса Common Crawl. Что, кстати, многие и делают для задач обучения ИИ и не только и что имеет свои ограничения из-за невысокого качества этой самой разметки.
Кроме того она используется далеко не всеми. Да чего уж там, огромное число государственных, корпоративных и академических вебсайтов не используют даже базовые инструменты для индексации поисковиками. У них нет файлов robots.txt, отсутствуют sitemaps и ещё много всего.
Когда я ещё возился начальной стадии с каталогами данных, казалось бы довольно типовыми функциями, то столкнулся с этим в полный рост. К примеру, большая часть каталогов данных не поддерживают Schema.org и не индексируются тем же краулером Google не говоря уже об остальных.
Геоданные почти все вообще не попадают в поисковые индексы как датасеты, для них нет разметки, а каталоги геоданных не оперируют метаданными из Schema.org, за редким исключением.
Как собирать метаданные в таких условиях?
По сути стратегия сбора метаданных о датасетах сводится к нескольким моделям:
1. Сбор стандартизированными инструментами через API каталогов данных или дампы каталогов.
Причём этих API может быть несколько. Тот же CKAN, к примеру, поддерживает собственное API и часто имеет дамп экспорта по стандарту DCAT, а у каталогов Dataverse ещё больше вариантов их индексации, с помощью внутреннего API, OAI-PMH, Sword и других вариантов. Это то что делают некоторые поисковики, например, научные или порталы агрегаторы данных, но они используют, как правило, 2-3 стандарта для сбора метаданных.
2. Индивидуализированное извлечение метаданных
В случае крупных каталогов данных написание парсеров исключительно под них и перенос метаданных в поисковый индекс. Это резко отличается от того что делают все остальные поисковики и агрегаторы, кроме тех которые используют большие открытые данные DataCite для каталогизации датасетов получивших DOI.
3. Краулинг + Schema.org
Стандартный механизм используемый Google Dataset Search и не используемый больше почти более нигде. В самом простом сценарии реализуется через поглощение sitemap файлов и последовательное извлечение разметки Schema.org Dataset из веб страниц. С одной стороны, не зависит от используемого в каталоге ПО, с другой стороны всё равно требует ручной верификации.
4. Умный анализ структуры каталога и автоматическое аннотирование датасетов
Это самое сложное и интересное. Как определить структура сайта? Как определить структуру веб страницы на которой размещён набор данных? Это можно делать по типовым шаблонам ссылок с префиксами типовыми для наборов данных, такими как /dataset/ и тд. Ещё один признак - это ссылки на дата файлы .csv, .json, .xml и им подобные, а также ключевые слова в разметке страниц и применение ИИ для понимания этой разметки. Всё вместе это может дать возможность приблизится к умному краулеру с обучением. Где-то с верификацией человеком, а где-то, возможно, даже без неё.
За бортом остаются порталы с собственным нестандартным API через которое рендерятся данные и другие порталы со встроенным AJAX'ом. Такие случаи даже умным краулером не обработать.
Всё это мысли вслух о поиске исходя из показателей количества охваченных каталогов данных и числа проиндексированных наборов данных как приоритетных. А есть и другие показатели качества, востребованности, удобства и не только.
#thoughts
Я как то уже писал о том что потратил в своё время немало сил и времени на то чтобы научиться создавать данные из неструктурированных источников. Развивая мысль "всё таблица" в мысль "всё данные". Самое очевидное применение - это сайты к которым пишут многочисленные парсеры, но число сайтов бесконечно, а число парсеров конечно. И писать множество парсеров для каждого сайта не хватит и тысячи жизней.
Можно ли это автоматизировать? Можно ли автоматически понимать разметку страниц и извлекать из них смысл. Самый очевидный путь - это использовать микроформаты и разметку контента через Schema.org и вытаскивать объекты из индекса Common Crawl. Что, кстати, многие и делают для задач обучения ИИ и не только и что имеет свои ограничения из-за невысокого качества этой самой разметки.
Кроме того она используется далеко не всеми. Да чего уж там, огромное число государственных, корпоративных и академических вебсайтов не используют даже базовые инструменты для индексации поисковиками. У них нет файлов robots.txt, отсутствуют sitemaps и ещё много всего.
Когда я ещё возился начальной стадии с каталогами данных, казалось бы довольно типовыми функциями, то столкнулся с этим в полный рост. К примеру, большая часть каталогов данных не поддерживают Schema.org и не индексируются тем же краулером Google не говоря уже об остальных.
Геоданные почти все вообще не попадают в поисковые индексы как датасеты, для них нет разметки, а каталоги геоданных не оперируют метаданными из Schema.org, за редким исключением.
Как собирать метаданные в таких условиях?
По сути стратегия сбора метаданных о датасетах сводится к нескольким моделям:
1. Сбор стандартизированными инструментами через API каталогов данных или дампы каталогов.
Причём этих API может быть несколько. Тот же CKAN, к примеру, поддерживает собственное API и часто имеет дамп экспорта по стандарту DCAT, а у каталогов Dataverse ещё больше вариантов их индексации, с помощью внутреннего API, OAI-PMH, Sword и других вариантов. Это то что делают некоторые поисковики, например, научные или порталы агрегаторы данных, но они используют, как правило, 2-3 стандарта для сбора метаданных.
2. Индивидуализированное извлечение метаданных
В случае крупных каталогов данных написание парсеров исключительно под них и перенос метаданных в поисковый индекс. Это резко отличается от того что делают все остальные поисковики и агрегаторы, кроме тех которые используют большие открытые данные DataCite для каталогизации датасетов получивших DOI.
3. Краулинг + Schema.org
Стандартный механизм используемый Google Dataset Search и не используемый больше почти более нигде. В самом простом сценарии реализуется через поглощение sitemap файлов и последовательное извлечение разметки Schema.org Dataset из веб страниц. С одной стороны, не зависит от используемого в каталоге ПО, с другой стороны всё равно требует ручной верификации.
4. Умный анализ структуры каталога и автоматическое аннотирование датасетов
Это самое сложное и интересное. Как определить структура сайта? Как определить структуру веб страницы на которой размещён набор данных? Это можно делать по типовым шаблонам ссылок с префиксами типовыми для наборов данных, такими как /dataset/ и тд. Ещё один признак - это ссылки на дата файлы .csv, .json, .xml и им подобные, а также ключевые слова в разметке страниц и применение ИИ для понимания этой разметки. Всё вместе это может дать возможность приблизится к умному краулеру с обучением. Где-то с верификацией человеком, а где-то, возможно, даже без неё.
За бортом остаются порталы с собственным нестандартным API через которое рендерятся данные и другие порталы со встроенным AJAX'ом. Такие случаи даже умным краулером не обработать.
Всё это мысли вслух о поиске исходя из показателей количества охваченных каталогов данных и числа проиндексированных наборов данных как приоритетных. А есть и другие показатели качества, востребованности, удобства и не только.
#thoughts
Давно размышляю о том как в научной среде публикуют данные и насколько всё зависит от научной дисциплины. В разных науках подход, инструменты, культура работы с данными и их доступность существенно отличаются.
Например, особняком идёт всё что касается life sciences особенно в части биоинформатики. Практически все исследования там, или создают данные, или используют и ссылаются на данные, или то и другое. Фактически это огромная связанная инфраструктура через стандарты, идентификаторы, специальные платформы и специализированные платформы и базы данных. Собственный мир развивающийся по собственным правилам.
Второй похожий блок - это науки о Земле включая климатологию, метеорологию, геофизику, науки о морях и океанах. По внутренним ощущениям там не так всё технологизировано, вернее, несколько консервативнее, но также это собственная экосистема.
Особняком данные связанные с ИИ, одна из областей где коммерческих данных может быть больше чем научных. Большая часть из них сконцентрированы в Kaggle и Hugging Face.
И отдельная история - это экономика, социальные науки, гуманитарные науки, госуправление и тд. Там данные если публикуются то скорее рассматриваются как один из результатов научной деятельности. Вот они публикуются, или на тех же ресурсах что и научные статьи, или на специализированных научных порталах общего типа.
Всё это сильно влияет на то как собирать данные, что считать датасетами, объём собираемых данных и так далее.
К примеру, сбор научных данных из репозиториев научных результатов - это, часто, поиск иголки в стоге сена. Не все научные репозитории поддерживают API и фильтрацию результатов по типу содержимого. Из репозиториев на базе DSpace, к примеру, надо вначале извлечь всё, а потом уже процеживать их по множеству критериев чтобы вытащить датасеты. Из 1 миллиона таких научных результатов, то что является датасетами будет 50-60 тысяч записей.
Возникает ситуация когда можно собирать научные данные и в процессе приходится ещё множество метаданных других научных работ и поисковик/поисковый индекс по научным работам получается автоматически. Как бы естественно. Но делать, его, вряд ли осмысленно поскольку таких поисковиков множество.
#thoughts #datasearch #openaccess #opendata
Например, особняком идёт всё что касается life sciences особенно в части биоинформатики. Практически все исследования там, или создают данные, или используют и ссылаются на данные, или то и другое. Фактически это огромная связанная инфраструктура через стандарты, идентификаторы, специальные платформы и специализированные платформы и базы данных. Собственный мир развивающийся по собственным правилам.
Второй похожий блок - это науки о Земле включая климатологию, метеорологию, геофизику, науки о морях и океанах. По внутренним ощущениям там не так всё технологизировано, вернее, несколько консервативнее, но также это собственная экосистема.
Особняком данные связанные с ИИ, одна из областей где коммерческих данных может быть больше чем научных. Большая часть из них сконцентрированы в Kaggle и Hugging Face.
И отдельная история - это экономика, социальные науки, гуманитарные науки, госуправление и тд. Там данные если публикуются то скорее рассматриваются как один из результатов научной деятельности. Вот они публикуются, или на тех же ресурсах что и научные статьи, или на специализированных научных порталах общего типа.
Всё это сильно влияет на то как собирать данные, что считать датасетами, объём собираемых данных и так далее.
К примеру, сбор научных данных из репозиториев научных результатов - это, часто, поиск иголки в стоге сена. Не все научные репозитории поддерживают API и фильтрацию результатов по типу содержимого. Из репозиториев на базе DSpace, к примеру, надо вначале извлечь всё, а потом уже процеживать их по множеству критериев чтобы вытащить датасеты. Из 1 миллиона таких научных результатов, то что является датасетами будет 50-60 тысяч записей.
Возникает ситуация когда можно собирать научные данные и в процессе приходится ещё множество метаданных других научных работ и поисковик/поисковый индекс по научным работам получается автоматически. Как бы естественно. Но делать, его, вряд ли осмысленно поскольку таких поисковиков множество.
#thoughts #datasearch #openaccess #opendata
Про то как публикуют и работают с опубликованными датасетами расскажу про их публикацию по стандарту schema.org.
В Schema.org, наборе стандартов для публикации информации о разных объектах для удобства их индексирования, есть два типа объектов Dataset и DataCatalog. Первый описывает набор данных и включает довольно большое число атрибутов, редко заполненных полностью, но тем не менее. Второй описывает коллекцию наборов данных, как правило это наборы данных одного сайта, реже несколько каталогов данных на одном сайте.
Особенность в том что если объекты типа Dataset ещё более-менее встречаются, то DataCatalog - это безусловная редкость. К примеру, в проекте Web Data Common за 2023 год извлечено менее миллиона (839 тысяч) ссылок на страницы с объектами Dataset и совсем нет объектов типа DataCatalog. Нет не случайно, потому что даже беглая проверка по каталогам данных в Dateno registry показывает что в лучшем случае у каждого тысячного каталога данных есть эта разметка.
А вот разметка Dataset присутствует у многих каталогов, из широко известных, к примеру, Hugging Face и Kaggle. А вот к примеру, на общеевропейском портале data.europa.eu этой разметки нет, а на национальном портале США data.gov она сокращённая и даёт только минимальные атрибуты такие как название и ключевые слова, без детализации прикреплённых ресурсов или лицензий.
При этом в команде Google, полтора года назад упоминали что в их поисковом индексе Google Dataset Search есть 45 миллионов записей с 13 тысяч сайтов. Правда у них охват шире чем у Common Crawl, а также явно кроме объектов Dataset они добавляют в индекс объекты типа DataDownload, они тоже есть в спецификации schema.org и, наконец, Google Dataset Search индексирует датасеты через разметку RDFa, а по ней нет статистики из Common Crawl. В проекте Web Data Commons нет отдельной выгрузки объектов типа Dataset для RDFa.
Основных проблем со Schema.org две.
Первая в том что это добровольная разметка объектов и слишком часто ей размечают коммерческие данные и сервисы рассчитывая на продвижение в поиске Гугла. И действительно там в поиске много "мусора", данных не имеющих ценности, но проиндексированных и доступных для поиска.
Вторая в том что реально интересные каталоги данных Schema.org не поддерживают. Особенно это справедливо в отношении геоданных и геопорталы практически все используют только собственные стандарты публикации данных.
Собственно поэтому в Dateno основная индексация не через краулинг объектов Schema.org, а несколько десятков видов API.
#thoughts #datasearch #dateno
В Schema.org, наборе стандартов для публикации информации о разных объектах для удобства их индексирования, есть два типа объектов Dataset и DataCatalog. Первый описывает набор данных и включает довольно большое число атрибутов, редко заполненных полностью, но тем не менее. Второй описывает коллекцию наборов данных, как правило это наборы данных одного сайта, реже несколько каталогов данных на одном сайте.
Особенность в том что если объекты типа Dataset ещё более-менее встречаются, то DataCatalog - это безусловная редкость. К примеру, в проекте Web Data Common за 2023 год извлечено менее миллиона (839 тысяч) ссылок на страницы с объектами Dataset и совсем нет объектов типа DataCatalog. Нет не случайно, потому что даже беглая проверка по каталогам данных в Dateno registry показывает что в лучшем случае у каждого тысячного каталога данных есть эта разметка.
А вот разметка Dataset присутствует у многих каталогов, из широко известных, к примеру, Hugging Face и Kaggle. А вот к примеру, на общеевропейском портале data.europa.eu этой разметки нет, а на национальном портале США data.gov она сокращённая и даёт только минимальные атрибуты такие как название и ключевые слова, без детализации прикреплённых ресурсов или лицензий.
При этом в команде Google, полтора года назад упоминали что в их поисковом индексе Google Dataset Search есть 45 миллионов записей с 13 тысяч сайтов. Правда у них охват шире чем у Common Crawl, а также явно кроме объектов Dataset они добавляют в индекс объекты типа DataDownload, они тоже есть в спецификации schema.org и, наконец, Google Dataset Search индексирует датасеты через разметку RDFa, а по ней нет статистики из Common Crawl. В проекте Web Data Commons нет отдельной выгрузки объектов типа Dataset для RDFa.
Основных проблем со Schema.org две.
Первая в том что это добровольная разметка объектов и слишком часто ей размечают коммерческие данные и сервисы рассчитывая на продвижение в поиске Гугла. И действительно там в поиске много "мусора", данных не имеющих ценности, но проиндексированных и доступных для поиска.
Вторая в том что реально интересные каталоги данных Schema.org не поддерживают. Особенно это справедливо в отношении геоданных и геопорталы практически все используют только собственные стандарты публикации данных.
Собственно поэтому в Dateno основная индексация не через краулинг объектов Schema.org, а несколько десятков видов API.
#thoughts #datasearch #dateno
Давно пишу по кусочкам лонгрид про природу данных и наборов данных, про то как отличается их восприятие людьми разных профессий и потребностей и как от того где они применяются "плавает" это определение.
Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?
Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.
Может быть именно повторное использование и востребованность тогда является главным критерием определения набора данных? В классических определениях набора данных это, или набор таблиц, или единица измерения информации опубликованной в открытом доступе.
А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.
В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.
Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?
Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.
В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.
В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.
Всё это, отчасти, философский вопрос о том строить ли поисковую систему по данным или поисковую систему для тех кто работает с данными. Разница между двумя этими понятиями весьма существенна. И поэтому она начинается с собственного определения того что такое набор данных
#thoughts #data #datasets
Самый простой пример - это всегда ли данные машиночитаемы? К примеру, данные в виде файлов csv, json, xml и тд. всегда можно рассматривать как машиночитаемые, а, к примеру, тексты, видео и изображения нет. Но если собрать тысячи, сотни тысяч текстов или фотографий, то вот, пожалуйста, датасет для обучения в data science. То есть данные не всегда машиночитаемы?
Другой пример, конфигурационные файлы приложений распространённо имеют машиночитаемые форматы как раз те же самые json, xml, yaml и ряд других. Делает ли это их наборами данных? Вообще-то нет, потому что не прослеживается модели их повторного использования.
Может быть именно повторное использование и востребованность тогда является главным критерием определения набора данных? В классических определениях набора данных это, или набор таблиц, или единица измерения информации опубликованной в открытом доступе.
А как рассматривать API? К примеру, в геоданных массово данные доступны не в виде файлов, а в виде API по стандартам OGC или ряду проприетарных. Их принято относить к наборам данных. Но там разные API, к примеру, WFS, WMS без сомнений можно относить к data api (API для доступа к данным), а какие-нибудь WPS уже точно не data api, а процессные API для обработки данных, а WCS что ближе к не API для данных, с помогающих в работе с геоинструментами. Для аудитории специалистов по геоанализу они нужны, но как бы не данные.
В научной среде репозитории данных очень часто совмещены с репозиториями ПО, во всяком случае для репозиториев общего типа. Главная идея тут в том что без ПО, причём конкретной версии, сложно повторить эксперимент/процессы в результате которых были данные получены.
Ещё пример, опять же про не машиночитаемость. С точки зрения архивации данных важно хранить данные в любой форме за условно любой период времени. К примеру, статистический сборник 19го века. Формально не машиночитаем, по факту исследователям статистикам может быть нужен? Безусловно. На многих порталах открытых данных опубликованы тысячи таких сборников как открытые данные. Но они не машиночитаемые. В такой логике к, примеру, Библиотека конгресса США или Национальная электронная библиотека в РФ это тоже каталоги данных? Или источники данных? Даже если они не машиночитаемы?
Всё это возвращает к размышлениям о том что наборы данных - это то о чём можно говорить как об опубликованным со смыслом (publish with the purpose), с пониманием аудитории и хотя бы одного сценария их применения.
В практическом применении это напрямую затрагивает, например, то какие данные индексируют и не индексируют поисковые системы. К примеру, Google Dataset Search не индексирует геоданные, они медленно, то уверенно склоняются к поисковику для исследователей. Научные поисковики вроде OpenAIRE, DataCite или BASE с самого начала декларируют что это не только поиск по данным, а по любым результатам научной деятельности до которых просто дотянутся. Для data science поисковика нет поскольку всего два основных ресурса, Hugging Face и Kaggle.
В Dateno индексируются геоданные (гео API) и порталы индикаторов причём с расширенной трактовкой индикаторов как то что датасетом является индикатор + страна во всех случаях когда можно сделать постоянную ссылку на файл или API. Так делают многие создатели этих порталов с индикаторами уже давно. Но это тоже некая форма интерпретации исходя из потребности и поиска пользователей.
Всё это, отчасти, философский вопрос о том строить ли поисковую систему по данным или поисковую систему для тех кто работает с данными. Разница между двумя этими понятиями весьма существенна. И поэтому она начинается с собственного определения того что такое набор данных
#thoughts #data #datasets
Помучавшись немного с геоклассификацией объектов, в данном случае наборов данных, и решив эту задачу грубо, я в процессе набросал примерную структуру программного инструмента который помогал бы решать её красиво.
Не знаю когда у меня дойдут руки до того чтобы это сделать и дойдут ли вообще, работы технической, организационной и только как-то ну очень много и это хорошо:) Но если кто-то захочет такое реализовать, то может быть эта схема поможет.
Задача то довольно простая, присвоение цифровым объектам геолокации не по принципу координат или адреса, а в привязке к территории от макрорегиона/группы стран, до конкретного города/территории субрегионального уровня. В Dateno это делается через привязку всего к справочникам UN M49, ISO3166-1 и ISO3166-2. Сложности возникают в том что в каталогах данных где есть геоаннотирование чаще всего нет уникальных кодов территорий и чаще всего названия макрорегионов, к примеру, не гармонизированы.
А потребность в аннотировании есть не только к датасетам, но и ко множеству других объектов: тексты, архивы, документы, изображения и тд.
#thoughts #modelling #geospatial
Не знаю когда у меня дойдут руки до того чтобы это сделать и дойдут ли вообще, работы технической, организационной и только как-то ну очень много и это хорошо:) Но если кто-то захочет такое реализовать, то может быть эта схема поможет.
Задача то довольно простая, присвоение цифровым объектам геолокации не по принципу координат или адреса, а в привязке к территории от макрорегиона/группы стран, до конкретного города/территории субрегионального уровня. В Dateno это делается через привязку всего к справочникам UN M49, ISO3166-1 и ISO3166-2. Сложности возникают в том что в каталогах данных где есть геоаннотирование чаще всего нет уникальных кодов территорий и чаще всего названия макрорегионов, к примеру, не гармонизированы.
А потребность в аннотировании есть не только к датасетам, но и ко множеству других объектов: тексты, архивы, документы, изображения и тд.
#thoughts #modelling #geospatial
У меня довольно небольшой телеграм канал у которого чуть более 8 тысяч подписчиков и, честно говоря, я практически не вкладывался в его продвижение чем-либо кроме контента, но мне регулярно пишут с просьбой опубликовать тот или иной материал и несмотря на малость канала, похоже, нужна какая-то публичная политика с вопросами и ответами.
1. Я практически ничего не размещаю в виде коммерческой рекламы. Во первых я с канала ничего не зарабатываю и не планировал, во вторых зачем распугивать аудиторию? Поэтому на любое рекламное размещение у меня запретительный ценник. Проще не спрашивать "на каких условиях".
2. Но если Вы публикуете открытые данные или создаете продукт с открытым кодом по работе с данными и они любопытные, то я обязательно об этом захочу написать.
3. Также как если Вы проводите какое-либо интересное открытое мероприятие, особенно если оно посвящено таким редким темам как архивация цифрового контента. Напомню что про архивацию я также модерирую телеграм канал @ruarxive.
4. Или если Вы сделали интересное исследование на данных и его данные доступны под свободными лицензиями, то это также интересно и я всегда сделаю репост.
5. Я редко пишу про мероприятия где я не участвую, не участвовал или не участвовала Инфокультура или Open Data Armenia. Только если оно по каким-то причинам важно мне лично.
6. Я стараюсь писать про все случаи закрытых данных в РФ и не только, они все под хэшем #closeddata и если Вы такие новые факты знаете, я обязательно об этом напишу и упомяну.
7. То же самое в отношении недокументированных API о которых я пишу тут время от времени с оговоркой что публикация этой информации не приводит к каким-либо неприятным последствиям вроде исчезновения этих данных.
8. Время от времени я пишу про big tech, госполитику в области данных и цифры, приватность и тд. И делаю репосты из каналов где упоминают важные события.
9. Во всём остальном действует очень простое правило. К публичному телеграм каналу я отношусь как открытой записной книжке. Фильтр который я задаю себе при любой публикации захочу ли я это перечитать в будущем? Если нет, то и зачем писать?
#thoughts #contentpolicy #blogging
1. Я практически ничего не размещаю в виде коммерческой рекламы. Во первых я с канала ничего не зарабатываю и не планировал, во вторых зачем распугивать аудиторию? Поэтому на любое рекламное размещение у меня запретительный ценник. Проще не спрашивать "на каких условиях".
2. Но если Вы публикуете открытые данные или создаете продукт с открытым кодом по работе с данными и они любопытные, то я обязательно об этом захочу написать.
3. Также как если Вы проводите какое-либо интересное открытое мероприятие, особенно если оно посвящено таким редким темам как архивация цифрового контента. Напомню что про архивацию я также модерирую телеграм канал @ruarxive.
4. Или если Вы сделали интересное исследование на данных и его данные доступны под свободными лицензиями, то это также интересно и я всегда сделаю репост.
5. Я редко пишу про мероприятия где я не участвую, не участвовал или не участвовала Инфокультура или Open Data Armenia. Только если оно по каким-то причинам важно мне лично.
6. Я стараюсь писать про все случаи закрытых данных в РФ и не только, они все под хэшем #closeddata и если Вы такие новые факты знаете, я обязательно об этом напишу и упомяну.
7. То же самое в отношении недокументированных API о которых я пишу тут время от времени с оговоркой что публикация этой информации не приводит к каким-либо неприятным последствиям вроде исчезновения этих данных.
8. Время от времени я пишу про big tech, госполитику в области данных и цифры, приватность и тд. И делаю репосты из каналов где упоминают важные события.
9. Во всём остальном действует очень простое правило. К публичному телеграм каналу я отношусь как открытой записной книжке. Фильтр который я задаю себе при любой публикации захочу ли я это перечитать в будущем? Если нет, то и зачем писать?
#thoughts #contentpolicy #blogging
В новостях про смену мировоззрения Павла Дурова с анархиста на прогосударственного французского гражданина и в скором исчезновении Флибусты есть одно немаловажное общее свойство. И там, и там, критические изменения в проекте/стартапе происходит ударом по наиболее уязвимому звену - человеку, лидеру, ключевому лицу.
В случае Флибусты на создателя проекта напал рак, а в случае Павла Дурова французская полиция. В случае Флибусты механизм наследования не был предусмотрен автором, в случае Дурова даже если бы он был, в руках полиции ключевое лицо компании, и как CEO, и как, можно предполагать, основной владелец.
С одной стороны я вижу огромное число продуктов/проектов/компаний имеют число трамвая, равное единице. Это практически все частные инициативы основанные на пассионарности и харизме основателя, а не на выстроенности процессов.
С другой многие компании отказываются от использования того или иного опенсорсного или проприетарного продукта если у него всего один разработчик. В случае опен сорса это довольно легко проверить, в случае коммерческого ПО сложнее, но то что лишь один человек стоит за чем-то важным - это очень большие риски.
Морали не будет, не думаю что мир быстро поменяется, но всегда стоит помнить что мы не вечны, как в терминах свободы так и жизни.
#thoughts
В случае Флибусты на создателя проекта напал рак, а в случае Павла Дурова французская полиция. В случае Флибусты механизм наследования не был предусмотрен автором, в случае Дурова даже если бы он был, в руках полиции ключевое лицо компании, и как CEO, и как, можно предполагать, основной владелец.
С одной стороны я вижу огромное число продуктов/проектов/компаний имеют число трамвая, равное единице. Это практически все частные инициативы основанные на пассионарности и харизме основателя, а не на выстроенности процессов.
С другой многие компании отказываются от использования того или иного опенсорсного или проприетарного продукта если у него всего один разработчик. В случае опен сорса это довольно легко проверить, в случае коммерческого ПО сложнее, но то что лишь один человек стоит за чем-то важным - это очень большие риски.
Морали не будет, не думаю что мир быстро поменяется, но всегда стоит помнить что мы не вечны, как в терминах свободы так и жизни.
#thoughts
Я как раз собирался составить очередную подборку интересного чтения про данные и понял что один из текстов стоит упомянуть отдельно и поговорить про него. Это заметка Is Excel immortal? [1] от Benn Stancil. Бэн регулярно пишет интересно про данные, венчурный рынок, стартапы, аналитику и про Excel он пишет очень правильные слова.
Основная мысль которую он доносит в том что Excel вечен и раскрывает её с тем что заменить его сложно и для этого требуется сильное долгосрочное видение и команда которая готова играть в очень длинную дистанцию. Он говорит об этом другими словами, но я лично перевожу их именно так.
Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.
Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.
Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.
Но в, самом деле, какой может быть замена Excel к 2075 году?
Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее
Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.
Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.
Каким может быть Excel будущего?
1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks
Что можно добавить?
Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal
#thoughts #excel #data #datatools
Основная мысль которую он доносит в том что Excel вечен и раскрывает её с тем что заменить его сложно и для этого требуется сильное долгосрочное видение и команда которая готова играть в очень длинную дистанцию. Он говорит об этом другими словами, но я лично перевожу их именно так.
Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.
Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.
Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.
Но в, самом деле, какой может быть замена Excel к 2075 году?
Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее
Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.
Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.
Каким может быть Excel будущего?
1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks
Что можно добавить?
Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal
#thoughts #excel #data #datatools
benn.substack
Is Excel immortal?
It might not just be immortal; it might be the most immortal thing of all.
Симпатичный жанр NO SLIDES, выступления без презентаций и одноимённая конференция [1] где нет презентаций в виде слайдов, только прямая речь и демонстрация экрана. А также таблица с выступлениями прошедшей конференции со ссылками на видеозаписи на Youtube [2]. Почти всё про данные и про аналитику, есть немало интересного что посмотреть.
Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.
Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0
#thoughts #presentations #conferences
Но самое главное жанр, я вот лично им не владею в достаточной мере, у меня вместо этого буквально тысячи слайдов. Даже при том что я начиная с ковида сильно снизил публичную активность с выступлениями, но жанр NO SLIDES пробовал всего 3-4 раза за свою жизнь.
Ссылки:
[1] https://noslides.wtf/conference
[2] https://docs.google.com/spreadsheets/d/1Wx6S3qUjjSuK-VX2tkoydTZGb1LzcYnht4N_WkBwApI/edit?ref=blef.fr&gid=0#gid=0
#thoughts #presentations #conferences
noslides.wtf
NOSLIDES | Conference
NOSLIDES Conference
Хорошая статья в Системном блоке про судьбу ABBYY, их продукта Compreno и научного подхода в переводе текстов [1]. Если вкратце, то судьба печально, LLM ИИ пожирают мир. Я помню в 2010-х разговоры про Compreno как люди вовлеченные в этот проект его расхваливали, но вживую его так и не успел попробовать, а теперь уже и непонятно зачем.
А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только прогибель трансформацию компьютерной лингвистики, это и про будущее онтологического моделирования, это про судьбу проектов вроде Wolfram Alpha (похоже недолгую уже), это про применение LLM в моделировании и систематизации данных.
Вот я вам приведу пример, у нас в Dateno десятки миллионов карточек датасетов и далеко не у всех есть привязка к категориям, не у всех есть теги, не у всех есть геометки и тд.. Можно вложить усилия и категоризировать их вручную, а можно натравить одну или несколько LLM и проделать эту работу. Можно ещё на несколько задач LLM натравить и будет ещё больший эффект, вопрос лишь в цене запросов или развертывания open source LLM.
А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".
Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/
#thoughts #readings #ai
А вообще то что пишет автор про то что простые методы обученные на бесконечном объёме данных дают больший эффект - это не только про
Вот я вам приведу пример, у нас в Dateno десятки миллионов карточек датасетов и далеко не у всех есть привязка к категориям, не у всех есть теги, не у всех есть геометки и тд.. Можно вложить усилия и категоризировать их вручную, а можно натравить одну или несколько LLM и проделать эту работу. Можно ещё на несколько задач LLM натравить и будет ещё больший эффект, вопрос лишь в цене запросов или развертывания open source LLM.
А что говорить про задачи онтологического моделирования во многих исследовательских проектах. Я всё жду когда появятся научные статьи с тезисами вроде "Мы заменили команду из 10 онтологов на LLM модель и результат был не хуже".
Ссылки:
[1] https://sysblok.ru/blog/gorkij-urok-abbyy-kak-lingvisty-proigrali-poslednjuju-bitvu-za-nlp/
#thoughts #readings #ai
Системный Блокъ
Горький урок ABBYY: как лингвисты проиграли последнюю битву за NLP - Системный Блокъ
Недавно СМИ облетела новость об увольнении всех российских программистов из компании ABBYY (тоже в прошлом российской, а теперь уже совсем нет). Теперь, когда страсти вокруг обсуждения дискриминации сотрудников по паспорту улеглись, хочется поговорить о более…
Большая область работы в дата инженерии - это геокодирование данных. Причём относится это не только к датасетам, но ко всем цифровым объектам для которых привязка к конкретной геолокации необходима.
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
Например, в Dateno есть геопривязка датасетов к странам, макрорегионам и субрегионам (территориям). Она, в большей части, реализована относительно просто. Изначально полувручную-полуавтоматически геокодированы источники данных, а их всего около 10 тысяч и далее с них геопривязка транслируется на датасеты. Это довольно простая логика работающая со всеми муниципальными и региональными порталами данных и куда хуже работающая в отношении национальных порталов данных, реестров индикаторов, каталогов научных данных и так далее.
Главная причина в том что национальные порталы часто агрегируют данные из локальных, научные данные могут происходить из любой точки мира, а индикаторы могут быть как глобальными, так и локализованными до стран, групп стран и отдельных городов и территорий.
Для самых крупных каталогов данных у нас есть дополнительная геопривязка датасетов через простое геокодирование стран по внутреннему справочнику и использованию pycountry.
Но это всё даёт геокодирование, максимум, 40-60% всех датасетов и многие значимые наборы данных привязки к конкретной стране/региону могут не иметь.
Что с этим делать?
Один путь - это использовать существующие открытые и коммерческие API геокодирования такие как Nominatim, Geonames, Googe, Yandex, Bing и другие. У автора библиотеки geocoder они хорошо систематизированы и можно использовать её как универсальный интерфейс, но одно дело когда надо геокодировать тысячи объектов и совсем другое когда десятки миллионов. Кроме того остаётся то ограничение что может не быть отдельных полей с данными геопривязки у первичных датасетов. На национальном портале могут быть опубликованы данные у которых геопривязка может быть только в названии или в описании, но не где-то отдельным полем.
Вот, например, набор данных исторических бюджетов города Мальмо в Швеции на общеевропейском портале открытых данных. Там геопривязка есть только до страны поскольку сам датасет в общеевропейский портал попадает со шведского национального портала открытых данных. При этом в публикации на шведском портале открытых данных можно через API узнать что там есть геокод города Malmo через Geonames и есть он в оригинальных данных на портале данных города.
При этом геоидентифицирующие признаки могут быть разнообразны, начиная со ссылок на geonames, продолжая ссылками на справочники Евросоюза, тэгами и просто текстовым описанием на любом условно языке.
Другой путь в попытке применить LLM для геокодирования в идеале так чтобы отправить туда JSON объект с кучей атрибутов и запросом на то чтобы по нему получить код территории/страны по ISO 3166-1 или ISO 3166-2.
Что выглядит интересно ещё и потому что у всех API геокодирования есть серьёзные ограничения на число запросов и на их кеширование.
И, наконец, данные о геопривязке могут быть в самих данных датасета, но это самая дорогая операция поскольку требует уже принципиально других вычислительных усилий.
#opendata #dateno #geodata #thoughts
К вопросу о дата-инженерии и Dateno, одна из особенностей проекта в том что практически вся работа с данными построена на собственных инструментах с открытым кодом, что имеет кучу преимуществ при старте, и накапливающиеся ограничения в будущем которые уже хочется избежать.
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.
Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.
2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.
3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.
4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.
5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.
6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.
7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.
8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.
9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.
#dateno #thoughts #dataengineering #elt #etl #datapipelines
Не успела появится профессия BI Engineer как её скоро заменит AI [1]. Полезная статья в блоге Rill о применении AI для корпоративной аналитики.
Это, кстати, вполне реалистичное применение технологий. Вместо построения дашбордов использование естественного языка для получения аналитики. Правда аналитики останутся без работы даже быстрее чем многие другие профессии. Потому что ничто не мешает членам совета директоров хотья прямо на совещании делать промпты на естественном языке к языковой модели которая имеет доступ к корпоративному хранилищу и получать почти моментальные ответы.
Ссылки:
[1] https://www.rilldata.com/blog/bi-as-code-and-the-new-era-of-genbi
#bi #analytics #ai #thoughts
Это, кстати, вполне реалистичное применение технологий. Вместо построения дашбордов использование естественного языка для получения аналитики. Правда аналитики останутся без работы даже быстрее чем многие другие профессии. Потому что ничто не мешает членам совета директоров хотья прямо на совещании делать промпты на естественном языке к языковой модели которая имеет доступ к корпоративному хранилищу и получать почти моментальные ответы.
Ссылки:
[1] https://www.rilldata.com/blog/bi-as-code-and-the-new-era-of-genbi
#bi #analytics #ai #thoughts
Я тут наблюдаю время от времени как публикуют открытые данные некоторые команды, в том числе с хорошей мировой репутацией, но с небольшими знаниями по современной дата инженерии и уже какое-то бесконечное время смотрю как многие открытые и не только открытые данные опубликованы. И прихожу к мысли о том что уже классическое определение открытых данных с точки зрения 5 звезд которое формулировал Тим-Бернерс Ли [1] [2] не то чтобы устарело, но требует актуализации.
Напомню как это было сформулировано:
- 1 звезда - данные доступны онлайн в любом формате ⭐️
- 2 звезды - данные доступны хотя бы в структурированном формате, например, Excel таблица ⭐️⭐️
- 3 звезды - данные доступны в структурированном непроприетарном формате, например, CSV, KML, JSON и др. ⭐️⭐️⭐️
- 4 звезды - данные доступны по прямой ссылке и в форматах а ля RDF (RDF, Turtle, JSON-LD и тд.). То есть их не надо получать динамически через какой-нибудь экспорт из графика или системы, а можно напрямую скачать.⭐️⭐️⭐️⭐️
- 5 звезд - данные доступны как Linked data, их можно связывать с другими датасетами. ⭐️⭐️⭐️⭐️⭐️
Концепция изначально хорошая и правильная, но она неизбежно столкнулась с тем что прижилась и, то частично, только в академической среде. В первую очередь потому что Linked Data плохо связывается с большими данными в общем случае, и с тем что работа над схематическим описанием в Linked Data - это серьёзный барьер с отсутствием прямой экономической выгоды. Это не значит что связанных данных нигде нет, это лишь значит что их мало и доля не растёт. Увы.
Если посмотреть по прошествии более 10 лет с момента формулировки и с точки зрения стремительного развитие работы с данными, я бы, навскидку, описал это так. Не по звёздам, а по уровням качества данных.
- 1 уровень - данные доступны в любом виде
- 2 уровень - данные доступны и к ним есть сопровождающие их базовые метаданные
- 3 уровень - данные доступны, к ним есть метаданные и они опубликованы в машиночитаемой форме
- 4 уровень - данные доступны, к ним есть метаданные, они машиночитаемы и к ним есть документация и/или схема
- 5 уровень - данные доступны, к ним есть метаданные, они машиночитаемы, к ним есть документация и они опубликованы в современных форматах для дата инженерии (parquet) или также доступны через API или как связанные данные Linked Data
- 6 уровень - данные оформлены как дата продукт, они доступны, к ним есть метаданные, они машиночитаемы, есть документация и несколько способов/форматов их получения: простые форматы CSV/JSON, современные вроде parquet, API и SDK. Пример: датасет с данными стран доступный как CSV, как JSON, как parquet, и в виде библиотеки на Python.
Это пока что мысли навскидку, если ещё чуть-чуть подумать то можно сформулировать точнее, но основное думаю очевидно. Linked Data - это хорошо, но воспринимать это как единственно эволюционную доступность данных нельзя. Точно так же с проприетарными форматами. Когда-то Microsoft был объектом публичной атаки буквально всех кто был за открытость. Сейчас проприетарность опубликованного формата, скажем так, вторична при практическом использовании. Проблема форматов XLS/XLSX и, кстати, ODS тоже не в проприетарности, а в чрезмерной гибкости приводящей к проблемам при конвертации.
В то же время про доступность данных для дата инженеров более 10 лет назад никто особо не думал, когда обсуждали вот эту концепцию 5 звезд. Сейчас всё иначе и качество данных определяется, в том числе, тем понимаем ли мы пользователей.
Чуть позже я ещё вернусь к этой теме.
Ссылки:
[1] https://5stardata.info/en/
[2] https://dvcs.w3.org/hg/gld/raw-file/default/glossary/index.html#linked-open-data
#opendata #thoughts #data
Напомню как это было сформулировано:
- 1 звезда - данные доступны онлайн в любом формате ⭐️
- 2 звезды - данные доступны хотя бы в структурированном формате, например, Excel таблица ⭐️⭐️
- 3 звезды - данные доступны в структурированном непроприетарном формате, например, CSV, KML, JSON и др. ⭐️⭐️⭐️
- 4 звезды - данные доступны по прямой ссылке и в форматах а ля RDF (RDF, Turtle, JSON-LD и тд.). То есть их не надо получать динамически через какой-нибудь экспорт из графика или системы, а можно напрямую скачать.⭐️⭐️⭐️⭐️
- 5 звезд - данные доступны как Linked data, их можно связывать с другими датасетами. ⭐️⭐️⭐️⭐️⭐️
Концепция изначально хорошая и правильная, но она неизбежно столкнулась с тем что прижилась и, то частично, только в академической среде. В первую очередь потому что Linked Data плохо связывается с большими данными в общем случае, и с тем что работа над схематическим описанием в Linked Data - это серьёзный барьер с отсутствием прямой экономической выгоды. Это не значит что связанных данных нигде нет, это лишь значит что их мало и доля не растёт. Увы.
Если посмотреть по прошествии более 10 лет с момента формулировки и с точки зрения стремительного развитие работы с данными, я бы, навскидку, описал это так. Не по звёздам, а по уровням качества данных.
- 1 уровень - данные доступны в любом виде
- 2 уровень - данные доступны и к ним есть сопровождающие их базовые метаданные
- 3 уровень - данные доступны, к ним есть метаданные и они опубликованы в машиночитаемой форме
- 4 уровень - данные доступны, к ним есть метаданные, они машиночитаемы и к ним есть документация и/или схема
- 5 уровень - данные доступны, к ним есть метаданные, они машиночитаемы, к ним есть документация и они опубликованы в современных форматах для дата инженерии (parquet) или также доступны через API или как связанные данные Linked Data
- 6 уровень - данные оформлены как дата продукт, они доступны, к ним есть метаданные, они машиночитаемы, есть документация и несколько способов/форматов их получения: простые форматы CSV/JSON, современные вроде parquet, API и SDK. Пример: датасет с данными стран доступный как CSV, как JSON, как parquet, и в виде библиотеки на Python.
Это пока что мысли навскидку, если ещё чуть-чуть подумать то можно сформулировать точнее, но основное думаю очевидно. Linked Data - это хорошо, но воспринимать это как единственно эволюционную доступность данных нельзя. Точно так же с проприетарными форматами. Когда-то Microsoft был объектом публичной атаки буквально всех кто был за открытость. Сейчас проприетарность опубликованного формата, скажем так, вторична при практическом использовании. Проблема форматов XLS/XLSX и, кстати, ODS тоже не в проприетарности, а в чрезмерной гибкости приводящей к проблемам при конвертации.
В то же время про доступность данных для дата инженеров более 10 лет назад никто особо не думал, когда обсуждали вот эту концепцию 5 звезд. Сейчас всё иначе и качество данных определяется, в том числе, тем понимаем ли мы пользователей.
Чуть позже я ещё вернусь к этой теме.
Ссылки:
[1] https://5stardata.info/en/
[2] https://dvcs.w3.org/hg/gld/raw-file/default/glossary/index.html#linked-open-data
#opendata #thoughts #data
Написал короткий лонгрид в продолжение размышлений о качестве открытых данных и дата продуктах
#opendata #thoughts #datasets
#opendata #thoughts #datasets
Ivan’s Begtin Newsletter on digital, open and preserved government
Открытые данные как дата продукт
Почему продвижение открытых данных не означает понимания их аудитории