Data analysis - DA SQL

Talend Talend — это довольно популярная платформ для интеграции и управления данными. В основном используется как ETL-инструмент. Вообще, Talend - это целая экосистема продуктов, но самые популярные из них и наиболее нужные аналитикам - это Talend Open Studio (бесплатная версия, но уже считается старой) и Talend Data Integration Platform (платная версия, более расширенная по сравнению с Open Studio). 🟠ETL-процесс в Talend визуализируется в виде Job. Создаются они с помощью специальных операторов, с которыми можно просто взаимодействовать на уровне интерфейса Talend Studio (или TDI). После запуска Job трансформируется в код (в основном это Java). Выглядит этот процесс следующим образом: 1️⃣Сначала идет подключение к источнику данных. Вариантов источника может быть много: Talend поддерживает различные базы данных, файлы, CRM-системы, облачные хранилища и еще много всего. Подключение идет через вышеупомянутые операторы, например: ➖tFileInputDelimited - для CSV файлов ➖tFileInputExcel - для Excel файлов ➖tDBInput - для баз данных (MySQL, PostgreSQL, Oracle) ➖tHDFSInput - для Hadoop HDFS 2️⃣Затем опционально идет преобразование данных в нужный формат / вид. Осуществляется это с помощью операторов: ➖ tMap - универсальный оператор в части трансформации ETL-процесса. Отвечает за маппинг, вычисления, "джоины", форматирование... ➖tFilterRow - фильтрация данных ➖tAggregateRow - агрегатные функции ➖tSortRow - сортировка ➖tUniqRow - удаление дубликатов 3️⃣В конце данные загружаются в целевое место. Пример операторов, которые за это отвечают: ➖tDBOutput - запись в базу данных ➖tFileOutputDelimited - запись в CSV файл ➖tHDFSOutput - запись в HDFS ➖tLogRow - вывод в логи 🟠Также нельзя еще забывать, что Talend можно использовать для Data Quality и для Data Preparation. Для этого подойдёт всё тот же Talend Data Integration, но для Data Preparation можно еще использовать и Talend Data Preparation. Для Data Quality процесс выглядит так: 1️⃣Сначала выбирается источник данных по аналогии с описанным ETL-процессом. 2️⃣Затем делается профилирование через отдельный модуль Data Profiling вне Job'а (сколько null, дубликатов, какие min, max, avg и т.д.) 3️⃣Потом настраиваются правила качества данных (оператор tRule). Позволяет задавать требования по null, формату, разные числовые ограничения и т.п. 4️⃣В конце через Talend можно вывести отчет по проверке данных на DQ. Data Preparation во множестве ситуаций можно делать через обычный ранее упомянутый tMap. После подключения к источнику через tMap можно очищать данные (преобразовывать в нужный формат, удалять дубликаты...), заполнять пропуски и дополнять данные (например, добавлять маппинг)

