Разное, дата инженерное:
1. При работе с JSON lines (NDJSON) по прежнему MongoDB поглощает любой скормленный файл, DuckDB лучше умеет считывать схемы и Clickhouse включая Clickhouse-local оказался самым "капризным". Для ситуаций данных с большим числом NoSQL данных и множеством схем clickhouse применим ограниченно и надо делать специальный инструментарий/надстройку чтобы иvмпортировать уже по предраспознанным схемам, что сильно замедлит импорт на больших файлах. По прежнему очень не хватает высокопроизводительного инструмента для работы с NoSQL.
2. DuckDB примечателен в плане й удобства разработчика, доступных примеров и документации, расширяемости и тд. DuckDB - это очень крутой инструмент. Причём можно смотреть на него как на вещь в себе и подспорье для аналитика, а можно как один из компонентов создаваемого дата-продукта.
3. Ценность Parquet'а начинаешь понимать когда взаимодействуешь с командами публикующими плохо документированные CSV файлы с кучей ошибок из-за того что они в CSV файлы упихивают иерархические структуры из первоисточника. Такие файлы или очень неудобно или совсем нормально не импортируются стандартными средствами. Parquet должен быть форматом для данных по умолчанию, остальное производится из него быстро.
4. Clickhouse или DuckDB были бы хорошими инструментами для замены движка внутри OpenRefine. Но, похоже, этого не дождаться. Разве что, сделать всё же, инструмент для headless data refine, я такой когда-то смастерил для MongoDB, но скорость там оставляет желать лучшего. Скорее это был прототип для оценки возможности реализации.
5. Классические ETL/ELT инструменты для геоданных не то чтобы совсем непригодны, но не заточены ни разу. Создавать / адаптировать существующие ETL движки под них? Или использовать что-то целенаправленно созданное в этой области? Пока не очень впечатляет всё что я видел.
#notes #dataengineering #data #datatools
1. При работе с JSON lines (NDJSON) по прежнему MongoDB поглощает любой скормленный файл, DuckDB лучше умеет считывать схемы и Clickhouse включая Clickhouse-local оказался самым "капризным". Для ситуаций данных с большим числом NoSQL данных и множеством схем clickhouse применим ограниченно и надо делать специальный инструментарий/надстройку чтобы иvмпортировать уже по предраспознанным схемам, что сильно замедлит импорт на больших файлах. По прежнему очень не хватает высокопроизводительного инструмента для работы с NoSQL.
2. DuckDB примечателен в плане й удобства разработчика, доступных примеров и документации, расширяемости и тд. DuckDB - это очень крутой инструмент. Причём можно смотреть на него как на вещь в себе и подспорье для аналитика, а можно как один из компонентов создаваемого дата-продукта.
3. Ценность Parquet'а начинаешь понимать когда взаимодействуешь с командами публикующими плохо документированные CSV файлы с кучей ошибок из-за того что они в CSV файлы упихивают иерархические структуры из первоисточника. Такие файлы или очень неудобно или совсем нормально не импортируются стандартными средствами. Parquet должен быть форматом для данных по умолчанию, остальное производится из него быстро.
4. Clickhouse или DuckDB были бы хорошими инструментами для замены движка внутри OpenRefine. Но, похоже, этого не дождаться. Разве что, сделать всё же, инструмент для headless data refine, я такой когда-то смастерил для MongoDB, но скорость там оставляет желать лучшего. Скорее это был прототип для оценки возможности реализации.
5. Классические ETL/ELT инструменты для геоданных не то чтобы совсем непригодны, но не заточены ни разу. Создавать / адаптировать существующие ETL движки под них? Или использовать что-то целенаправленно созданное в этой области? Пока не очень впечатляет всё что я видел.
#notes #dataengineering #data #datatools