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

Во Франции рассматривают законопроект о запрете на разработку систем предсказания судебных решений [1]. В переводе на русский это звучит как:
"Идентификационные данные магистратов и сотрудников судебных органов не могут использоваться повторно с целью или в целях оценки, анализа, сравнения или прогнозирования их фактической или предполагаемой профессиональной деятельности.’

Всё это вкодировано в статью 33 [2] закона о реформе юстиции который рассматривается парламентом Франции.

В России где почти 99% всех приговоров обвинительные это не столь критично, но во Франции есть стартапы такие как Predictice [3] которые предполагают возможность формирования аналитики по конкретным судьям.

С введением ответственности в 5 лет тюрьмы все кто такую аналитику предлагают на рынке немедленно свернут свою деятельность.

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

Ссылки:
[1] https://www.artificiallawyer.com/2019/06/04/france-bans-judge-analytics-5-years-in-prison-for-rule-breakers/
[2] https://www.legifrance.gouv.fr/eli/loi/2019/3/23/2019-222/jo/article_33
[3] https://predictice.com/

#data #dataanalytics #opendata

Написал текст в рассылку на тему того зачем создаются корпоративные каталоги данных [1]. Это часть скорее теоретическая чем практическая, в неё мало практических примеров, зато много подробностей о том зачем и в какой ситуации компании, в принципе, задумываются о внедрении каталогов данных. В следующих текстах я уже подробнее разберу случаи когда точно не надо усложнять себе жизнь и заводить каталог данных который бы перестал быть актуальным и расскажу о выборе инструментов, там уже много особенностей технологических и разные инструменты решают разные задачи. А ещё точнее с разным качеством решают одни и те же задачи.

Ссылки:
[1] https://begtin.substack.com/p/corporate-data-discovery-1

#data #datacatalogs #dataengineering #dataanalytics #compliance

Оказывается Foursquare анонсировали недавно [1] Foursquare Geospatial Intelligence Platform, нигде кроме анонса, даже на их сайте в такой формулировке не находится, но из анонса видно что они позиционируют три продукта как составные части это платформы.

Это такие продукты как:
- FSQ Graph - база всех точек POI собранных и очищенных в виде данных привязанных к системе геокодирования H3
- FSQ Database - высокопроизводительная база с использованием GPU для SQL аналитики
- FSQ Studio - интерактивный инструмент визуализации данных, в нём же они публикуют некий каталог геоданных (доступен только после авторизации)

И похоже что эти компоненты будут объединены в некий унифицированный продукт.

А ранее команда Foursquare выкладывала огромный набор данных точек интереса по всему миру [2].

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

Ссылки:
[1] https://location.foursquare.com/resources/blog/products/introducing-the-foursquare-geospatial-intelligence-platform/
[2] https://t.me/begtin/6202

#geodata #dataanalytics #foursquare #opendata

У Benn Stancil очередная замечательная заметка Most graduate degrees in analytics are scams [1] на более чем актуальную тему - многочисленных магистерских программ по аналитике (применительно к данным) в колледжах и университетах. Он сам и ему в комментариях там набрасывают немало инсайтов почему эти магистерские дипломы никак не влияют на привлекательность человека на рынке или влияют в обратную сторону и являются "красным флажком".

Ключевое в его посыле в том что академические программы по дата аналитике учат тому как работать сложными методами с очень простыми и лёгкими данными в том время как в реальной жизни всё наоборот, ты работаешь очень простыми методами с очень сложными данными. Сложными во всех смыслах: собрать, связать, очистить, ощутить неполноту не поддающуюся исправлениям и тд. Причём сложная математика, за очень и очень редким исключением, возникает только в data science, а сложные методы почти вообще никогда.

И там же у него о том почему стартапы ищут тех кто поступил в Гарвард или Стенфорд, но их не волнует учился ли там человек далее, потому что экзамен в эти университеты - это как IQ тест, говорит о человеке больше чем готовность учиться далее.

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

У Benn'а много хороших текстов и это один из них, стоит почитать хотя бы чтобы просто подумать над этой темой.