Как провести корреляционный анализ Допустим, мы имеем датасет с банковскими транзакциями с информацией по клиентам, суммам, балансу, времени и т.д. На примере исследования гипотезы "Чем больше средний баланс клиента, тем больше его суммарные расходы" (упоминалось ранее) опишу, как можно проводить корреляционный анализ с помощью Python. 1️⃣Изначально посчитаем средний баланс и суммарные траты для каждого клиента c помощью обычной группировки (если нужно, то можно задать ограничение на временной период): import pandas as pd file_path = 'ПУТЬ.../bank_transactions.csv' df = pd.read_csv(file_path) stats = df.groupby('CustomerID').agg({ 'CustAccountBalance': 'mean', 'TransactionAmount': 'sum' }).rename(columns={ 'CustAccountBalance': 'avg_balance', 'TransactionAmount': 'total_spent' }) На выходе получим агрегированные по каждому клиенту данные, в которых будет указана общая сумма трат за всё время и средняя сумма баланса за это же время. 2️⃣Затем нужно посчитать коэффициент корреляции в рамках данных из п.1 и проверить эти результаты на статистическую значимость с помощью p_value. Возьмем корреляцию Спирмена, т.к. она устойчива к выбросам и не требует нормальности, а значит, для финансовых данных подходит лучше всего. from scipy.stats import spearmanr corr, pval = spearmanr(stats['avg_balance'], stats['total_spent']) print(corr, pval) Получим 2 числа: саму корреляцию и p_value. И если корреляция положительная и p_value < 0.05, значит, гипотеза поддерживается данными: есть статистически значимая связь между средним балансом и суммарными расходами. И, соответственно, чем выше коэффициент корреляции, тем связь будет сильнее. 3️⃣Для проверки гипотезы первых 2 пунктов может быть и достаточно. Но не лишним также будет еще построить тренд, чтобы посмотреть, как именно реагируют одни данные на изменения других. Для этого разделим датасет на сегменты по ранее рассчитанным средним балансам, условно на 5 групп: stats['balance_group'] = pd.qcut(stats['avg_balance'], q=5, labels=['Q1 (низкий)', 'Q2', 'Q3', 'Q4', 'Q5 (высокий)']) group_stats = stats.groupby('balance_group').agg({ 'avg_balance': 'mean', 'total_spent': 'mean' }).round(2) print(group_stats) Важно разделять сегменты по признакам из гипотезы (баланс), а не по, например, демографическим критериям. В итоге мы сожмем весь датасет до 5 групп, у каждой из которых будет выводится средний баланс по группе и общие траты по группе. 4️⃣Теперь считаем сам тренд. Для этого задаём группу Q1 как базис (самый низкий средний баланс) и считаем отношение суммы транзакций одной группы к другой (Q1/Q1, Q2/Q1, Q3/Q1 и т.д.): base_spent = group_stats['total_spent'].iloc[0] trend = [] for i in range(len(group_stats)): ratio = group_stats['total_spent'].iloc[i] / base_spent trend.append(ratio) print(trend) Результат получится в виде списка из 5 чисел, который всегда будет начинаться с 1. Он может многое показать: ▶️Например, если мы имеем плавный рост [1.0, 1.3, 1.7, 2.2, 3.0] (или снижение), то можно сделать вывод, что рост баланса стабильно влияет на изменение трат во всех диапазонах ▶️Резкий скачок (или снижение) [1.0, 1.8, 2.0, 2.1, 2.2] может показать, переход между какими группами наиболее влиятелен ▶️Если есть что-то наподобие такого [1.0, 1.2, 1.1, 1.8, 1.9] (небольшой рост, снижение, резкий скачок), то значит, что внутри датасета скрыты какие-то другие факторы, которые влияют на траты сильнее, чем рост баланса ▶️Если изменения незначительны [1.0, 1.1, 1.0, 1.2, 1.3], то, очевидно, никакой связи тут нет

Что такое CDC (Change Data Capture) CDC - это процесс отслеживания изменений в базе данных и передачи этих изменений в целевую систему (например, в DWH). Условно, у нас есть таблица в DDS слое (подробнее про слои), изменения в которой надо отслеживать (то есть отслеживать любые INSERT/ UPDATE/ DELETE). И информация о каждом таком изменении в виде отдельной записи поступает в специальную "техническую" таблицу, которая может находиться на слое Staging. И еще важно понимать, что основной принцип работы CDC — регистрация только изменившихся элементов, что снижает нагрузку на инфраструктуру и ускоряет процессы передачи информации. 🟠Зачем это нужно? В первую очередь, для скорости. Можно не ждать полноценного обновления данных в БД раз в неделю, а наблюдать за каждым изменением в режиме реального времени. Еще бывает полезно использовать CDC для наблюдения за полнотой данных. Например, классический ETL передает данные из источника в источник ежемесячно, и такими, какими они были по состоянию, условно, на 23.59 31-ого числа. Но посмотреть за тем, как менялись эти данные на уровне логов (кто что добавлял/изменял/удалял до того момента, как передать в ETL) можно с помощью CDC. С помощью CDC можно еще настроить миграцию данных из одной системы в другую. К примеру, при добавлении новой записи в БД эта запись дополнительно еще отражается в виде события (JSON), которое потом преобразуется для нужд уже другой БД. Ну и также это всё помогает для восстановления после сбоев, мониторинга активности, аномалий и т.п. 🟠Как это реализуется? ▶️Через встроенный в БД журнал транзакций. Например, SQL Server или Oracle предоставляют такие решения, которые позволяют отслеживать изменения через транзакционные логи. Этот метод высокоэффективен, так как он минимизирует вмешательство в операционные процессы. ▶️С помощью специально написанных триггеров в SQL (подробнее про триггеры). То есть мы сами пишем, например, что при любом изменении таблицы A нужно записывать эти изменения в таблицу Б. Метод подходит для небольших БД, т.к. вызывает дополнительную нагрузку на систему. ▶️Через сравнение состояний. То есть сравниваются 2 версии 1 таблицы в разные моменты времени, и если есть какие-то различия, то они записываются как изменения. Очевидно, что такой подход фиксирует далеко не все изменения, но зато он довольно прост в реализации. ▶️С помощью специальных сторонних инструментов, таких как Debezium, Talend, Informatica или Apache Kafka.

