Forwarded from Сиолошная
Выводы и результаты такие:
— для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем
— для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё пара трюков: дополнительная информация в контекст (RAG над документацией) + Set-of-Mark (когда кнопки/текст на экране распознают и выделяют на картинке для модели)
— глобально решается 14% задач, что очень мало, но тут можно сделать много срезов
— например, простых задач решается уже 40% (сложных — 1.2%)
— также решается 20% задач, требующих только работу с графическим интерфейсом, без консоли или IDE
— (см. картинку) GPT-4V решает 25% задач на визуализацию, GPT-4o 24% на Data Ingestion
— GPT сильно превосходит модели Google и Anthropic
Так что пока живём, джунов не заменит. Но очень хочется, чтобы при релизе GPT-5 и Claude-3.5-Opus прям сразу рассказали про метрики на этом и схожих бенчмарках — чтобы понимать, какую долю работу мы скоро потеряем...
— для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем
— для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё пара трюков: дополнительная информация в контекст (RAG над документацией) + Set-of-Mark (когда кнопки/текст на экране распознают и выделяют на картинке для модели)
— глобально решается 14% задач, что очень мало, но тут можно сделать много срезов
— например, простых задач решается уже 40% (сложных — 1.2%)
— также решается 20% задач, требующих только работу с графическим интерфейсом, без консоли или IDE
— (см. картинку) GPT-4V решает 25% задач на визуализацию, GPT-4o 24% на Data Ingestion
— GPT сильно превосходит модели Google и Anthropic
Так что пока живём, джунов не заменит. Но очень хочется, чтобы при релизе GPT-5 и Claude-3.5-Opus прям сразу рассказали про метрики на этом и схожих бенчмарках — чтобы понимать, какую долю работу мы скоро потеряем...
Forwarded from Сиолошная
Сиолошная
Выводы и результаты такие: — для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем — для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё…
Понятно ли вам примерно, как именно «простая LLM которая генерирует следующее слово» решает эти задачи?
Anonymous Poll
15%
Да, прекрасно понимаю функционал агента
49%
Нууу очень примерно, плюс минус
37%
Нет, вообще не понимаю, модель же просто текст генерирует?
Forwarded from DE
Оказывается есть стандарт OpenFeature с которым фича-флаги выглядят ещё более удобными и привлекательными при разработке.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DE
DE
Feature flags (или флаги функций) важный инструмент в современном программировании. Они позволяют тебе включать и выключать определённые функции в коде без необходимости вносить изменения в основной код базы. Это особенно полезно при разработке и тестировании новых функций.
✔️ Преимущества использования feature flags
1️⃣ Контроль над функциями:
Можно безопасно тестировать новые функции на ограниченной группе пользователей.
2️⃣ Ускорение разработки:
Новые функции могут быть внедрены быстрее, так как их можно включать или выключать без релиза новой версии приложения.
3️⃣ Уменьшение риска:
Если новая функция вызывает проблемы, её можно быстро отключить, минимизируя влияние на пользователей.
4️⃣ Персонализация:
Различные пользователи могут видеть разные наборы функций в зависимости от своих предпочтений, групп или политик безопасности.
✅ Влияние feature flags на кодовые базы
1️⃣ Усложнение кода:
При неправильном использовании количество условий в коде (многообразие if-elif, которые ты так любишь🙃 ) может увеличиться, что сделает его сложнее для чтения и сопровождения.
2️⃣ Тестирование:
Необходимо тестировать каждую комбинацию включённых и выключенных флагов, что может увеличить объём работы тестировщиков.
3️⃣ Технический долг:
Если feature flags не удаляются после стабилизации функции, они могут накопить технический долг, усложняя кодовую базу.
📎 Заключение
Feature flags являются мощным инструментом при правильном использовании, помогая управлять развитием продукта и уменьшать риски. Однако важно следить за их количеством и своевременно удалять неиспользуемые флаги, чтобы поддерживать кодовую базу в чистоте.
#dev #featureflags #if
Можно безопасно тестировать новые функции на ограниченной группе пользователей.
Новые функции могут быть внедрены быстрее, так как их можно включать или выключать без релиза новой версии приложения.
Если новая функция вызывает проблемы, её можно быстро отключить, минимизируя влияние на пользователей.
Различные пользователи могут видеть разные наборы функций в зависимости от своих предпочтений, групп или политик безопасности.
При неправильном использовании количество условий в коде (многообразие if-elif, которые ты так любишь
Необходимо тестировать каждую комбинацию включённых и выключенных флагов, что может увеличить объём работы тестировщиков.
Если feature flags не удаляются после стабилизации функции, они могут накопить технический долг, усложняя кодовую базу.
Feature flags являются мощным инструментом при правильном использовании, помогая управлять развитием продукта и уменьшать риски. Однако важно следить за их количеством и своевременно удалять неиспользуемые флаги, чтобы поддерживать кодовую базу в чистоте.
#dev #featureflags #if
Please open Telegram to view this post
VIEW IN TELEGRAM
https://www.datanami.com/2024/07/08/dont-believe-the-big-database-hype-stonebraker-warns/
YandexGPT
краткий пересказ статьи от нейросети
Не верьте шумихе вокруг базы данных, предупреждает Стоунбрейкер
Кратко
Подробно
◦ Обзор состояния баз данных
◦ • Реляционные базы данных (RM) доминируют, но их будущее под вопросом.
◦ • Новые технологии, такие как NoSQL, не смогли заменить RM.
◦ • Некоторые технологии, такие как Hadoop и MapReduce, устарели.
•
◦ Тенденции в базах данных
◦ • Хранилища ключей и значений и хранилища документов эволюционировали, но не вытеснили RM.
◦ • Столбчатые базы данных и векторные базы данных имеют ограниченное будущее.
◦ • Базы данных Graph и облачные базы данных стали популярными.
•
◦ Архитектура баз данных
◦ • Хранилища данных в столбцах и облачные базы данных доминируют на рынке.
◦ • Хранилища данных / Lakehouses предлагают гибкость для обработки данных не-SQL.
◦ • Системы NewSQL не получили широкого распространения.
◦ • Аппаратные ускорители баз данных не оправдали затрат.
•
◦ Базы данных блокчейна
◦ • Базы данных блокчейна не нашли широкого применения за пределами Даркнета.
•
◦ Будущее разработки баз данных
◦ • Сообщество баз данных должно стремиться к стандартизации и открытому исходному коду.
◦ • Необходимо извлекать уроки из истории и стремиться к постоянному развитию.
•
◦ Сопутствующие товары и поставщики
◦ • Статья содержит ссылки на дополнительные материалы и продукты от различных поставщиков.
•
◦ Теги
◦ • В статье используются различные теги для описания различных аспектов баз данных.
•
YandexGPT
краткий пересказ статьи от нейросети
Не верьте шумихе вокруг базы данных, предупреждает Стоунбрейкер
Кратко
Подробно
◦ Обзор состояния баз данных
◦ • Реляционные базы данных (RM) доминируют, но их будущее под вопросом.
◦ • Новые технологии, такие как NoSQL, не смогли заменить RM.
◦ • Некоторые технологии, такие как Hadoop и MapReduce, устарели.
•
◦ Тенденции в базах данных
◦ • Хранилища ключей и значений и хранилища документов эволюционировали, но не вытеснили RM.
◦ • Столбчатые базы данных и векторные базы данных имеют ограниченное будущее.
◦ • Базы данных Graph и облачные базы данных стали популярными.
•
◦ Архитектура баз данных
◦ • Хранилища данных в столбцах и облачные базы данных доминируют на рынке.
◦ • Хранилища данных / Lakehouses предлагают гибкость для обработки данных не-SQL.
◦ • Системы NewSQL не получили широкого распространения.
◦ • Аппаратные ускорители баз данных не оправдали затрат.
•
◦ Базы данных блокчейна
◦ • Базы данных блокчейна не нашли широкого применения за пределами Даркнета.
•
◦ Будущее разработки баз данных
◦ • Сообщество баз данных должно стремиться к стандартизации и открытому исходному коду.
◦ • Необходимо извлекать уроки из истории и стремиться к постоянному развитию.
•
◦ Сопутствующие товары и поставщики
◦ • Статья содержит ссылки на дополнительные материалы и продукты от различных поставщиков.
•
◦ Теги
◦ • В статье используются различные теги для описания различных аспектов баз данных.
•
Datanami
Don’t Believe the Big Database Hype, Stonebraker Warns
How we store and serve data are critical factors in what we can do with data, and today we want to do oh-so much. That big data necessity is the mother of
Forwarded from Alex. Seconds.
Media is too big
VIEW IN TELEGRAM
📈Weekly Data Stand-Up — 📆22.07.2024
Текущие задачи/планы:
• CrowdStrike наносит удар, но не по нам
• Snowflake UDTF все-таки заработала
• Grafana Alerts по метрикам (или их отсутствию) из Airflow
• нехватка open source коннекторов, но смотрим на Airbyte
• планы добавить линтеры и форматеры для SQL/dbt (SQLfluff) и HCL (tflint)
Предложения/вопросы из чата:
• передача метрик GitHub через OpenTelemetry
Спасибо всем, кто забежал поучаствовать ранним утром понедельника💙
P.S.: кстати, если кто-то хочет поучаствовать в таком формате #weeklydatastandup и рассказать о своих текущих задачах/сложностях/успехах, пишите мне и присоединяйтесь в роли спикера!
Текущие задачи/планы:
• CrowdStrike наносит удар, но не по нам
• Snowflake UDTF все-таки заработала
• Grafana Alerts по метрикам (или их отсутствию) из Airflow
• нехватка open source коннекторов, но смотрим на Airbyte
• планы добавить линтеры и форматеры для SQL/dbt (SQLfluff) и HCL (tflint)
Предложения/вопросы из чата:
• передача метрик GitHub через OpenTelemetry
Спасибо всем, кто забежал поучаствовать ранним утром понедельника💙
P.S.: кстати, если кто-то хочет поучаствовать в таком формате #weeklydatastandup и рассказать о своих текущих задачах/сложностях/успехах, пишите мне и присоединяйтесь в роли спикера!
Forwarded from Data1984
Forwarded from Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Forwarded from Andre
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
А что значит правильные модели?
Forwarded from Vadim
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Литературы очень мало, причем, понятия различаются.
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Data Engineering Wiki
Concepts - Data Engineering Wiki
Core Concepts How to build a data pipeline Data Modeling Batch vs Stream processing Indexing Relational vs Non-relational data OLTP vs OLAP Database ConceptsCAP Theorem Column-oriented Database Docum…
Forwarded from DataWorkshop - AI & ML
Кстати, в мире технологии постоявнно появляются новые инструменты и найтись во всем этом становится трудно.
Есть такая библиотека, которая называется Ibis (это не призыв к действиям, чем заняться 14 февраля, хотя случайностей не бывает 😂).
Ibis — это как универсальный "переводчик" для работы с данными в Python. Позволяет манипулировать огромными объемами данных, хранящимися где угодно, используя знакомый интерфейс в стиле pandas.
Самое крутое — код выполняется там, где хранятся данные, благодаря чему всё работает быстрее, не загружая Твой компьютер. Это как иметь один инструмент, который подходит для любой работы с данными, не нужно переучиваться или переписывать код при смене базы данных или увеличении объемов данных.
Поддерживает
- Apache Arrow DataFusion
- Apache Druid
- Apache Flink
- Apache Impala
- Apache PySpark
- BigQuery
- ClickHouse
- Dask
- DuckDB
- Exasol
- HeavyAI
- MySQL
- Oracle
- Pandas
- Polars
- PostgreSQL
- SQL Server
- SQLite
- Snowflake
- Trino
Хочешь узнать больше? Поставь сердечко ❤️
Есть такая библиотека, которая называется Ibis (это не призыв к действиям, чем заняться 14 февраля, хотя случайностей не бывает 😂).
Ibis — это как универсальный "переводчик" для работы с данными в Python. Позволяет манипулировать огромными объемами данных, хранящимися где угодно, используя знакомый интерфейс в стиле pandas.
Самое крутое — код выполняется там, где хранятся данные, благодаря чему всё работает быстрее, не загружая Твой компьютер. Это как иметь один инструмент, который подходит для любой работы с данными, не нужно переучиваться или переписывать код при смене базы данных или увеличении объемов данных.
Поддерживает
- Apache Arrow DataFusion
- Apache Druid
- Apache Flink
- Apache Impala
- Apache PySpark
- BigQuery
- ClickHouse
- Dask
- DuckDB
- Exasol
- HeavyAI
- MySQL
- Oracle
- Pandas
- Polars
- PostgreSQL
- SQL Server
- SQLite
- Snowflake
- Trino
Хочешь узнать больше? Поставь сердечко ❤️
Forwarded from Инжиниринг Данных (Dmitry)
Cheat sheet for data engineering ramp up in 2022.
🟢 SQL/data modeling
Install Postgres. Load dummy data with \copy
Understand ACID
Different consistency levels: Strict, Linearizable, Serializable, Eventual, Casual
Aggs with GROUP BY.
Joins: INNER, LEFT.
Filter records with WHERE. Filter groups with HAVING.
Aggs persisted to summary tables.
ORDER BY foo LIMIT n --> top n by foo.
Organize queries with CTEs and temp tables. Subselect sparingly
Window functions to look at trends within arbitrary partitions.
Unique constraints. Foreign key constraints.
Dimensions vs Fact tables. Star, snowflake schemas.
EXPLAIN <query>. Read the plan.
Add an index. How does the EXPLAIN change?
🟢 CompSci concepts you must know
Uniformly distributed hash functions.
Tuples vs Arrays.
Iterator design pattern.
External Merge sort.
Bit vectors, HashMap. Sets.
Directed graphs.
Serialization
🟢 Time representation
ISO 8601 strings
Prefer native date and timestamp objects.
UTC.
🟢 Fundamentals of distributed data processing
Cap theorem.
Replication.
Horizontal vs Vertical scaling.
Sharding vs clustering.
Share-nothing principle.
Partitioning data at-rest.
Planning for fault tolerance and failure.
Exponential back off retries.
Latency vs bandwidth.
How to code to iterators without the input fully buffered in memory.
🟢 Spark
Dataframe and Dataset batch API.
Shuffle challenges. When to repartition().
Runtime partitioning by key.
Tuning: executors num, memory, cores. Num shuffle partitions.
Dataframe ops split up into composable driver functions.
Construct fixture Dataframes for unit tests.
Create temporary views as staging tables.
Data quality checks over staging views. Lots of logging.
Fail driver if checks fail.
Block any downstream dependencies until the checks pass.
Hive metastore for data lake catalog.
🟢 Common structured data formats
TSV, Tar, Zip, XLSX, Avro, Parquet, Protobufs, Delta
Splittable file format?
Compression: Bz2. Gzip, Snappy, LZO.
Hadoop mergeUtils to help small files problem.
🟢 Cloud providers
Top players for distributed computing: AWS, GCP, Azure
S3/GCS object stores
Managed Airflow = pipelining
EMR/Dataproc = processing
Container registries. EKS/GKE for container execution
IAM access controls. As-needed access. No shared service creds.
🟢 Languages (1 - 10 goal proficiency)
SQL (10)
Python (8)
Java (7)
Scala (4)
Bash (4)
🟢 Metrics/monitoring/alerting
Statsd, Prometheus.
HTTP vs. UDP
Gauge vs increment vs histogram.
Measurement vs tag.
Visualize measurement time series: Grafana, Datadog.
Observe what normal is. Alert on abnormal thresholds.
Alert messaging clarity.
Runbooks for on-call.
🟢 Linux familiarity
tail -f
tmux
ps -ef, kill -9
vim
ssh, scp
cat, less, more, grep, find, echo, xargs, |, >, >>, <
sudo
.bash_profile, EXPORT, unset, $PATH
🟢 Containers
Linux cgroups.
Dockerfile. Docker Desktop.
docker-compose
Basic understanding of Kubernetes. Kubectl
Anything I leave out that's important?
🟢 SQL/data modeling
Install Postgres. Load dummy data with \copy
Understand ACID
Different consistency levels: Strict, Linearizable, Serializable, Eventual, Casual
Aggs with GROUP BY.
Joins: INNER, LEFT.
Filter records with WHERE. Filter groups with HAVING.
Aggs persisted to summary tables.
ORDER BY foo LIMIT n --> top n by foo.
Organize queries with CTEs and temp tables. Subselect sparingly
Window functions to look at trends within arbitrary partitions.
Unique constraints. Foreign key constraints.
Dimensions vs Fact tables. Star, snowflake schemas.
EXPLAIN <query>. Read the plan.
Add an index. How does the EXPLAIN change?
🟢 CompSci concepts you must know
Uniformly distributed hash functions.
Tuples vs Arrays.
Iterator design pattern.
External Merge sort.
Bit vectors, HashMap. Sets.
Directed graphs.
Serialization
🟢 Time representation
ISO 8601 strings
Prefer native date and timestamp objects.
UTC.
🟢 Fundamentals of distributed data processing
Cap theorem.
Replication.
Horizontal vs Vertical scaling.
Sharding vs clustering.
Share-nothing principle.
Partitioning data at-rest.
Planning for fault tolerance and failure.
Exponential back off retries.
Latency vs bandwidth.
How to code to iterators without the input fully buffered in memory.
🟢 Spark
Dataframe and Dataset batch API.
Shuffle challenges. When to repartition().
Runtime partitioning by key.
Tuning: executors num, memory, cores. Num shuffle partitions.
Dataframe ops split up into composable driver functions.
Construct fixture Dataframes for unit tests.
Create temporary views as staging tables.
Data quality checks over staging views. Lots of logging.
Fail driver if checks fail.
Block any downstream dependencies until the checks pass.
Hive metastore for data lake catalog.
🟢 Common structured data formats
TSV, Tar, Zip, XLSX, Avro, Parquet, Protobufs, Delta
Splittable file format?
Compression: Bz2. Gzip, Snappy, LZO.
Hadoop mergeUtils to help small files problem.
🟢 Cloud providers
Top players for distributed computing: AWS, GCP, Azure
S3/GCS object stores
Managed Airflow = pipelining
EMR/Dataproc = processing
Container registries. EKS/GKE for container execution
IAM access controls. As-needed access. No shared service creds.
🟢 Languages (1 - 10 goal proficiency)
SQL (10)
Python (8)
Java (7)
Scala (4)
Bash (4)
🟢 Metrics/monitoring/alerting
Statsd, Prometheus.
HTTP vs. UDP
Gauge vs increment vs histogram.
Measurement vs tag.
Visualize measurement time series: Grafana, Datadog.
Observe what normal is. Alert on abnormal thresholds.
Alert messaging clarity.
Runbooks for on-call.
🟢 Linux familiarity
tail -f
tmux
ps -ef, kill -9
vim
ssh, scp
cat, less, more, grep, find, echo, xargs, |, >, >>, <
sudo
.bash_profile, EXPORT, unset, $PATH
🟢 Containers
Linux cgroups.
Dockerfile. Docker Desktop.
docker-compose
Basic understanding of Kubernetes. Kubectl
Anything I leave out that's important?
Forwarded from commit -m "better"
CAP теорема от PG: интересный проект, хорошая команда, деньги - выбери два.
Forwarded from data будни (Sasha Mikhailov)
⚾ Andy Pavlo
меня покусал библиотекарь, поэтому перед тем как ввести новое действующее лицо, дам ссылку на общеизвестный факт.
имя Andy Pavlo у меня прочно ассоциируется с базами данных: Andy = databases, databases = Andy
у него есть открытый каталог всех баз данных, где уже есть ссылки на 998 (!) штук
https://dbdb.io/
ещё у негоесть был стартап, который помогает тюнить клиентские базы данных с помощью мл: моделька на основе метаданных подкручивает настройки вашего постгреса в цикле с обратной связью. сами данные она не видит.
https://ottertune.com/
и, видимо, для души (и будущих клиентов и сотрудников), он ведёт курс по базам данных в университете CMU
несмотря на то, что курс офлайн в обычном кирпичном университете, все лекции записываются и доступны на ютубе (а ещё иногда в начале играет настоящий диджей!)
вот записи с последнего потока — 2024 год
меня покусал библиотекарь, поэтому перед тем как ввести новое действующее лицо, дам ссылку на общеизвестный факт.
имя Andy Pavlo у меня прочно ассоциируется с базами данных: Andy = databases, databases = Andy
у него есть открытый каталог всех баз данных, где уже есть ссылки на 998 (!) штук
https://dbdb.io/
ещё у него
https://ottertune.com/
и, видимо, для души (и будущих клиентов и сотрудников), он ведёт курс по базам данных в университете CMU
несмотря на то, что курс офлайн в обычном кирпичном университете, все лекции записываются и доступны на ютубе (а ещё иногда в начале играет настоящий диджей!)
вот записи с последнего потока — 2024 год
Forwarded from Igor Melnikov
Часть вторая.
Смотрю БД. В БД есть несколько основных таблиц фактов, гигантских размеров. Все несекционированные.
Занимают 90% объема всей БД. В общем обычная история.
Первым делом, как это было всегда в оракловых проектах , предлагаю секционировать эти таблицы по месяцам.
Начинается нехилый проект по секционированию. В downtime, конечно, перелив не укладывается - пишу скрипты перелива данных в секции. Потом выясняется, что данные меняются задним числом - поэтому пришлось на исходные таблицы навесить DML-триггеры, которые фиксируют факт изменения строки в отдельную лог- таблицу. Соответственно, в процедуре перелива обрабатываю данные этой лог таблицы.
Потом была проблема в том, что перелив одной операции в партицию (INSERT SELECT ... WHERE sale_date='month_year') падал то по таймауту, то по ошибке PG. PG очень не любит длинные транзакции, поэтому пришлось мелкими порциями строки переливать в партицию (cекционирование по месяцам).
Ну и конечно пришлось увеличивать дисковое пространство в облаке - объем БД увеличился. Смутило, что объем стал не в два раза больше, а в четыре раза (4). Почему-то в суматохе не обратил на это внимание.
В общем все позади, и в выходные ночью доливаю последние изменения, обрабатываю лог-таблицы и переключаю на новые таблицы: исходные таблицы переименовываю, а секционированные переименовываю в имя исходной таблицы).
На следующий день начался кошмар, который продолжался в течении пары недель.
Продолжение в третьей части ...
Смотрю БД. В БД есть несколько основных таблиц фактов, гигантских размеров. Все несекционированные.
Занимают 90% объема всей БД. В общем обычная история.
Первым делом, как это было всегда в оракловых проектах , предлагаю секционировать эти таблицы по месяцам.
Начинается нехилый проект по секционированию. В downtime, конечно, перелив не укладывается - пишу скрипты перелива данных в секции. Потом выясняется, что данные меняются задним числом - поэтому пришлось на исходные таблицы навесить DML-триггеры, которые фиксируют факт изменения строки в отдельную лог- таблицу. Соответственно, в процедуре перелива обрабатываю данные этой лог таблицы.
Потом была проблема в том, что перелив одной операции в партицию (INSERT SELECT ... WHERE sale_date='month_year') падал то по таймауту, то по ошибке PG. PG очень не любит длинные транзакции, поэтому пришлось мелкими порциями строки переливать в партицию (cекционирование по месяцам).
Ну и конечно пришлось увеличивать дисковое пространство в облаке - объем БД увеличился. Смутило, что объем стал не в два раза больше, а в четыре раза (4). Почему-то в суматохе не обратил на это внимание.
В общем все позади, и в выходные ночью доливаю последние изменения, обрабатываю лог-таблицы и переключаю на новые таблицы: исходные таблицы переименовываю, а секционированные переименовываю в имя исходной таблицы).
На следующий день начался кошмар, который продолжался в течении пары недель.
Продолжение в третьей части ...
Forwarded from Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Forwarded from Andre
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
А что значит правильные модели?
Forwarded from Vadim
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Литературы очень мало, причем, понятия различаются.
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Data Engineering Wiki
Concepts - Data Engineering Wiki
Core Concepts How to build a data pipeline Data Modeling Batch vs Stream processing Indexing Relational vs Non-relational data OLTP vs OLAP Database ConceptsCAP Theorem Column-oriented Database Docum…