Zanak

Не очень понятно, зачем вам питон, если вы на нем не разрабатываете.
Но обо всем по порядку:
- язык ставится в любом случае. php, python, ruby, что-то еще, в зависимости от того, какое приложение вы разворачиваете.
- вебсервер вам в любом случае ставить. апач, нжинкс, лайти или что - то еще, это дело личных предпочтений.
- БД тоже ставится по определению. установка соответствующего драйвера - обязательная процедура для любого языка.
- установка сервера приложений. это тоже общая часть для любого языка. у каждого языка, почти наверняка, есть свое, специфичное решение. для python это gunicorn, для ruby unicorn, для perl, к примеру starman или twiggy, для php это php-fpm. можно использовать пакет uwsgi, который через плагины поддерживает несколько языков, чтобы один раз разобраться с настройками и потом просто пользоваться.
- менеджер пакетов. это, если и не общее для всех языков, достаточно типичное решение. npm для ноды, cpan для perl, composer для php, например.
- установка песочницы. для питона это virtualenv. этот инструмент позволяет дать запускаемым приложениям необходимые пакеты, не выполняя их установку в системный каталог. каждому приложению нужные именно ему версии пакетов! питон здесь тоже не уникален. для php или ruby, например, есть аналогичные инструменты. к стати, если на сервере будет жить единственное приложение, то этот шаг можно пропустить, и все зафигачить в системный каталог.
- и только теперь установка самого фреймворка: pip install django. дальше по инструкции развертывания из документации к фреймворку, указать базу, накатить миграции ...

Большая часть шагов по развертыванию вашего приложения является общей для многих языков и многих фреймворков. Может стоит поучить матчасть?

Что есть ORM? Отображение логических или физических сущностей БД на объекты программы.
Источник данных - это сервис. Драйвер соединения - ваш код, который отправляет запросы в чужой API и получает ответ, обрабатывая ошибки, когда они возникают. В чем собственно проблема?
Ну да, вам придется явно закодировать объекты, которые предоставят интерфейс для взаимодействия с данными API вместо магии метапрограммирования django orm. Или простота вас и смущает?
Оберните данные внешнего API в классы, разбив их согласно логике использования, и пользуйте любой привычный вам фреймворк. Можете даже привычные active record или repository реализовать, если в контексте задачи это оправдано.

Асинхрон на базе очередей редиски не вариант? Я про что - то подобное этому.

Чтобы видеть, что именно у вас не получается, нужно видеть код. Открываю документацию, и вижу: создаем инстанс документа, передав путь до файла, доступ к существующим элементам получаем через inline_shapes, paragraphs, sections или tables, новые создаем с помощью add_* методов. Каждый элемент страницы содержит, либо коллекции вложенных элементов, либо свойство text, которое, скорее всего вам и нужно.
В вашем случае порядок действий должен быть примерно такой:
- читаем документ
- перебираем таблицы (свойство tables документа), пока не найдем нужную Table (критерием соответствия может быть, например, наличие строки "№ ауд." в соответствующих ячейках первой строки, метод cell у таблицы вам в помощь)
- перебираем строки найденных таблиц, выбирая из ячеек соответствующие данные в случае заголовка таблицы или строки с предметом
- по мере нахождения, добавляем в результат новые данные
- закрываем документ и показываем все найденное

soket.setblocking(False)
не оно?

Смотрите в сторону использования API KEY. Каждому розданному API KEY позволяете создать/привязать одного пользователя. Программа у пользователя спрашивает имя и пароль, дергает сервер для регистрации/привязки, хоть простым post-ом, хоть специальный api запилите.
Дальнейшая судьба API KEY - на ваше усмотрение. Например, его можно использовать в процедуре восстановления пароля, как дополнительный токен авторизации.

Задача в общем случае не имеет решения, конечно, если договорится с владельцем сайта - не вариант.
Да, ты можешь на питоне научится подделывать заголовки запросов, распознавать капчу, можешь даже качественно строить в памяти dom и обрабатывать его js, загруженным со страниц целевого сайта, но это работает только в частных случаях. Как только появляется интерес не дать тебе утащить данные, сразу начинается гонка, один придумывает способы, как обламать халявщика, другой - как эти проверки обойти. Авита, как пример, много внимания уделила, а может и уделяет до сих пор, противостоянию с пауками, и, в моем случае, найденные решения жили от нескольких дней, до нескольких месяцев, а потом все равно отпадали.
Если, все таки, желание не отпало, можно попробовать перестать прикидываться браузером и стать им на самом деле. Речь про написание плагинов, которые будут приглядывать за страницей и искать на ней нужные данные, собирая их в памяти на отдельной вкладке, или отправляя на твое api для сохранения. Можно попробовать поиграться со встраиванием браузера в твою программу, но я игрался только со встраиванием ишака в прогу на дельфях, да и то, очень давно.

Обернуть отправку асинхронного запроса в функцию, если этого не сделано, и импортировать grequests локально, внутри функции.

Еще можно как - то так:

import signal, os

def handler(signum, frame):
    print 'Signal handler called with signal', signum
    exit()

signal.signal(signal.SIGALRM, handler)
signal.alarm(5)

for i in range(0, 1000000):
    print "i: %s\n" % (i)

Параллельность не есть асинхронность.
Паралельное исполнение заданий подразумевает, что они исполняются одновременно, ну, почти одновременно.
Асинхронное выполнение - это выполнение, при котором процессор может поработать над другой задачей, пока текущая ожидает завершения долгой операции, типа передачи по сети, ну или работы с диском, например.
aiohttp асинхронный фреймворк, или я что-то упустил?