Apache Spark Apache Spark - это открытый движок (фреймворк) для распределенной обработки больших данных. Он нужен для того, чтобы принимать Python- и SQL-скрипты (также работает и со Scala, Java, R), разбивать эти скрипты на множество мелких задач и распределять их по узлам кластера для параллельного выполнения. Иными словами, Spark приходит на помощь, когда данных слишком уж много. Они не помещаются не то что в excel, но и даже памяти целого компьютера может быть мало. И вопрос не только во вместимости, а еще и в том, что python- или sql-запрос к этим данным будет обрабатываться очень долгое время. 🟠Как вообще работать с Apache Spark? 1️⃣Самое первое, очевидно, это нужно подключиться к данным. Важно понимать, что в самом Spark данные не хранятся (по крайней мере постоянно). Они могут храниться во многих источниках, в том числе и в привычных нам БД. Подключиться к той же самой БД можно через фреймворк для Python - PySpark, прописав параметры подключения. 2️⃣Затем уже непосредственно пишем скрипты (условно на Python) и передаваем их в Spark для дальнейшей обработки. Для этого нужен упомянутый ранее PySpark - любой код, написанный с помощью этого фреймворка, запускает вычислительные мощности Spark. Что касается SQL, то с ним можно работать как и с помощью PySpark, так и с помощью Spark Thrift Server: ▶️Если использовать PySpark, то SQL-скрипты можно писать внутри Python-кода, используя специальные модули (spark.sql) ▶️Если использовать Spark Thrift Server, то это даст нам возможность писать чистый SQL код без использования Python. Но для этого придется установить сторонний sql-клиент (например DBeaver), и, используя Spark Thrift Server, связать sql-клиент с БД, где хранятся данные. В этом случае выполнение sql-запроса будет так же запускать вычислительные мощности Spark. 3️⃣В конце, после выполнения нужных скриптов, результатами можно распоряжаться как и обычно: экспорт в файлы, загрузка в бд, визуализация через BI-инструменты... 🟠В чем принцип работы Apache Spark? Для того, чтоб разобраться чуть подробнее с тем, что у Spark под капотом, советую почитать про Hadoop, так как их часто сравнивают. Если кратко, то Hadoop состоит из двух основных частей: HDFS (система для хранения больших данных) и MapReduce (способ обработки больших данных). Spark же часто позиционируется как более современная замена MapReduce. В чем же основные отличия? ▶️MapReduce работает медленнее Spark, т.к. постоянно записывает данные на диск, тогда как Spark обрабатывает все в памяти ▶️Код также удобнее писать. В случае с MapReduce, любой код в конечном итоге преобразовывается в специальное задание для MapReduce, тогда как Spark из-за своих фреймворков понимает код в чистом виде. ▶️Spark имеет множество встроенных возможностей, тогда как для MapReduce нужны сторонние инструменты (например, нужен Hive, чтобы писать на SQL)

