Forwarded from Neural Kovalskii
Deep Research Showdown теперь на Хабре
Йоу, народ 👋
Переписал свои изыскания про Deep Research на Хабр. Если вам интересно, как я мучил LLM-ки, сравнивал OpenAI, Grok, Perplexity и свой NDT на Tavily, то залетайте, читайте и поднимайте мне карму! 🙏
Это моя первая статья на Хабре, буду рад вашим комментариям🩶
Йоу, народ 👋
Переписал свои изыскания про Deep Research на Хабр. Если вам интересно, как я мучил LLM-ки, сравнивал OpenAI, Grok, Perplexity и свой NDT на Tavily, то залетайте, читайте и поднимайте мне карму! 🙏
Это моя первая статья на Хабре, буду рад вашим комментариям
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Deep Research Showdown: битва AI-систем за качество исследований
Как я сравнил топовые AI-модели для глубокого анализа данных и собственную разработку Привет! Меня зовут Валера Ковальский, я CEO NDT by red_mad_robot. Недавно я протестировал ведущие AI-системы,...
Forwarded from Korenev AI - GPT в тапочках🩴
Ловите новый вкусный видос!
Там мы разбираем, как научить LLM новым навыкам, начиная с простых методов и заканчивая продвинутыми техниками. Парни делятся реальным опытом! Одна только история про автоматическое формирование отчетов с LLM только чего стоит!
В пасхалке – разбор проблем извлечения информации из сложных PDF-документов и таблиц.
В видео даются практические советы по подготовке данных, выбору методов обучения, оценке результатов и стоимости всего этого банкета.
Забивайте на все дела, отменяйте все поездки и походы по гостям, срочно смотреть!
Ютуб
Рутуб
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Датавиз в BI • Алиса Ручкина
День 3. Полезняшки по датавизу и разработке дашборда
Сегодня отвечаем на самые животрепещущие вопросы начинающих BI-разработчиков.
🔹 Как выбрать график?
Используй карточки визуализации от DataYoga. Еще про выбор графика можно посмотреть здесь: Подборка чарт-чузеров
🔹 Как сделать график правильным и эстетичным?
Ознакомься с датавиз-стратагемами от DataYoga.
🔹 Как подобрать цвета?
Прочитай памятку о цвете в визуализации данных.
🔹 Как собрать требования для дашборда?
Используй шаблон Dashboard Canvas 2.0 и посмотри видеоролики на Youtube, добавленные на доску.
🔹 Из чего состоит процесс разработки дашборда?
Загляни на доску ДАО процесса разработки дашборда от DataYoga.
❓Интересно, что будет в следующем дне?
Ставь 🔥, если да!
#подборка #дашборд #стартfinebi
Сегодня отвечаем на самые животрепещущие вопросы начинающих BI-разработчиков.
🔹 Как выбрать график?
Используй карточки визуализации от DataYoga. Еще про выбор графика можно посмотреть здесь: Подборка чарт-чузеров
🔹 Как сделать график правильным и эстетичным?
Ознакомься с датавиз-стратагемами от DataYoga.
🔹 Как подобрать цвета?
Прочитай памятку о цвете в визуализации данных.
🔹 Как собрать требования для дашборда?
Используй шаблон Dashboard Canvas 2.0 и посмотри видеоролики на Youtube, добавленные на доску.
🔹 Из чего состоит процесс разработки дашборда?
Загляни на доску ДАО процесса разработки дашборда от DataYoga.
❓Интересно, что будет в следующем дне?
Ставь 🔥, если да!
#подборка #дашборд #стартfinebi
Forwarded from DevFM
Markwhen — для построения роадмапов
Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям.
Хочу поделиться гиковским опенсорсным инструментом — Markwhen.
Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.
Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.
#tools
Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям.
Хочу поделиться гиковским опенсорсным инструментом — Markwhen.
Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.
Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.
#tools
GitHub
GitHub - mark-when/markwhen: Make a cascading timeline from markdown-like text. Supports simple American/European date styles,…
Make a cascading timeline from markdown-like text. Supports simple American/European date styles, ISO8601, images, links, locations, and more. - mark-when/markwhen
Forwarded from Quant Valerian
🤝 КОМАНДА vs РАБОЧАЯ ГРУППА
У обоих есть общая цель. Но в команде каждый действительно хочет этой цели достичь. В рабочей группе каждый просто делает свою работу, что должно продвигать группу в сторону цели, но у сотрудников отсутствует персональное стремление к этой общей цели.
⭐️ МОДЕЛЬ ТАКМАНА И ЕЁ ОГРАНИЧЕНИЯ
Модель Такмана описывает динамику развития группы через пять стадий.
В организационной психологии нет единого мнения о развитии группы.
Стадийный подход рассматривает процесс командообразования как последовательность этапов.
Циклический подход предполагает, что развитие группы происходит в виде циклов стабильности и перемен.
Модель прерывистого равновесия Конника и Герчика описывает рабочие группы с дедлайном.
Все модели групповой динамики имеют свои ограничения.
• Модель Такмана подходит для психотерапевтических групп, но не для рабочих.
• Модель прерывистого равновесия Конника и Герчика применима к рабочим группам с дедлайном.
⭐️ ПРОЦЕСС КОМАНДООБРАЗОВАНИЯ В РЕАЛЬНОСТИ
Рабочая группа проходит через этапы формирования, напряжения, кризиса и системных изменений.
Процесс может протекать с разной скоростью и степенью выраженности.
Группа может возвращаться на предыдущие стадии развития.
Процесс командообразования может протекать по-разному в зависимости от обстоятельств.
Группа может избежать стадии шторма.
Влияние на процесс командообразования зависит от этапа развития группы.
У обоих есть общая цель. Но в команде каждый действительно хочет этой цели достичь. В рабочей группе каждый просто делает свою работу, что должно продвигать группу в сторону цели, но у сотрудников отсутствует персональное стремление к этой общей цели.
⭐️ МОДЕЛЬ ТАКМАНА И ЕЁ ОГРАНИЧЕНИЯ
Модель Такмана описывает динамику развития группы через пять стадий.
В организационной психологии нет единого мнения о развитии группы.
Стадийный подход рассматривает процесс командообразования как последовательность этапов.
Циклический подход предполагает, что развитие группы происходит в виде циклов стабильности и перемен.
Модель прерывистого равновесия Конника и Герчика описывает рабочие группы с дедлайном.
Все модели групповой динамики имеют свои ограничения.
• Модель Такмана подходит для психотерапевтических групп, но не для рабочих.
• Модель прерывистого равновесия Конника и Герчика применима к рабочим группам с дедлайном.
⭐️ ПРОЦЕСС КОМАНДООБРАЗОВАНИЯ В РЕАЛЬНОСТИ
Рабочая группа проходит через этапы формирования, напряжения, кризиса и системных изменений.
Процесс может протекать с разной скоростью и степенью выраженности.
Группа может возвращаться на предыдущие стадии развития.
Процесс командообразования может протекать по-разному в зависимости от обстоятельств.
Группа может избежать стадии шторма.
Влияние на процесс командообразования зависит от этапа развития группы.
Forwarded from Мягкие техники
Третий признак рабочего аргумента
Помните, как на встрече один неубедительный аргумент с вашей стороны мог сорвать весь план? Или как один слабый довод от собеседника на встрече заставлял вас начать сомневаться в его правоте. Или тот случай, когда вы пытались доказать свою идею, но аргументы просто не складывались в логичную цепочку.
Давайте обсудим почему так происходит: у нас в меню последний, третий, признак рабочего аргумента и подытожим тему аргументации.
Предыдущие два признака были: подходит под тему дискуссии и сформулирован на языке выгод для второй стороны.
⸻
Признак рабочего аргумента №3: Аргумент сформулирован ёмко, то есть соответствует принципу «достаточности»
В идеале аргументы подтверждают тезис, а тезис логически вытекает из аргументов. Для этого, как правило, приходится приводить несколько аргументов: одного чаще всего недостаточно. При этом все эти аргументы должны быть достаточно убедительными.
Во втором примере аргумент про ускорение релизов фичей выглядит как пустые красивые слова, которые никак не подтверждены — их прицепили вагончиком к нормальному первому аргументу о стабильном результате.
Есть риск, что слушатель, заметив такой неказистый второй аргумент, напряжётся и с подозрением отнесётся так же и к первому тезису.
⸻
В качестве упражнения попробуйте на этой неделе выбирать один-два аргумента, но чтобы они были максимально убедительными и выстраивать диалог вокруг них.
Мне такое упражнение помогло понять, почему я вываливаю много аргументов, но они пролетают мимо собеседника.
⸻
Итого, мы разобрали три признака рабочего аргумента:
1. Подходит под тему дискуссии;
2. На языке выгод для второй стороны;
3. Достаточный.
Чтобы аргументация была прочной:
— убедитесь, что аргументы, которые вы приводите, будут понятны для собеседника;
— оставьте по возможности только те аргументы, с которыми собеседнику будет легко согласиться (больше — не значит лучше).
Виды аргументов, которые сложно критиковать (но не невозможно):
— статистика с подробным описанием методологии и выводами из исследования;
— аксиомы и общепринятые факты;
— официальные документы и законы.
⸻
В этот раз без «тёмной стороны» :). Нашли что-то полезное в этой заметке?
Я не размещаю рекламу и не делаю интеграции. Благодарность для меня — ваши лайки, комменты и репосты в других каналах.
Помните, как на встрече один неубедительный аргумент с вашей стороны мог сорвать весь план? Или как один слабый довод от собеседника на встрече заставлял вас начать сомневаться в его правоте. Или тот случай, когда вы пытались доказать свою идею, но аргументы просто не складывались в логичную цепочку.
Давайте обсудим почему так происходит: у нас в меню последний, третий, признак рабочего аргумента и подытожим тему аргументации.
Предыдущие два признака были: подходит под тему дискуссии и сформулирован на языке выгод для второй стороны.
⸻
Признак рабочего аргумента №3: Аргумент сформулирован ёмко, то есть соответствует принципу «достаточности»
В идеале аргументы подтверждают тезис, а тезис логически вытекает из аргументов. Для этого, как правило, приходится приводить несколько аргументов: одного чаще всего недостаточно. При этом все эти аргументы должны быть достаточно убедительными.
Например
Тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
Связка аргументов, каждый сформулирован достаточно ёмко и убедительно: «Чтобы стабильно добиваться поставленных KPI, мы строго придерживаемся процесса оценки всех новых задач. Это также позволяет нам расставлять приоритеты осознанно, учитывать загрузку, риски и взаимосвязи между задачами. В итоге мы релизим фичи быстрее и качественнее».
Пример, где аргументы не соответствуют принципу достаточности: «Чтобы стабильно добиваться поставленных KPI, мы строго придерживаемся процесса оценки всех новых задач. Это также позволяет нам релизить фичи быстрее и качественнее».
Во втором примере аргумент про ускорение релизов фичей выглядит как пустые красивые слова, которые никак не подтверждены — их прицепили вагончиком к нормальному первому аргументу о стабильном результате.
Есть риск, что слушатель, заметив такой неказистый второй аргумент, напряжётся и с подозрением отнесётся так же и к первому тезису.
⸻
В качестве упражнения попробуйте на этой неделе выбирать один-два аргумента, но чтобы они были максимально убедительными и выстраивать диалог вокруг них.
Мне такое упражнение помогло понять, почему я вываливаю много аргументов, но они пролетают мимо собеседника.
⸻
Итого, мы разобрали три признака рабочего аргумента:
1. Подходит под тему дискуссии;
2. На языке выгод для второй стороны;
3. Достаточный.
Чтобы аргументация была прочной:
— убедитесь, что аргументы, которые вы приводите, будут понятны для собеседника;
— оставьте по возможности только те аргументы, с которыми собеседнику будет легко согласиться (больше — не значит лучше).
Виды аргументов, которые сложно критиковать (но не невозможно):
— статистика с подробным описанием методологии и выводами из исследования;
— аксиомы и общепринятые факты;
— официальные документы и законы.
⸻
В этот раз без «тёмной стороны» :). Нашли что-то полезное в этой заметке?
Я не размещаю рекламу и не делаю интеграции. Благодарность для меня — ваши лайки, комменты и репосты в других каналах.
Forwarded from Пристанище Дата Сайентиста (TelepostBot)
RouteLLM снижает ваши расходы на инференс LLM в 3,6 раза 💵.
Он выбирает использовать сильную или слабую LLM в зависимости от сложности запроса пользователя. Это оптимизирует баланс между стоимостью и качеством ответа.
Вы можете использовать его напрямую через их Python-библиотеку.
Вот как работает модель:
- Модель обучена на предпочтениях, полученных из 80 000 сражений на платформе Chatbot Arena.
- Они группируют модели по уровням, чтобы справиться с разреженностью меток. Сильные модели берутся из топ-уровней, а слабые — из третьего уровня.
- Они тестируют разные подходы к маршрутизации, включая матричную факторизацию, классификатор на основе BERT, ранжирование с учетом сходства (SW) и даже каузальный классификатор Llama 3 8B.
- Маршрутизатор на основе матричной факторизации снижает затраты до 3,66 раза, сохраняя качество, сопоставимое с GPT-4.
Эти маршрутизаторы хорошо обобщаются на разные пары сильных и слабых моделей без необходимости повторного обучения.
Статья
Он выбирает использовать сильную или слабую LLM в зависимости от сложности запроса пользователя. Это оптимизирует баланс между стоимостью и качеством ответа.
Вы можете использовать его напрямую через их Python-библиотеку.
Вот как работает модель:
- Модель обучена на предпочтениях, полученных из 80 000 сражений на платформе Chatbot Arena.
- Они группируют модели по уровням, чтобы справиться с разреженностью меток. Сильные модели берутся из топ-уровней, а слабые — из третьего уровня.
- Они тестируют разные подходы к маршрутизации, включая матричную факторизацию, классификатор на основе BERT, ранжирование с учетом сходства (SW) и даже каузальный классификатор Llama 3 8B.
- Маршрутизатор на основе матричной факторизации снижает затраты до 3,66 раза, сохраняя качество, сопоставимое с GPT-4.
Эти маршрутизаторы хорошо обобщаются на разные пары сильных и слабых моделей без необходимости повторного обучения.
Статья
Forwarded from ML Advertising
Сделал подборку туториалов по промпт инжинирингу для LLM:
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Claude API Docs
Prompt engineering overview
Claude API Documentation
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №4. Choosing Technologies Across the Data Engineering Lifecycle. Часть №3
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №5. Data Generation in Source Systems. Часть №1 Источники исходных данных для Data системы.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.