В продолжение истории про документы выложенные Минюстом США и в которых замазанный текст легко распознается я скажу вам что совершенно не удивлен и косяков госорганов и корпоратов в работе с документами и данными я знаю много, хотя и рассказывать про большую часть не могу и не хочу потому что не чувствую своей принадлежности к рынкам инфобеза и OSINT. Расскажу лишь некоторые примеры не называя имен

1. Скрытые, но доступные данные в недокументированном API
Госорган создает общедоступный портал с некоторой информацией и портал построен по уже классической трехзвенной структуре: База данных -> Слой API -> Веб интерфейс. При этом все ограничения в доступе к данным делаются только на уровне веб интерфейса, а через API вполне можно собирать записи имеющие статус "удаленные" или "черновики". Ситуация вообще не редкая и возникает от недостатка квалификации постановщика задачи, разработчиков и недостаточного тестирования

2. Скрытые данные в общедоступных материалах
Многие форматы публикации текстов, таблиц и изображений имеют свои особенности позволяющие как скрывать часть содержания так и "раскрывать" его. Пример с закрашиванием PDF файлов всем хорошо известен, а есть, к примеру, случаи когда публикуются Excel файлы со скрытыми вкладками, частенько когда публикуют статистику ее рассчитывают на более детальных первичных данных в другой вкладке, а потом эту вкладку скрывают, а не удаляют. Так чувствительные данные внутри Excel файлов становятся общедоступными. Есть и другие случаи когда одни файлы MS Office погружают в другие, а когда запускают процесс удаления метаданных он вырезает метаданные из основного контейнера, но не удаляет их из внедренных файлов. И так далее, это только то что совсем на поверхности

3. Доступное API стандартизированного ПО
Организация выбирает стандартизированное ПО для сайта, а у этого стандартизированного ПО (CMS) есть какое-то количество опять же стандартно общедоступных API о которых они могут и не подозревать. Я привожу часто в пример WordPress у которого есть открытые эндпоинты дающие возможность находить документы ссылок на которые может не быть на сайте, но сами файлы остаются. Например, если кто-то загружает документ в WordPress и потом делиться на него с кем-то по прямой ссылке, то даже если на страницах сайта этого документа нет, то в API он доступен. WordPress - это пример, кроме него есть немало других CMS и веб фреймворков имеющих такую особенность
—
Насмотревшись всего этого в больших количествах я совершенно не удивляюсь когда вижу как в очередной раз кто-то попадается на такой лаже как "затереть текст в PDF файле", думаю что еще не раз такое будет.

А я про такое пишу пореже потому что лично мне открытые данные и дата инженерия куда интереснее, кроме того рассказывая какой-либо кейс с такими утечками данных всегда велика вероятность что канал утечки исчезнет;)

#thoughts #osint #data #privacy

Полезное чтение про данные, технологии и не только:
- How to Stay Ahead of AI as an Early-Career Engineer в IEEE Spectrum о том как меняются требования к джуниорам в ИТ на фоне применения ИИ. Если вкратце то требования к кандидатам растут, хуже всего тем кто умеет не начальном уровне кодить и не вкладывался в собственное развитие многие годы. Ключевой вопрос в том как должно меняться образование?
- Congress: Protect NCAR and Climate Research союзе обеспокоенных ученых в США призывает остановить закрытие Национального центра атмосферных исследований (NCAR) США которое недавно было анонсировано администрацией Трампа
- The Hidden Price of Data статья в журнале IMF про то как измерять стоимость данных в экономике и экономическими методами, автор статьи написала книгу на эту тему, тоже полезную для понимания того как экономика данных устроена.
- Instagram CLI для тех кто любит текстовые терминалы и серьезное намерен бороться с "гниеним мозга" (brainrot) утилита для работы с инстаграмом с командной строки. Я бы пошел дальше и вместо отображения изображения сразу бы давал текстовое описание извлеченное из него с помощью LLM