Как провести анализ динамики Продолжая затронутую ранее тему, расскажу немного подробнее о том, как именно построить динамику с помощью Python. 1️⃣Как проследить за изменением суммы и кол-ва транзакций и за изменением среднего баланса? Проще всего будет сгруппировать данные с помощью groupby по дате транзакции (key='TransactionDate'), рассчитав, соответственно, нужные нам метрики (сумму, кол-во, среднее...) и выбрав нужный интервал (пускай это будет неделя: freq='W'): import pandas as pd #Путь и первоначальная сортировка file_path = 'ПУТЬ.../bank_transactions.csv' df = pd.read_csv(file_path) df = df.sort_values('TransactionDate') #Группировка weekly_stats = df.groupby( pd.Grouper(key='TransactionDate', freq='W')).agg({ 'TransactionAmount': ['sum', 'count', 'mean'], 'CustAccountBalance': 'mean' }).round(2) weekly_stats.columns = [ 'Total_Amount', 'Transaction_Count', 'Avg_Transaction', 'Avg_Balance'] weekly_stats = weekly_stats.reset_index() print("Недельная статистика:") print(weekly_stats) В итоге получим агрегированные по неделям данные с расчетом общей суммы транзакций, их кол-ва, среднего размера транзакции и среднего размера баланса. Можно прикрутить к этому и расчет относительной и абсолютной динамики: weekly_growth = weekly_stats.set_index('TransactionDate').pct_change()*100 weekly_growth = weekly_growth.round(2) weekly_growth = weekly_growth.reset_index() print("\nНедельные приросты (%):") print(weekly_growth) weekly_abs_change = weekly_stats.set_index('TransactionDate').diff() weekly_abs_change = weekly_abs_change.reset_index() print("\nАбсолютные изменения:") print(weekly_abs_change) Всё это применимо как и к датасету в целом, так и к отдельно ранее рассчитанным сегментам. При необходимости можно также это всё визуализировать. 2️⃣Как выявить изменения временных паттернов? При анализе часовой активности логика тут примерно такая же: нужна группировка, но уже не по неделям, а по часам. Для этого нужно извлечь часы из времени транзакции и по этим часам сгруппировать датасет (или сегмент). # Извлекаем час из времени транзакции df['Hour'] = pd.to_datetime(df['TransactionTime'], format='%H:%M:%S').dt.hour # Количество транзакций по часам hourly_transactions = df.groupby('Hour').agg({ 'TransactionID': 'count', 'TransactionAmount': ['sum', 'mean'] }).round(2) hourly_transactions.columns = [ 'Transaction_Count', 'Total_Amount', 'Avg_Amount'] hourly_transactions = hourly_transactions.reset_index() print("Распределение транзакций по часам:") print(hourly_transactions) Очень похожим образом можно анализировать активность и по дням недели, и по кварталам, и по месяцам. Еще можно рассчитать среднее время между транзакциями для каждого клиента. Для этого выберем клиентов, у которых больше 1 транзакции, и в рамках этих клиентов отсортируем транзакции по их дате и времени, рассчитав среднюю разницу между ними. Получившиеся результаты (в секундах) можно преобразовать в дни и, соответственно, вывести результаты: customer_intervals = df.groupby('CustomerID').apply( lambda x: x.sort_values('TransactionDateTime')['TransactionDateTime'].diff().mean() if len(x) > 1 else pd.NaT ) customer_intervals_days = customer_intervals.dt.total_seconds() / (24 * 3600) interval_stats = { 'Avg_Days_Between_Transactions': customer_intervals_days.mean(), 'Median_Days_Between_Transactions': customer_intervals_days.median(), 'Min_Days_Between_Transactions': customer_intervals_days.min(), 'Max_Days_Between_Transactions': customer_intervals_days.max() } print("\nСтатистика времени между транзакциями (в днях):") for key, value in interval_stats.items(): print(f"{key}: {value:.2f}") Это даст нам сводные результаты по датасету или сегменту. Если мы хотим понять, как менялось это время, например, из месяца в месяц, то можно просто задать ограничения на входящие данные и получать эту статистику за каждый месяц (а не за весь период как сейчас), сравнивая потом эти месяца между собой.

