🔋 Труба данных – Telegram
🔋 Труба данных
3.99K subscribers
330 photos
5 videos
9 files
449 links
Авторский канал обо всем, что происходит в мире работы с данными: хранение, обработка, визуализация, как мы принимаем решения и как мы становимся профессионалами в работе с данными.

Автора канала - @SimonOsipov
Download Telegram
https://medium.com/@thedatainsight/bronze-is-the-battlefield-why-real-data-engineers-start-at-the-source-6eaa16730f0a

Нормально делай - нормально будет! Саша снова насыпал базисной базы, а мне даже добавить нечего.

@ohmydataengineer - канал "🕯Труба Данных"
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8💩1
Big data integration company Fivetran Inc. is reportedly holding advanced talks with dbt Labs Inc. over a multibillion-dollar acquisition.

https://siliconangle.com/2025/09/28/report-fivetran-talks-dbt-labs-multibillion-dollar-big-data-merger/

Просто новость. Выводов никаких не будет =)

@ohmydataengineer - канал "🕯Труба Данных"
Please open Telegram to view this post
VIEW IN TELEGRAM
💩7👍31🔥1🥱1
Очередная движуха для тех, кто живёт аналитикой. Коллеги и друзья из NEWHR снова собирают рынок — кого, где, за сколько и зачем нанимают. Всё по классике: зарплаты, новые задачи, как и где работают, кто топит за культуру.

В этот раз цепляют и бизнес/системных аналитиков, и даже начальников.

20 минут на опрос — и потом инсайты, стрим и вся вкусная инфа (полный разбор ждём в 2026, а промежуточное — сразу по ходу).

Чем больше залетит народу — тем точнее картина, поэтому и делюсь ссылкой

P.S. Да, ждать результат надо, но стоит того — предыдущие выпуски были полезными
Ссылка на последнее 2024

Как принять участие в исследовании?
 Заполните 20-мин опросник
💩4👍3🔥32
Forwarded from DevBrain
Python 3.14 уже здесь!

Пару часов назад вышел финальный релиз новой версии Python 3.14. Это, пожалуй, один из самых мощных релизов на моей памяти. Новая версия несёт в себе ряд крутых фич, а именно:
- полная поддержка Free-threaded Python
- T-strings, спорная фича, но на мой взгляд удобно иметь в стандартной библиотеке (синтаксис знакомых нам f-strings)
- zstd внутри стандартной либы, один из самых эффективных алгоритмов сжатия данных
- поддержка multiple interpreters из коробки
- uuid 6-8, на 40% быстрее

И многое другое, полный список изменений ловите по ссылке: https://pythoninsider.blogspot.com/2025/10/python-3140-final-is-here.html
🔥25👍5
Forwarded from Время Валеры
На днях в open source выпустили распределённую файловую систему, которая рассчитана на эксабайты (тысячи петабайт).

Сделали это чуваки из XTX, мощные трейдеры, которые известны двумя вещами: тем, что у них (по крайней мере недавно) был топ-3 кластер по количеству ГПУ, и тем, что их основатель, Александр Герко, так любит Лондон, что каждый год платит 500+ млн фунтов налогов на доходы как физическое лицо.

Из интересного (они выделили 9 пунктов, но только 5 мне кажутся отличительными)

Has no single point of failure in its metadata services.
Is hardware agnostic and uses TCP/IP to communicate.
Utilizes different types of storage (such as flash vs. hard disks) cost effectively.
Exposes read/write access through its own API over TCP and UDP, and a Linux kernel filesystem module.
Requires no external service and has a minimal set of build dependencies

Начали работы над системой в 2022 году, в середине 2024 мигрировали весь ML

TernFS' metadata is split into 256 logical shards. Shards never communicate with each other. This is a general principle in TernFS: Splitting the metadata into 256 shards from the get-go simplifies the design, given that horizontal scaling of metadata requires no rebalancing, just the addition of more metadata servers.

Ну и заодно свой формат сериализации разработали, чтобы разработчики передвигали не json, thrift, а что-то там свое.

Еще из интересного - обсуждение когда нужно зеркалить файлы, а когда делать Reed-Solomon coding.

Рекомендую почитать
🔥10💩31👍1
🥱14😢8💩3👍2🔥1
https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks

Прекрасная статья о том, что момент, когда вам в большинстве случаев, перестанет хватать Posgres на самом деле очень и очень далек.
И как Pub/Sub решение, и как Redis решение, и Data Lake решение.

Циферки, метрики, замеры внутри, все как вы любите 😃


P.S. Конечно же, никто не говорит о том, что Kafka надо заменять на Postgres. The claim isn’t that Postgres is functionally equivalent to any of these specialized systems. The claim is that it handles 80%+ of their use cases with 20% of the development effort.

Но поздно, стервятники уже налетели...https://www.morling.dev/blog/you-dont-need-kafka-just-use-postgres-considered-harmful/