#ai #instagram #data #careers #it

(Часть вторая)

3. Резкое падение стоимости создания наборов данных
Звучит парадоксально, но факт, с прогрессом ИИ агентов создать данные из существующих материалов в любой форме проще чем просить предоставить их в машиночитаемом виде. Реальные ограничения возникают только в отношении данных которые недоступны ни в каком виде, но если они всё таки есть, хоть сканами, хоть запутанными текстами, датасеты из них собираются. Это сразу же меняет несколько важных нарративов.

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

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

У меня есть живой пример подобного когда я давно откладывал задачу получения статистики из Статбанка Армении (statbank.armstat.am) из-за того что у них было поломано API и древняя версия ПО на котором он сделан. Развилка была в том чтобы:
a) Попросить у них данные (ждать пришлось бы долго и это не системное решение)
б) Заплатить фрилансеру написать парсер
в) Сделать парсер за пару часов с помощью ИИ агента

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

Условно зачем убеждать, к примеру, Пр-во Армении публиковать данные если мы и так их соберем и опубликуем на opendata.am ? Шутка, убеждать конечно же надо, но думаю что идея ясна.
—

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

#thoughts #openness #data #opendata #openaccess

Полезный ежегодный обзор баз данных в тексте Databases in 2025: A Year in Review от Andy Pavlov.
Всем кто работает с данными большого объёма будет полезно, вот ключевые выдержки:
1. Доминирование PostgreSQL продолжается. Многие экспериментируют со многими базами данных, но в продакшен всё равно используется PostgreSQL и совместимые с ним и его протоколом аналоги.
2. MCP для каждой СУБД. Похоже что тренд очевиден, MCP прикручивают к каждой СУБД каждый вендор и в этом нет ничего дурного. Больше универсальных интерфейсов полезных и нужных
3. MongoDB против FerretDB. MongoDB активно давит на FerretDB в том что воспроизведение их API и протокола нарушает их права. Такого в области баз данных ранее не было, самое близкое - это разборки Oracle vs Google из-за Java API. Тогда Oracle не удалось убедить суд в том что их права нарушены
4. Поле битвы форматов файлов. Активно идет появление новых стандартов и форматов дата файлов на замену Parquet. Я также не спроста писал про эту тему так часто, там идет сильная конкуренция и интересные технические решения

В оригинальном обзоре много ссылок и других событий

#data #rdbms #readings

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

Но это лишь один уровень оптимизации, далее вопрос в выборочной обработке данных. Почему в какой-то момент так выстрелил довольно старый формат Parquet? Помимо хорошей компресии и возможности быстрого чтения данных он ещё и дает возможность выборочного чтения и фильтрации данных. К примеру, в отношении XML файлов это уже не работает, в отношении JSON, с большими ограничениями (для JSONl да, в остальных случаях нет) и так далее. А ещё есть огромное число форматов имеющих предметное и отраслевое применение где всё что можно - это, либо считывать их в память целиком, или перебирать содержание по каждой записи.

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

В качестве регулярных напоминаний, большое количество открытого кода который я лично создавал и поддерживаю:
- iterabledata библиотека для Python по работе с любыми файлами с записями с помощью прямого их перебора и возвращением каждой записи как словаря (dict). Фактически реализация интерфейсов csv.DictReader и csv.DictWriter для десятков форматов файлов таких как JSON, JSON lines, XML, Parquet, ORC и множества более специфических и отраслевых таких как PCAP, WARC и др.
- internacia-db референсная база данных с базовыми данными по странам и по страновым блокам. Распространяется в форматах JSONL, Parquet, DuckDB, YAML. Полезно для задач обогащения данных, поиска и фильтрации результатов в территориальной привязке, сравнении стран и территориальных блоков.
- undatum это инструмент командной строки для работы с файлами со сложной иерархией так как работают с CSV файлами. Он умеет считать статистику, преобразовывать файлы, анализировать их, разрезать на части и тд. Внутри используется библиотека iterabledata и большое число форматов файлов поддерживаются
- metacrafter библиотека для Python и инструмент командной строки для работы с семантическими типами данных, используется для выявления персональных идентификаторов и иных объектов (кодов организаций, кадастровых и почтовых кодов и так далее)

