По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В интернете можно найти множество статей с описанием шаблонов масштабирования баз данных (БД), но, в основном, это разрозненная информация с перечислением методик и практически без объяснений.
Ниже приведено подробное руководство по шаблонам масштабирования БД, пошаговым объяснением принципов их работы и примерами использования.
Практический пример
Предположим, вы создали стартап, который предлагает совместные поездки по дешевой цене. Вы выбрали город для поездок, а первая реклама привлекла не более 10 клиентов.
Вы храните информацию обо всех клиентах, поездках, местах, бронированиях и историях заказов в одной и той же БД и, скорее всего, на одной физической машине. У вас нет навороченного кеширования или конвейера обработки больших данных, ведь ваше приложение только появилось. На данный момент это – идеальный вариант: в базе мало клиентов, и система, вряд ли, бронирует по поездке каждые 5 минут.
Но время идет. В вашей системе регистрируется все больше людей, ведь это самый дешевый сервис на рынке. Да и реклама сделала свое дело. Вы получаете по 10 заказов в минуту. Постепенно это количество увеличивается до 20, а затем и 30 бронирований в минуту.
В этот момент вы замечаете, что система начинает тормозить: время отклика API сильно увеличилось, а некоторые транзакции блокируются или зависают и, в конечном итоге, не проходят. Время ответа приложения также увеличилось, что вызвало недовольство клиентов. Как же решить эту проблему?
Шаблон №1 – оптимизация запросов и реализация пула соединений
Первое решение, которое приходит на ум: кэш слишком часто использует нединамические данные (история бронирования, история платежей, профили пользователей и т.д.). Но прикладным уровнем кеширования вы не сможете решить проблему с временем отклика API, предоставляющим динамические данные (текущее местоположение водителя, ближайшая машина для конкретного клиента, текущая стоимость поездки после выхода на маршрут и т.д.).
Вы приходите к выводу, что база данных слишком нормализована, поэтому вы решаете ее немного «разбавить» и добавляете несколько избыточных столбцов (такие столбцы часто попадают в операторы WHERE или JOIN ON в запросах). Это сокращает количество запросов на соединение, разбивает большие запросы на несколько маленьких и добавляет их результаты на прикладной уровень.
Можно заняться и параллельной оптимизацией – настроить подключения к базам данных. Внешние и клиентские библиотеки БД доступны практически для всех языков программирования. Для кеширования подключений к БД можно воспользоваться библиотеками пула соединений. Либо вы можете настроить размер пула соединений в самой СУБД.
Создание сетевого подключения – вещь весьма затратная, поскольку требует двусторонней коммуникации между клиентом и сервером. Пулы соединений помогают оптимизировать количество подключений. Библиотеки пула соединений реализуют мультиплексирование подключений – несколько потоков приложения могут пользоваться одним и тем же подключением.
Вы замеряете время отклика API и замечаете снижение задержки на 20-50% (или даже больше). На данный момент это хорошая оптимизация.
Затем вы расширили бизнес на еще один город и получили больше клиентов. Постепенно вы доходите до 80-100 бронирований в минуту. Ваша система не в состоянии справиться с таким объемом. Вы вновь замечаете увеличение времени ожидания API, а слой базы данных не справляется с нагрузкой. Но в этот раз оптимизация запросов не дает вам существенного улучшения производительности. Вы проверяете метрики системы и видите, что дисковое пространство заполнено, ЦП занят в 80% времени, а ОЗУ переполняется слишком быстро.
Шаблон № 2 – вертикальное масштабирование или масштабирование вверх
Изучив все системные метрики, вы не находите другого решения, кроме как обновить аппаратное обеспечение системы. Вы увеличиваете размер оперативной памяти в 2 раза, а объем диска – раза в 3. Это называется вертикальным масштабированием. Вы сообщаете группе по обслуживанию инфраструктуры, команде devops или агентам сторонних центров обработки данных (ЦОД) о необходимости обновления вашей машины.
Но как настроить саму машину для вертикального масштабирования?
Вы выделяете машину большего объема. Один из подходов заключается в том, чтобы не переносить данные со старой машины вручную, а настроить новую машину в качестве копии, или реплики (replica), уже существующего устройства, или источника (primary), прописав временную конфигурацию первичной реплики (primary replica). После завершения репликации назначьте новую машину в качестве primary и отключите старую. Поскольку обрабатывать запросы планируется на этой новой машине, все чтение/запись также будет вестись на ней.
Отлично. Вы прокачали систему, и теперь все работает намного быстрее.
Ваш бизнес идет на ура, и вы решаете расшириться еще до 3 городов. Теперь вы ведете деятельность в 5 городах. Трафик увеличился втрое, вы получаете по 300 заказов в минуту. Проблема с производительностью вернулась: размер индекса сильно сказывается на памяти, базу данных необходимо постоянно поддерживать, а сканирование таблицы с индексом замедлилось до невозможности. Вы подсчитали стоимость дальнейшего масштабирования системы, но цена не внушает доверия. Так что же делать?
Шаблон №3 – разделение ответственности на команды и запросы (CQRS):
Вы понимаете, что та самая большая машина не в состоянии обработать все запросы на чтение/запись. Да и чаще всего компаниям нужны транзакционные возможности на запись (write), а не чтение (read). Вас даже устраивает небольшая несогласованность данных или замедление операций read. В принципе, раньше это тоже не казалось вам проблемой. Вы решаете, что неплохо было бы разделить операции чтения и записи на физической машине. Это позволит отдельным машинам выполнять больше операций чтения/записи.
Теперь вы берете целых 2 большие машины и настраиваете их репликами для текущего компьютера. Репликация базы данных решит вопрос с переносом данных с primary машины на реплики. Вы перенаправляете все запросы на чтение (буква Q в CQRS, что означает «запрос» - Query) в реплики – любая реплика может обслуживать любой запрос на чтение. А все запросы на запись остаются на первичной машине. Возможна небольшая задержка в репликации, но в вашем конкретном случае это не критично.
Вариант с настройкой primary-replica вполне подходит для большинства стартапов среднего масштаба, получающих по сотням тысяч запросов ежедневно… но при условии, что компании периодически архивируют старые данные.
Вы вновь расширились на 2 города, и замечаете, что primary-машина не справляется со всеми запросами на запись. Многие такие запросы приходят с опозданием. Более того, задержка между primary и replica начинает сказываться на клиентах и водителях. Например, поездка завершена, клиент успешно ее оплачивает, но водитель не видит платеж, поскольку активность клиента – это запрос на запись, который идет на машину primary, а активность водителя – это запрос на чтение, который приходит на одну из реплик. Вся система настолько замедлилась, что водитель не видит платежа как минимум секунд 30, и это вызывает недовольство как со стороны клиента, так и у самого водителя. Как же поступить сейчас?
Шаблон №4 – репликация с несколькими источниками
Конфигурация primary-replica помогла вам успешно масштабироваться, однако теперь для операций записи не хватает возможностей. Быть может, вы согласитесь слегка пожертвовать быстротой запросов на чтение. А почему бы не перенести запросы на запись тоже в реплики?
В модели с несколькими источниками (multi-primary) все машины работают как источник, и как реплика. Такая структура чем-то напоминает замкнутый круг из машин: A->B->C->D->A. «B» может реплицировать данные из «A», «C» – реплицирует данные из «В», «D» – дублирует данные из «C», а «A» делает тоже самое из «D». Вы можете выполнять операцию чтения и одновременно записывать данные в любой узел; вы можете транслировать запрос во все узлы, а значение вернет один из откликнувшихся узлов. Все узлы имеют одинаковую схему БД, один и тот же набор таблиц, индекс и т.д. Но нужно следить, чтобы в узлах одной таблицы не было конфликта по id , иначе при трансляции запросов несколько узлов вернут разные данные по одному и тому же id.
Вообще считается, что для ID лучше использовать UUID или GUID. Еще один недочет данной системы: из-за трансляции запросов и поиска корректного результата, запросы на чтение могут оказаться неэффективными. Это, своего рода, принцип распределения/сборки в действии.
И вот вы вновь масштабировали бизнес. В этот раз на 5 новых городов. Система не справляется. Теперь вам нужно обрабатывать по 50 запросов в секунду. Вам очень не хватает обработки большого количества параллельных запросов. Но как это сделать?
Шаблон №5 – декомпозиция
Вы знаете, что база данных location получает много трафика на чтение/запись. Вполне возможно, что соотношение записи к чтению составляет 7:3. Это создает большую нагрузку на существующие БД. В таблицах location содержится несколько первичных данных: долгота (longitude), широта (latitude), отметка времени (timestamp), ID водителя (driver id), ID поездки (trip id) и т.д.
Там практически нет информации о поездках или данных пользователя, его платежах и т.д. Возможно, стоит разделить таблицы location на отдельную схему? Как насчет того, чтобы распределить эту БД по отдельным машинам с корректно настроенной конфигурацией primary-replica или multi-primary?
Это называется декомпозицией данных по функциональности. В разных БД можно хранить данные, разделенные по функциональному признаку, а результат (при необходимости) агрегируется на серверном уровне. Такой способ позволит вам масштабировать нужный функционал с большим количеством запросов на чтение/запись. В то же время прикладной или серверный уровень приложения должен будет заняться объединением результатов, что приведет к значительному изменению кода.
Теперь представьте себе, что вы масштабировались до 20 городов в своей стране и планируете открыть филиалы в Австралии. Растущий спрос на ваше приложение требует все более быстрого времени ответа. Ни один из методов выше с этим не поможет. Вам нужно масштабировать систему так, чтобы при расширении в другие страны/регионы не приходилось слишком часто проектировать и менять архитектуру. Как же тогда поступить?
Шаблон №6 – горизонтальное масштабирование
Вы хорошо загуглили эту тему, почитали массу статей о том, как другие компании решали такую проблему, и поняли, что настал момент масштабироваться горизонтально. Вы выделили, скажем, 50 машин – все с одинаковой схемой БД и одинаковыми наборами таблиц. На каждой машине хранится лишь часть данных.
Поскольку во всех БД хранится один и тот же набор таблиц, вы можете спроектировать систему таким образом, чтобы реализовать привязку данных (то есть все связанные данные хранятся на одной машине). В каждой машине может быть своя реплика; реплики используются для восстановления после сбоя. Каждая такая база данных называется «шардом». На физической машине может быть один или несколько шардов – их количество зависит от нужной вам схемы проектирования. Вы должны придумать ключ шардирования, который бы всегда относился к одной и той же машине. Представьте себе много машин с кучей связанных данных в одном наборе таблиц; операции на чтение/запись запрашиваются для одной и той же строки или набора ресурсов на одной и той же машине с БД.
Реализовать шардинг довольно сложно. По крайней мере, так говорят инженеры. Но при обслуживании миллионов или даже миллиардов запросов, рано или поздно вам придется пойти на столь непростой шаг.
Настроив шардинг, вы уверены, что сможете масштабироваться во многие страны. Ваш бизнес разросся настолько, что инвесторы вынуждают вас расширяться на другие континенты. И тут опять возникают проблемы. Все то же время отклика API. Ваш сервис находится в США, и у пользователей из Вьетнама возникают трудности при бронировании. Но почему? И что же делать?
Шаблон №7 – умное сегментирование центров обработки данных
Ваш бизнес развивается в Америке, Южной Азии и нескольких странах Европы. Каждый день вы получаете миллионы заказов, а ваш сервер атакуют миллиарды запросов. Поздравляю! Это пиковый момент в вашей деятельности.
Запросы из приложения поступают с разных континентов и проходят через сотни или даже тысячи серверов в интернете, поэтому время отклика растет. Может, распределить трафик по центрам обработки данных? Вы могли бы настроить ЦОД в Сингапуре, и он бы обрабатывал все запросы из Южной Азии. Затем сделать еще один в Германии – он займется всеми запросами из европейских стран, и оставить ЦОД в Калифорнии для обработки американских запросов.
Кроме того, вам понадобится репликация между ЦОД – на случай, если потребуется восстановление после сбоя. Если центр обработки данных в Калифорнии выполняет репликацию сингапурского ЦОД, то в случае аварии в Калифорнии (стихийные бедствия, отсутствие электричества и т.д.), все запросы из США будут передаваться в Сингапур и наоборот.
Такой метод масштабирования подходит для: обслуживания миллионов клиентов из разных стран, сохранения всех данных и поддержания постоянной доступности системы.
Заключение
В статье приведены общие методы по масштабированию базы данных. Стоит сказать, что у большинства инженеров нет достаточных возможностей для реализации всех шаблонов. Но лучше знать о существовании таких схем, которые в будущем могут помочь вам с проектированием архитектуры и систем.
Третья статья будет посвящена поиску и устранению неисправностей EtherChannels. Большинство проблем с EtherChannels происходит из-за неправильной конфигурации.
Предыдущие статьи этого цикла:
Устранение неполадок коммутации Cisco
Траблшутинг STP (Spanning tree protocol)
Case #1
В этом сценарии есть только два коммутатора и два интерфейса. Идея состоит в том, чтобы сформировать etherchannel путем объединения интерфейсов FastEthernet 0/13 и 0/14, но это не работает
Сначала мы проверим, все ли интерфейсы работают. Да они все работают.
Мы можем проверить, что port-channel interface был создан, но он не работает.
Вот хорошая команда для проверки EtherChannel. Используйте суммарную информацию от команды show etherchannel summary, чтобы увидеть ваши port-channels. Мы видим, что коммутатор A настроен для LACP и коммутатор B для PAgP, а это никогда не будет работать.
Лучшая команда для использования это show etherchannel detail. Это дает вам много информации, но нам особенно интересно узнать, настроен ли LACP для пассивного или активного режима. Интерфейсы в активном режиме будут "активно" пытаться сформировать EtherChannel. Интерфейсы в пассивном режиме будут отвечать только на запросы LACP.
Вот вывод команды show etherchannel detail на коммутаторе B. Мы видим, что он был настроен для PAgP, и интерфейсы настроены для desirable режима. Если бы они были настроены на автоматический режим, мы бы увидели флаг А.
SwitchB(config)#no interface po1
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode passive
SwitchB(config-if)#exit
SwitchB(config)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode passive
Давайте сначала избавимся от port-channel interface. Если мы этого не сделаем, вы увидите ошибку при попытке изменить channel-group mode на интерфейсах.
После изменения конфигурации мы видим, что port-channel1 поднялся. Задача решена!
Извлеченный урок: убедитесь, что вы используете один и тот же режим EtherChannel с обеих сторон.
Case #2
Ну что же давайте рассмотрим другую ошибку! Та же топология и EtherChannel, который не функционирует:
Мы проверяем, что port-channel interface существует, но он не работает с обеих сторон.
Мы также видим, что интерфейс FastEthernet 0/13 и 0/14 были добавлены к port-channel interface.
Интерфейсы FastEthernet рабочие, поэтому мы знаем, что проблема не в этом. Давайте углубимся в конфигурацию EtherChannel.
Мы видим, что FastEthernet 0/13 и 0/14 на коммутаторе A оба настроены на автоматический режим PAgP (из-за флага "A").
FastEthernet 0/13 и 0/14 на коммутаторе B также настроены на автоматический режим PAgP. Это никогда не сбудет работать, потому что оба коммутатора теперь пассивно ждут сообщений PAgP.
SwitchB(config)#interface fa0/13
SwitchB(config-if)#channel-group 1 mode desirable
SwitchB(config-if)#interface fa0/14
SwitchB(config-if)#channel-group 1 mode desirable
Давайте изменим один из коммутаторов, чтобы он активно отправлял сообщения PAgP.
EtherChannel сейчас работает. Проблема решена!
Извлеченный урок: при использовании PAgP убедитесь, что хотя бы один из коммутаторов использует требуемый режим, или в случае LACP убедитесь, что один коммутатор находится в активном режиме.
Case #3
Еще одна ситуация: EtherChannel настроен между коммутатором A и коммутатором B, но клиент жалуется, что соединение медленное ... что может быть не так?
Быстрая проверка говорит нам, что port-channel interface работает.
Команда show etherchannel detail дает нам много выходных данных, но она так же нам говорит, что происходит. Вы видите, что интерфейс FastEthernet 0/13 и 0/14 были настроены для port-channel, но коммутатор не смог связать их, потому что FastEthernet 0/14 настроен на 10 Мбит. Возможно, что это основная причина медленной скорости передачи данных.
Мы будем использовать один из операторов для команды show. Нас интересует только то, чтобы увидеть вероятную причину, которую команда "show etherchannel detail" покажет.
SwitchA(config)#interface fa0/14
SwitchA(config-if)#speed auto
SwitchB(config)#interface fa0/14
SwitchB(config-if)#speed auto
Давайте изменим скорость на авто. Мы должны убедиться, что FastEthernet 0/13 и 0/14 имеют одинаковую конфигурацию.
Вероятно, вы увидите пару сообщений о том, что ваши интерфейсы переходят в состояние up и down.
Теперь мы видим, что оба интерфейса были добавлены в port-channel... проблема решена!
Извлеченный урок: убедитесь, что все интерфейсы, которые будут добавлены в port-channel, имеют одинаковую конфигурацию!
В этой статье мы расскажем как интегрировать Python c Excel и Word, чтобы без проблем создавать автоматические отчеты. Microsoft Excel и Microsoft Word – это, без доли сомнений, две наиболее широко используемые программы как в мире бизнеса, так и в некорпоративной сфере. Они практически являются синонимами слову «работа». Как правило, не проходит и недели, чтобы мы тем или иным способом не воспользовались их преимуществами. И хотя для обычных повседневных задач автоматизация не требуется, бывают случаи, когда она может стать необходимостью. А именно, когда у вас есть множество диаграмм, рисунков, таблиц и отчетов, которые необходимо сделать, это может стать очень утомительным занятием, если все это выполнять вручную. А это не должно быть так. На самом деле существует способ создать конвейер в Python, где можно будет легко интегрировать эти программы для создания электронных таблиц в Excel, а затем передавать результаты в Word для создания отчета практически мгновенно.
Openpyxl
Познакомьтесь с Openpyxl, возможно, одной из самых универсальных привязок в Python, которая превращает взаимодействие с Excel буквально в прогулку по парку. Используя этот пакет, вы сможете читать и записывать все новые и старые форматы Excel, то есть .xlsx и .xls. Openpyxl позволяет заполнять строки и столбцы, выполнять формулы, создавать 2D- и 3D-диаграммы, маркировать оси и заголовки, а также имеет множество других возможностей, которые могут пригодиться. Однако здесь наиболее важно то, что этот пакет позволяет вам перебирать бесконечное количество строк и столбцов Excel, тем самым избавляя вас от всех этих утомительных вычислений и построения графиков, которые вам приходилось делать ранее самим.
Python-docx
А затем появляется Python-docx – пакет для Word – то же, что Openpyxl для Excel. Если вы все еще не изучили их документацию, то вам все же стоит на нее взглянуть. Python-docx – без преувеличения один из самых простых и понятных наборов инструментов, с которыми я работал с тех пор, как начал работать с Python. Он позволяет автоматизировать создание документов, автоматически вставляя текст, заполняя таблицы и отображая изображения в отчете без каких-либо усилий.
Без лишних церемоний давайте создадим наш собственный автоматизированный конвейер. Запустите IDE по вашему выбору и установите следующие пакеты:
pip install openpyxlpip install python-docx
Автоматизация Microsoft Excel
Для начала загрузим уже созданную книгу Excel (как показано ниже):
workbook = xl.load_workbook('Book1.xlsx')
sheet_1 = workbook['Sheet1']
Затем мы пройдемся по всем строкам в нашей электронной таблице для того, чтобы вычислить и вставить значение мощности, которую мы получим, умножив ток на напряжение:
for row in range(2, sheet_1.max_row + 1):
current = sheet_1.cell(row, 2)
voltage = sheet_1.cell(row, 3)
power = float(current.value) * float(voltage.value)
power_cell = sheet_1.cell(row, 1)
power_cell.value = power
Как только мы сделаем это, то мы сможем использовать рассчитанные значения мощности для построения линейной диаграммы, которая будет вставлена в указанную ячейку, как показано ниже:
values = Reference(sheet_1, min_row = 2, max_row = sheet_1.max_row, min_col = 1, max_col = 1)
chart = LineChart()
chart.y_axis.title = 'Power'
chart.x_axis.title = 'Index'
chart.add_data(values)
sheet_1.add_chart(chart, 'e2')
workbook.save('Book1.xlsx')
Извлечение диаграммы
Теперь, когда мы построили нашу диаграмму, нам нужно ее извлечь в формате изображения для того, чтобы мы могли использовать ее в нашем отчете Word. Для начала объявим точное местоположения нашего файла Excel, а также место, куда мы хотим сохранить изображение получившейся диаграммы:
input_file = "C:/Users/.../Book1.xlsx"
output_image = "C:/Users/.../chart.png"
Затем необходимо получить доступ к таблице, используя следующий метод:
operation = win32com.client.Dispatch("Excel.Application")
operation.Visible = 0
operation.DisplayAlerts = 0
workbook_2 = operation.Workbooks.Open(input_file)
sheet_2 = operation.Sheets(1)
И далее вы можете перебрать все диаграммы в таблице (если их больше одной) и сохранить их в указанном месте:
for x, chart in enumerate(sheet_2.Shapes):
chart.Copy()
image = ImageGrab.grabclipboard()
image.save(output_image, 'png')
passworkbook_2.Close(True)
operation.Quit()
Автоматизация Microsoft Word
Теперь, когда у нас есть изображение диаграммы, мы должны создать шаблон документа, который представляет собой обычный документ Microsoft Word (.docx), сформированный именно так, как нам необходимо, чтобы наш отчет имел определенный тип и размер шрифта, нужное форматирование и структуру страницы. Далее, все, что нам необходимо сделать, это создать заполнители для нашего автоматизированного содержимого, то есть значений таблиц и изображений, и объявить их с переменными, как показано ниже.
Внутри двойных фигурных скобок {{variable_name}} может быть объявлен любое автоматизированное содержимое, включая текст и изображения. Для таблиц вам необходимо создать таблицу с шаблонной строкой, в которую включены все столбцы, а затем вам необходимо добавить еще одну строку выше и одну строку ниже со следующими обозначениями:
Первая строка:
{%tr for item in variable_name %}
Последняя строка:
{%tr endfor %}
На рисунке выше указаны следующие имена переменных:
table_contents для словаря Python, в котором будут храниться наши табличные данные.
Index для ключей словаря (первый столбец).
Power, Current и Voltage для значений словаря (второй, третий и четвертый столбцы).
Затем мы импортируем наш документ-шаблон в Python и создаем словарь, в котором будут храниться значения нашей таблицы:
template = DocxTemplate('template.docx')
table_contents = []for i in range(2, sheet_1.max_row + 1):
table_contents.append({
'Index': i-1,
'Power': sheet_1.cell(i, 1).value,
'Current': sheet_1.cell(i, 2).value,
'Voltage': sheet_1.cell(i, 3).value
})
Далее мы импортируем изображение диаграммы, которое ранее мы создали в Excel, и создаем еще один словарь для создания экземпляров всех переменных-заполнителей, объявленных в документе-шаблоне:
image = InlineImage(template,'chart.png',Cm(10))context = {
'title': 'Automated Report',
'day': datetime.datetime.now().strftime('%d'),
'month': datetime.datetime.now().strftime('%b'),
'year': datetime.datetime.now().strftime('%Y'),
'table_contents': table_contents,
'image': image
}
И, наконец, мы отображаем отчет с нашей таблицей значений и изображением диаграммы:
template.render(context)
template.save('Automated_report.docx')
Заключение
И вот, мы получили автоматически созданный отчет Microsoft Word с числами и диаграммами, созданными в Microsoft Excel. При этом у вас есть полностью автоматизированный конвейер, который можно использовать для создания любого количества таблиц, диаграмм и документов.
Исходный код программы
import openpyxl as xl
from openpyxl.chart import LineChart, Reference
import win32com.client
import PIL
from PIL import ImageGrab, Image
import os
import sys
from docx.shared import Cm
from docxtpl import DocxTemplate, InlineImage
from docx.shared import Cm, Inches, Mm, Emu
import random
import datetime
import matplotlib.pyplot as plt
######## Generate automated excel workbook ########
workbook = xl.load_workbook('Book1.xlsx')
sheet_1 = workbook['Sheet1']
for row in range(2, sheet_1.max_row + 1):
current = sheet_1.cell(row, 2)
voltage = sheet_1.cell(row, 3)
power = float(current.value) * float(voltage.value)
power_cell = sheet_1.cell(row, 1)
power_cell.value = power
values = Reference(sheet_1, min_row = 2, max_row = sheet_1.max_row, min_col = 1, max_col = 1)
chart = LineChart()
chart.y_axis.title = 'Power'
chart.x_axis.title = 'Index'
chart.add_data(values)
sheet_1.add_chart(chart, 'e2')
workbook.save('Book1.xlsx')
######## Extract chart image from Excel workbook ########
input_file = "C:/Users/.../Book1.xlsx"
output_image = "C:/Users/.../chart.png"
operation = win32com.client.Dispatch("Excel.Application")
operation.Visible = 0
operation.DisplayAlerts = 0
workbook_2 = operation.Workbooks.Open(input_file)
sheet_2 = operation.Sheets(1)
for x, chart in enumerate(sheet_2.Shapes):
chart.Copy()
image = ImageGrab.grabclipboard()
image.save(output_image, 'png')
pass
workbook_2.Close(True)
operation.Quit()
######## Generating automated word document ########
template = DocxTemplate('template.docx')
#Generate list of random values
table_contents = []
for i in range(2, sheet_1.max_row + 1):
table_contents.append({
'Index': i-1,
'Power': sheet_1.cell(i, 1).value,
'Current': sheet_1.cell(i, 2).value,
'Voltage': sheet_1.cell(i, 3).value
})
#Import saved figure
image = InlineImage(template,'chart.png',Cm(10))
#Declare template variables
context = {
'title': 'Automated Report',
'day': datetime.datetime.now().strftime('%d'),
'month': datetime.datetime.now().strftime('%b'),
'year': datetime.datetime.now().strftime('%Y'),
'table_contents': table_contents,
'image': image
}
#Render automated report
template.render(context)
template.save('Automated_report.docx')