Что я могу добавить так это то что хуже чем магистерские программы - это многочисленные курсы по аналитике продаваемые под соусом "увеличь свою зарплату в 4 раза". В них есть худшее от обоих миров, это про обучение как работать с очень простыми данными очень простыми методами. Чем более массовыми такие курсы являются, тем больше они являются красными флажками для любого профессионального работодателя.
Потому что их прохождение говорит следующее:
1. Вас можно обмануть заманухой о быстром повышении зарплаты через явный скам.
2. Вы готовы потратить много времени на курс по которому можно было бы учиться самостоятельно, открытых материалов множество

У Benn'а есть совет в том что важнее взять данные которые реально вам интересны и сделать самостоятельную аналитику на их основе, копаясь в них до тех пока пока не найдётся нечто реально интересное.

Я к этому совету готов присоединится и усилить. Индустриальный опыт и любопытство в работе с данными в резюме и собеседовании значительно превосходят почти любое образование и курсы.

Ссылки:
[1] https://benn.substack.com/p/most-graduate-degrees-in-analytics

#it #dataanalytics #data #thoughts

Кстати, вот такой вопрос. А какие есть хорошие инструменты и, желательно, кейсы открытых или недорогих инструментов для совместной работы аналитиков? Причём желательно для тех кто умеет Excel и не умеет SQL.

Есть JupyterLab, но он про тех кто умеет в Python и всё что касается больших данных там, всё равно, про SQL. То же самое с RStudio и RStudio совсем не про совместную работу.

И, не на облачных платформах, а так чтобы можно было развернуть локально.
Примерно с такими требованиями:
1. Подключением к наиболее популярным базам данных: PostgreSQL, Clickhouse,
2. Совместные пространства для работы от 2 до 10 человек
3. Возможность получения данных интерактивными запросами и SQL
4. Возможность экспорта данных в Excel
5. Возможность сохранять и делиться результатами внутри пространств: файлы, таблицы, дашборды (желательно)
6. Гибкое управление доступом к пространствам и ресурсам: публичные и закрытые пространства.
7. Желательно с поддержкой Jupyter Notebooks.

Что-то из этого могут инструменты вроде Yandex Datalens (есть open source версия) и SuperSet, но так чтобы всё это вместе - такого не знаю.

Поделитесь личным опытом.

#questions #dataanalytics

Про Apache Iceberg как всё более нарастающий технологический тренд в дата инженерии, ещё в декабре 2024 года Amazon добавили его поддержку в S3, а сейчас появляется всё больше число инструментов поддерживающих подключение к Apache Iceberg.

Даже удивительно как технология которой уже более 8 лет может стремительно набрать популярность при достижении определённого уровня зрелости и появлении эффективных инструментов.

Что важно знать про Apache Iceberg:
1. Это стандарт и ПО для построения озер данных созданный для преодоления ограничений предыдущих продуктов со схожими функциями такими как Apache Hudi
2. В основе Apache Iceberg технологии хранения на базе S3 и файлы Parquet. Parquet используется как контейнеры хранения данных, а S3 как хранилище данных и метаданных
3. Фундаментальная идея в реализации недорого хранилища для аналитических данных с высокопроизводительным доступом через SQL.
4. Важная причина роста популярности в комбинации: производительности, снижения стоимости и большой экосистемы из движком для запросов (query engines)
5. Серверных продуктов с открытым кодом для Apache Iceberg пока немного, кроме самой референсной реализации есть Nessie и Lakekeeper. Но много облачных провайдеров которые поддерживают такие таблицы.
6. Большая часть примеров сейчас про облачные S3 хранилища, в основном AWS. Для подключения S3 совместимых хранилищ требуется повозится
7. Применять Apache Iceberg оправдано когда у вас есть команда аналитиков умеющих в SQL и совсем неоправдано для не умеющих
8. К задачам связанным с открытыми данными этот тип дата каталога малоприменим потому что он про удобное рабочее место для продвинутого аналитика, а не про дистрибуцию данных.
9. Вообще такие продукты - это про разницу между каталогами данных, каталогами метаданных, каталогами открытых данных. Названия выглядят так словно отличий мало, а отличия огромны. Как и области применения.