Как можно проанализировать датасет и какие выводы сделать На примере датасета с банковскими транзакциями можно попытаться провести анализ для выявления тенденций, которые могут быть использованы банком для улучшения пользовательского опыта. Напомню, что мы имеем такие поля, как: ▶️Id транзакции ▶️Id клиента ▶️Дата рождения клиента ▶️Пол клиента ▶️Локация ▶️Дата транзакции ▶️Время транзакции ▶️Баланс счета клиента ▶️Сумма транзакции И еще в прошлый раз провели классификацию клиентов по признаку возраста, пола и локации, рассчитав по каждой группе агрегатные метрики. 🟠Что даст проведенная классификация? Мы сможем выявить, какие сегменты клиентов самые многочисленные, активные, богатые и т.п., всё это ранжировать, и возможно даже придумать правила по типу "высокая активность + высокий баланс = премиальные клиенты" и т.д.. Но это будет верно лишь в среднем для сегмента, даже если их будет порядка 100-150 (а нам все-таки в конечном итоге нужно будет взаимодействовать с каждым клиентом отдельно). В таком подходе есть риск: ▶️Потерять хорошего клиента в плохом сегменте ▶️Захватить плохого клиента из хорошего сегмента ▶️Или даже получить искаженные показатели для сегмента из-за нескольких аномальных клиентов внутри Если мы хотим сохранить демографические характеристики и внутри каждого демографического сегмента выделять уже другие сегменты, основываясь не на возрасте/поле/регионе, а на фин. показателях, то нужно будет проводить классификацию 2 уровня (строить иерархию), но уже чисто по финансовым критериям (кол-во транзакций, баланс, сумма транзакций и т.д.) Разновидностей тут много: можно при классификации учитывать и средний баланс, и максимальный, и оборот за период, и кол-во транзакций, можно сравнивать клиентов внутри демографической группы или даже придумать собственную скоринговую модель - всё зависит от бизнесовых потребностей. Главное, что нужно понимать: такая двухуровневая классификация даст понимание того, КАК общаться с клиентом (на основе демографии) и ЧТО предлагать клиенту (на основе финансовых активностей) 🟠Что еще можно выявить помимо сегментации? Например, начать определять динамику. Можно выявлять это всё как и в рамках датасета, так и в рамках отдельных сегментов. Можно наблюдать очень много за чем: ▶️Кол-во новых клиентов за периоды ▶️Изменение численности сегмента (может указывать как и на отток/приток клиентов в целом, так и на их миграцию из одного сегмента в другой) ▶️Изменение кол-ва транзакций, средней суммы транзакций, среднего размера баланса (как правило, снижение этих показателей может предсказать отток клиентов, увеличение - возможность для создания премиум продуктов) ▶️Изменение временных паттернов поведения - т.е. наблюдаем за временем, когда наибольшая / наименьшая активность (может показывать разные технические сбои, изменение потреб. привычек и т.п.) 🟠Можно также выявить временные паттерны, посчитав: ▶️Кол-во транзакций по часам (распределение активности в течение дня) ▶️Кол-во транзакций по дням недели ▶️Сезонность по месяцам/кварталам ▶️Среднее время между транзакциями для каждого клиента ▶️Пиковые часы/дни нагрузки на систему Считать всё это можно и в целом в рамках всего датасета, и в рамках отдельных клиентских сегментов, зависит опять же от целей. Но в целом это даст нам понимание, когда лучшее время для коммуникации с клиентами и когда, например, лучше всего проводить техобслуживание и прочие технические аспекты. 🟠Еще, как идея, можно попробовать провести корреляционный анализ и найти какие-нибудь взаимосвязи, например, зависимость размера/частоты транзакции от баланса, и на основании этого делать определенные выводы. Условно, если есть связь, что чем больше баланс, тем активнее клиент тратит (особенно если сравнивать не разных клиентов, а временную динамику у 1 клиента), то можно побуждать его активнее пользоваться накопительными счетами; если связь обратная (частые транзакции увеличивают в итоге баланс), то можно предлагать выгодный кэшбек. 🟠Ну и, конечно, куда же без поиска аномалий. На эту тему у меня были посты тут и тут (тоже про транзакции)

Довольно частая ситуация, особенно в финансах, когда мы имеем: 1️⃣Какой-либо финансовый показатель, который = Х 2️⃣Множество корректировок t1, t2... t100 (отрицательные и положительные), которые суммируются с Х 3️⃣На выходе получаем значение Y1, но должно было получиться значение Y2. При этом мы знаем, что какие-то из этих корректировок нужно исключить, чтобы результат из Y1 стал нужным нам Y2. Но не знаем, какие именно это должны быть корректировки и сколько вообще их должно быть. Как вариант выхода из этой ситуации можно рассмотреть перебор всех возможных чисел t, которые в сумме дадут ту самую разницу. На помощь как обычно придет питон. Рассмотрим на примере: X = 100 корректировки = [10, 20, -5, 15, -10, 25, -15] Y1 = 140 Y2 = 155 (расхождение с Y1 - 15) Сам скрипт, который автоматизирует подбор чисел: import itertools X = 100 adjustments = [10, 20, -5, 15, -10, 25, -15] Y1 = X + sum(adjustments) Y2 = 155 target_sum_remaining = Y2 - X for r in range(len(adjustments)): for exclude_combo in itertools.combinations(adjustments, r): remaining = [a for a in adjustments if a not in exclude_combo] if sum(remaining) == target_sum_remaining: print(f"{exclude_combo} = {sum(exclude_combo)}") В итоге получим 4 комбинации корректировок, каждая из которых дает в сумме то самое расхождение в -15: [-15] [-5, -10] [10, -10, -15] [-5, 15, -10, -15] Если их исключить из суммирования, то получится нужный нам результат = 155. В контексте финансов способ, конечно, не совсем корректный, но он быстро подсвечивает все подозрительные корректировки, на которые можно обратить внимание и уже дальше их анализировать.