@ohmydataengineer
11
https://github.com/toon-format/toon

Если у вас есть какие-либо автоматизации с использованием LLM и вы в них кидаетесь данными, то вот тут ребята собрали небольшой оптимизатор структур, позволяющий экономить на токенах.

@ohmydataengineer
💩82🔥1
Российские ETL решения....

Я даж не знаю, смеяться или плакать..🙈

Специально оставлю вам ссылку с картинки https://russianbi.ru/ - чтобы вы сами посмотрели на это.
💩26😢5🥱3
https://bfcm.shopify.com

У Shopify в этом году на Βlack Friday было 45kk сообщений в Кафку в секунду...

(скриншот, конечно, сегодняшний, а не пятничный, но сам вебсайт оч классный с техническими метриками)

А сколько там пасхалок на этом сайте... 😃 (одна из них что он жрет гигабайт оперативки)

@ohmydataengineer
👍19💩1
MiniO все.

This project is currently under maintenance and is not accepting new changes.
• The codebase is in a maintenance-only state
• No new features, enhancements, or pull requests will be accepted
• Critical security fixes may be evaluated on a case-by-case basis
• Existing issues and pull requests will not be actively reviewed
• Community support continues on a best-effort basis through Slack


https://github.com/minio/minio

@ohmydataengineer
😢60👍4💩4🔥1
Показываем аудитории молодые open-source проекты. Мне не жалко, вдруг кому-то будет интересно.


🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных

🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);

Запуск через Docker:
docker run -d
--name postgresus
-p 4005:4005
-v ./postgresus-data:/postgresus-data
--restart unless-stopped
rostislavdugin/postgresus:latest

📌 GitHub
16🔥12💩3👎1
https://karpathy.bearblog.dev/year-in-review-2025

Andrej Karpathy (ну тот, который был главнюком за AI в Tesla и не только) подвел отличные и оч лаконичные итоги года.
Еще мне на прошлой неделе удалось посмотреть два интересных интервью и один докладик

- Andrej Karpathy — “We’re summoning ghosts, not building animals” - https://www.youtube.com/watch?v=lXUZvyajciY

- Ilya Sutskever – "We're moving from the age of scaling to the age of research"- https://www.youtube.com/watch?v=aR20FWCCjAs

- Andrej Karpathy: Software Is Changing (Again) - https://www.youtube.com/watch?v=LCEmiRjPEtQ


И нет, это не х2 скорость, это он так в реальности говорит 😃


@ohmydataengineer - канал "Труба данных" про всякое в мире работы с данным
👍8
Forwarded from Клуб CDO
8e0ef293-a3c7-49ab-afbb-3f8cac35a88c_1600x954.jpg
192.3 KB
Хотя про AI-агентов сейчас пишут буквально из каждого утюга, в этой статье мне особенно зацепился один момент — визуализация зависимости качества ответов LLM от длины контекста. Интуитивно мы все чувствуем, что «чем больше — тем лучше», но на практике кривая выглядит иначе: после определённого порога контекст начинает не помогать, а мешать. Сигнал тонет в шуме, модель теряет фокус, а качество решений деградирует. Забрал эту картинку себе в копилку как хорошее напоминание.

Из этого логично вытекает важный тезис: формулировка задачи вторична, первична политика контекста. Не «как красиво спросить», а что именно и в каком объёме сейчас действительно нужно модели. Принцип «минимум, достаточный для текущего шага» оказывается куда более надёжным, чем попытка загрузить в контекст всё возможное «на всякий случай».

Отдельно понравилась мысль про инструменты. Да, туллинг расширяет возможности LLM, но каждый их вывод — это ещё один удар по контекстному бюджету. Если инструменты шумят, возвращают избыточные данные или нестабильный формат, агент быстро начинает деградировать. Поэтому критичны строгие контракты, малый, предсказуемый и структурированный вывод — иначе инструменты становятся источником энтропии, а не силы.

История сообщений — ещё одна зона инженерной ответственности. Хранить всё подряд — плохая стратегия. Актуальное должно быть доступно, «закрытые» куски — сжаты и зафиксированы в виде состояния, всё остальное — безжалостно отброшено. Контекст — не лог событий, а рабочая память, и к ней применимы те же принципы, что и к архитектуре систем.

Итог для меня простой: контекст-инжиниринг — это полноценная дисциплина проектирования. Каждая загрузка в окно контекста — осознанное решение с ограничениями. Надёжность агента обеспечивается не магией промпта, а управлением информационным бюджетом, продуманной retrieval-стратегией и регулярной компакцией состояния. Именно здесь сейчас проходит граница между «демо» и реально работающими агентными системами.

https://newsletter.systemdesign.one/p/what-is-context-engineering
👍16💩2
https://www.youtube.com/watch?v=rmvDxxNubIg

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

@ohmydataengineer - канал "Труба данных" про всякое в мире работы с данным
1🔥5🥱1