#opensource #dataengineering #dataanalytics #iceberg

Полезные ссылки про данные, технологии и не только:
- Cloudflare R2 data catalog [1] свежий каталог данных на базе Apache Iceberg от Cloudflare поверх их сервиса хранения файлов R2. Хорошая новость, потому что R2 дешевле Amazon S3 при сравнимом качестве сервиса. Жду когда Backblaze запустит аналогичный сервис для их Backblaze B2
- xorq [2] читается как zork, фреймворк для обработки данных с помощью разных движков. Там и DuckDB, и Pandas, и DataFusion и др. Удобство в универсальности, но продукт пока малоизвестный, надо смотреть
- Iceberg?? Give it a REST! [3] автор рассуждает о том что без REST каталога Iceberg малополезен и, в принципе, про развитие этой экосистемы. Многие уже рассматривают стремительный взлёт Iceberg как хайп, что не отменяет того что технология весьма любопытная.
- BI is dead. Change my mind. [4] текст от Engeneering director в Clickhouse о том как меняется (может поменяться) BI в ближайшее время. TLDR: LLM + MCP + LibreChat. Чтение полезное для всех кто занимается внутренней аналитикой и использует Clickhouse
- Roadmap: Data 3.0 in the Lakehouse Era [5] изменения в экосистеме управления данными с точки зрения венчурного капитала. Простым языком для тех кто инвестирует средства в то какие новые технологии в дата инженерии появились и развиваются.

Ссылки:
[1] https://blog.cloudflare.com/r2-data-catalog-public-beta/
[2] https://github.com/xorq-labs/xorq
[3] https://roundup.getdbt.com/p/iceberg-give-it-a-rest
[4] https://www.linkedin.com/pulse/bi-dead-change-my-mind-dmitry-pavlov-2otae/
[5] https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era

#opensource #dataanalytics #datatools #dataengineering

По поводу каталогов данных на базы Apache Iceberg, я не поленился и развернул один на базе Cloudflare R2 о котором писал ранее и могу сказать что всё прекрасно работает, с некоторыми оговорками конечно:

- каталог в Cloudflare R2 настраивается очень просто, без танцев с бубном, но требует ввода карты даже если не надо платить (на бесплатном тарифе в R2 можно хранить до 10GB и бесплатный исходящий трафик). Фактически там просто одна галочка которую надо включить
- подключение к pyIceberg также крайне простое, и в части загрузки данных, и в части запросов к ним. Для всего есть примеры
- а вот для прямого подключения DuckDB к этому каталогу танцы с бубном явно понадобятся, потому что в документации нет ничего про R2, примеры только с Amazon S3 Tables и Amazon Glue, скорее всего всё вскоре появится, но пока ничего нет.
- не заработало передача параметров фильтрации в функции table.scan, что решается последующим запросом к не фильтрованным записям, но при фильтрации требует очень много памяти;
- какие-либо UI для каталогов Apache Iceberg пока отсутствуют. Вернее есть встроенные инструменты в облачных сервисах и возможность посмотреть на загруженное в open source каталогах типа Nessie и Lakehouse, но всё это встроенные интерфейсы. Явно напрашивается UI для Iceberg browser и доступ к таблицам из веб интерфейса через DuckDB WASM к примеру.
- спецификация предусматривает возможность задания метаданных таблицам и пространствам имён, но у меня это не сработало. Впрочем я бы метаданные по пространствам имён хранил бы отдельно. Как то это логичнее
- хотя UI для каталога нет, но UI для доступа к данным в нём можно обеспечить через UI к DuckDB. Хотя для DuckDB нет пока инструкций для подключения к R2, но есть примеры прямого чтения метаданных по файлу манифеста в JSON
- есть ощущение что для работы с Iceberg и подобными таблицами напрашивается кеширующий клиент. Собственно я не первый и не один кто об этом думает.

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

#datatools #data #dataengineering #dataanalytics