Пересчет (Processing) OLAP-кубов Пересчет OLAP-куба - это процесс загрузки новых данных из источника (как правило - из хранилища данных) в саму структуру куба. Для дальнейшего обсуждения нужно разобраться с основными понятиями, которые связаны с OLAP-кубами: ▶️Партиции. Это разделение куба на части (например, данные за прошлый год хранятся в одном месте, за этот - в другом). ▶️Измерения. Показывают, что именно считается в кубе, например, товары: яблоки, груши, арбузы и т.д. Иными словами, это нечисловые данные, по которым можно осуществлять группировку. Часто измерения бывают иерархическими. ▶️Факты. Показывают, в отличие от измерений, именно числовые данные (например, 5 яблок, 10 груш и т.д.). Хранятся в таблице фактов и связываются с измерениями по id (принцип напоминает логику построения архитектуры реляционных БД) ▶️Меры. Расчётные выражения (формулы), которые определяют, как нужно агрегировать данные. Они не хранят готовые значения, а выполняются непосредственно при запросе. ▶️Агрегаты. Грубо говоря, это те же самые меры, только уже предварительно посчитанные и сохранённые. ▶️Индексы. Используются для ускорения выполняемых OLAP-запросов, например, для расчёта средних значений. 🟠Существует несколько основных способов пересчёта куба (или отдельных его элементов): ▶️Process Full. Подразумевает под собой полную перестройку куба (или измерения и партиции), а именно уничтожение текущего и постройки вместо него нового с нуля. Обычно используется такой способ, когда структура куба изменилась (добавились новые измерения, меры), когда куб развёртывается впервые или когда произошли серьёзные изменения в исходных данных. Это крайне долгий и ресурсоемкий процесс, но который зато обеспечивает качество и актуальность данных. ▶️Process Incremental. Добавляет только новые или изменённые записи в существующие данные без полной перезагрузки. Также может для новых добавленных данных обновить агрегаты. Используется в основном для регулярного дополнения существующих данных новыми (например, раз в неделю) ▶️Process Data. Загружает только сырые данные в таблицу фактов или измерений. Не пересчитывает агрегаты и индексы (после этого требуется Process Index). Главное отличие от упомянутого ранее Process Incremental - это перезагрузка всех данных в целевых таблицах, а не только тех, которые, условно, добавились только недавно. ▶️Process Index. Перестраивает только индексы и агрегаты без загрузки данных. Применяется, как правило, для ускорения выполнения запросов и используется после process data (для актуализации агрегатов) ▶️Process Update. Обновляет измерения. Полезно в случаях, когда, например, изменились справочники. ▶️Process Clear - полная очистка (будь то куб или партиция

Think-cell Think-cell - это надстройка для Microsoft PowerPoint и Excel, предназначенная для автоматизации создания слайдов в презентациях. 🟠Главная ее особенность - динамическая связь с экселем. То есть в качестве источника данных для диаграммы можно сослаться напрямую на эксель-файл и потом, при обновлении данных, диаграмма будет сразу же автоматически изменяться. Всё это делается через интуитивно понятный интерфейс PowerPoint. Это дает широкий простор для автоматизации процесса создания презентаций. Например, одна из типовых ситуаций: данные хранятся в ЕХД, периодически выгружаются, подгоняются под типовой шаблон в экселе, на основе которого строятся диаграммы в PP. Автоматизировать этот процесс можно так: Подключиться к БД и заселектить нужные данные (подробнее) from sqlalchemy import create_engine import pandas as pd conn = "ПАРАМЕТРЫ ПОДКЛЮЧЕНИЯ К БД" engine = create_engine(conn) sql_query = """ SQL-ЗАПРОС НА ВЫБОРКУ """ df = pd.read_sql(sql_query, engine) и с помощью xlsxwriter сохранить данные в эксель в нужном виде (подробнее): with pd.ExcelWriter('file.xlsx', engine='xlsxwriter') as writer: df.to_excel(writer, sheet_name='Лист_1', index=False) workbook = writer.book worksheet = writer.sheets['Лист_1'] Так как в нашем случае обновление шаблонное и периодическое, можно сохранять xlsx-файл с заменой - Think-cell будет распознавать изменения и автоматически обновлять построенные диаграммы. Так что по факту, нажимая лишь "одну кнопку", можно выгружать данные, сохранять в эксель и обновлять связанные с ним презентации. 🟠Говоря о дополнительных возможностях think-cell, он позволяет строить более продвинутые визуализации (Waterfall charts, матричные диаграммы, диаграммы Ганта, каскадные диаграммы), а также при желании можно настроить автоматические расчеты и автоматическое форматирование через интерфейс PowerPoint.