А также много другого открытого кода о котором я регулярно тут пишу.

#opensource #data #dataengineering #datatools

Фонд Викимедиа анонсировал партнерство с ещё несколькими ИИ бигтехами - это Amazon, Meta, Microsoft и Mistral AI, вдобавок к уже имевшимся партнерствам с Google, Ecosia, Nomic, Pleias, ProRata и Reef Media. Можно сказать что, вполне возможно, у Википедии появится таки устойчивое финансирование и проект будет жить. Это с одной стороны, с другой стороны не превратится ли в Викимедиа в коммерческий продукт под видом некоммерческого и не оттолкнет ли это многих редакторов от вклада в её тексты? Я слишком мало знаю о том что происходит там внутри, так что интересно. Что еще интересно так то что AI крупняк, не считая X.ai с его Грокипедией, не пытается воспроизвести продукты Фонда, а заключает соглашения с ним. Полагаю что причиной может быть и то что у Фонда Викимедиа есть техническая возможность ограничивать ИИ краулеры, а одни лишь дампы Википроектов содержат только текстовый контент и не в реальном времени.

#opendata #API #wikipedia #data #ai

Data Engineering Design Patterns свежая бесплатная книга от ORelly профинансированная стартапом Buf по дата инженерии.

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

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

А я смотрю на книгу и думаю не написать ли мне самому книжку по data discovery, но объективно понимаю что столько сейчас операционной работы что не до этого.

#dataengineering #readings #data

В DuckDB добавили поддержку формата Vortex, это такой специальный формат хранения данных который разработали в компании SpiralDB и передали в Linux Foundation в августе 2025 г.Это такой специально оптимизированный формат хранения данных который может быть компактнее и быстрее Parquet.

Собственно в статье есть примеры бенчмарков Parquet версии 1 и версии 2 и Vortex. Собственно запросы к Vortex через DuckDB быстрее примерно в 1.5 раза чем к Parquet версии 1 (самая распространенная версия).

Выглядит это оптимистично, к тому же постепенно Vortex начинают поддерживать и другие инструменты. Так что не только Parquet актуален как формат хранения данных.

#opensource #data #datatools #dataengineering

Open Semantic Interchange (OSI) свежий индустриальный стартап описания данных в задачах дата аналитики. Подготовлен Snowflake вместе с Alation, Atlan, BlackRock, Blue Yonder, Cube, dbt Labs, Elementum AI, Hex, Honeydew, Mistral AI, Omni, RelationalAI, Salesforce, Select Star, Sigma и ThoughtSpot.

Официально опубликован он был ещё в сентябре 2025 г.

Явный акцент в нём на инструментах BI и спецификация явным образом определяет то как описывать таблицы для анализа данных и ИИ инструментов.

Чем-то он напоминает и пересекается со стандартами Frictionless Data (он про файлы), спецификацией Open Lineage, Data Description Specifications (DDS) (используется в среде IBM) и ряд других.

Новые спецификации это хорошо, насколько хороша эта поймем по мере её внедрения.

#opensource #openspecs #data

talk-data.com чей-то симпатичный пэт проект в дата инженерной тусовке. Автор себя явно не выпячивает, но сделал базу лекторов и выступления про данные (современные дата инженерные и дата аналитические инструменты). Там спикеров 3000 из 713 компаний по 104 событиям и по 4483 темам. Например, 98 выступлений про DuckDB или 38 выступлений про Polars

Выглядит полезно для всех кто хочет погрузиться в одну или несколько тем по данным.

#data #events