ad hoc задачи что это
SQL-Ex blog
Новости сайта «Упражнения SQL», статьи и переводы
Что такое ad hoc запрос?
Вот простой пример ad hoc запроса в SQL Server:
SQL Server параметризует этот простой запрос:
Вот пример динамического запроса, который параметризован (подготовлен), поэтому он не является ad hoc:
Однако если параметров нет, запрос останется ad hoc. Вот пример ad hoc запроса, который так же является динамическим:
Чем полезны ad hoc запросы?
Во многих случаях разработчик или DBA может один раз выполнить ad hoc запрос, и больше никогда не использовать его. С другой стороны, один и тот же запрос может выполняться тысячи раз за день из приложения, и при этом, возможно, оставаться ad hoc запросом. В зависимости от запроса может не иметь смысла включать его в хранимую процедуру или параметризовать его.
Ad hoc запросы не являются ни плохими, ни хорошими; как и все остальное, это зависит от того, как они используются. Сошлюсь на интересную статью от Phil Factor, посвященную устранению проблем с некоторыми неэффективными ad hoc операторами.
Что такое ad hoc запрос в базе данных?
Чтобы выяснить, рассматривает ли SQL Server запрос как ad hoc, вы можете проверить тип объекта в кэше плана. Вот запрос из книги «Внутри Microsoft SQL Server 2012» Kalen Delaney и др. Замечу, что вам может потребоваться добавить больше фильтров на [text], если он вернет слишком много строк, чтобы отыскать ваш запрос.
Вы увидите тип объекта Adhoc для ad hoc запроса. Для параметризованных запросов вы также увидите строку с типом объекта Prepared. Вызовы хранимых процедур будут возвращать Proc, и имеется несколько других.
Что такое параметр Optimize for Ad Hoc Workload?
Представим себе систему, на которой каждый из большого числа запросов может выполняться только раз. Чтобы избежать ситуации, когда они занимают место в кэше планов, включите параметр Optimize for Ad Hoc Workload. Тогда при первом выполнении запроса в кэше сохраняется только заглушка плана. Если запрос выполняется снова, SQL Server сохранит весь план.
Заключение
Обратные ссылки
Нет обратных ссылок
Комментарии
Показывать комментарии Как список | Древовидной структурой
Автор не разрешил комментировать эту запись
Автоматизация бизнес-процессов. Ad-hoc изменения на примере из жизни. Часть 3
Тема внедрения изменений в бизнес-процессы дошла и до Российского отделения международной Ассоциации BPM-профессионалов (ABPMP Russian Chapter) в виде статьи президента этой ассоциации г-на Белайчука под названием «С чего начинается управление изменениями». Точнее г-н Белайчук поделился с читателями своего блога переводом статьи с англоязычного ресурса.
В статье речь идёт об управлении изменениями в бизнес-процессах. Основная мысль заключается в том, что «начинать управлять изменениями надо намного раньше — уже на первом этапе проекта BPI, когда разрабатывается устав, проводится выявление процесса и его моделирование». Автор статьи даёт понять, что управление изменениями должно носить систематический характер, и необходимо принимать во внимание, что в работе любой организации постоянными могут быть только изменения.
Далее в статье описываются трудности, которые непременно возникнут в организации при каждом витке итерации вносимых изменений в «устоявшуюся» работу процессов организации, и как с ними бороться на уровне психики?! «людей, сталкивающихся с изменениями».
Поэтому предлагаю вместо утешения сотрудников организаций, которым волей или неволей приходится сталкиваться с изменениями в структуре бизнес-процессов, дабы не расстраивать их понапрасну, рассмотреть более технический подход к этой ситуации.
Суть подхода заключается в следующем:
Запущенные экземпляры подстраиваются под изменения модели процесса автоматически.
То есть достаточно внести изменение в модель бизнес-процесса, а далее можно расслабиться и не думать, как встроить новые изменения в уже запущенные экземпляры, которые, к примеру, будут активны ещё несколько лет. Ведь ждать окончания их жизненного цикла, чтобы полностью забыть о них, нет ни желания, ни возможности.
Просьба не путать этот подход с adaptive case management (ACM).
ACM — это самый гибкий подход на сегодняшний день, который даёт возможность настраивать каждый запускаемый экземпляр индивидуально.
Рассматриваемый подход, в данной статье, описывает полу-структурированные процессы (semi-structured), которые обладают заранее определённым набором правил, но могут изменяться в ходе выполнения процесса.
Эти изменения автоматически применяются также к запущенным экземплярам до момента внесения изменений, тем самым обеспечивая наличие глобальной модели бизнес-процесса в данный момент времени.
Другими словами, изменения применимы не только к новым экземплярам (т.е. отсроченные изменения), а также ко всем запущенным экземплярам данной модели бизнес-процесса, используя метод миграции (т.е. экстренные изменения).
Рассмотрим пример из жизни, взяв процесс возврата командировочных, и примем допущение, что жизненный цикл этого процесса равен 10 годам (чтобы наглядней понимать преимущество экстренных изменений в запущенных экземплярах).
Модель процесса «Возврат командировочных» в версии 1.0:
Заполняется заявка на возврат командировочных, далее заявка обрабатывается менеджером, который может немедленно её одобрить, отклонить или запросить дополнительную информацию.
Согласно принятому решению происходит оповещение инициатора процесса. И после возврата командировочных или отказа возврата процесс завершается.
Процесс был запущен и спокойно себе отрабатывает заявки, пока в определённый момент времени не приходит уведомление от руководства, что заявки свыше €200 должны задним числом утверждаться ещё и начальником отдела. То есть это изменение также применимо к ранее запущенным заявкам, которые были проапрувлены менеджером, но у бухгалтерии, как обычно, не дошли до этого руки и командировочные ещё не были возвращены.
Для этого создаётся новая версия процесса с учётом необходимых изменений, в данном случае можно добавить ещё один UserTask и один ExclusiveGateway.
И следующая версия процесса будет выглядеть подобным образом:
Появилось новое разветвление после утверждения заявки менеджером; и если сумма превышает €200, то требуется утверждение ещё от одного лица с другим уровнем доступа.
Всё вроде хорошо, новые заявки будут запускаться по новой модели процесса, но остаётся вопрос, как быть с уже запущенными экземплярами, особенно с теми, где сумма возврата превышает €200? Здесь мы также вспоминаем о сделанном допущении, что окончание жизненного цикла запущенных экземпляров в ближайшие 10 лет не предвидится, а изменения нужно внести сейчас в не одну тысячу запущенных экземпляров, с разбросанными этапами выполнения по всей модели.
В этом случае, как было уже описано в первой части, последующая версия процесса соединяется с предыдущей посредством так называемой «Migration Map», в которой указываются «переходы» токенов между соседними версиями процесса.
Для данного примера «Migration Map» может выглядеть следующим образом, при котором заявки, которые были одобрены к выплате в версии процесса 1.0, но ещё не были обработаны бухгалтерией, будут перенаправлены к новому разветвлению «more than €200». В случае, если сумма превышает €200, то необходимо будет дополнительное одобрение начальством. Заявки с суммой до €200 будут, как и в первой версии, проходить к UserTask «Refund expenses» сразу без дополнительного одобрения.
Миграция активируется в момент перехода токена между тасками любого типа или в момент обращения пользователя к одному из UserTask.
В данном случае новые требования, которые необходимо применить к запущенным экземплярам, будут реализованы при попытке пользователя открыть UserTask «Refund expenses». Система управления процессами (СУП) определяет, что появилась новая версия процесса и заглядывает в «Migration Map». СУП по названию процесса, названию исходного UserTask, и зная в какой версии был запущен текущий экземпляр процесса, определяет версию процесса для миграции и название элемента в новой версии процесса.
По этим параметрам и проходит «скачок» между версиями. Для пользователя это происходит незаметно. Если после миграции в новой версии процесса у данного пользователя нет прав доступа к новому элементу, то появляется соответствующее сообщение о том, что версия процесса была изменена и запрашиваемый UserTask не доступен.
Миграция для остальных тасков происходит без структурных изменений, т.е. в тот же самый таск, но уже в обновлённой версии процесса.
Подводя итог, можно сказать, что с увеличением количества используемых BPNM элементов ухудшается гибкость самих процессов.
Для решения этой проблемы и обеспечения достаточной гибкости и адаптивности процесса моделирование происходит на двух абстрактных уровнях (Часть 2). На верхнем уровне описывается предметный процесс. Нижний уровень — технический, на нём описываются подпроцессы для верхнего уровня.
Золотое правило моделирования процессов: упрощайте предметный уровень и всё сложное переносите на технический.
Желаю всем простого, понятного и лёгкого моделирования!
Как мы автоматизировали выгрузки и другие Ad-hoc задачи аналитика с помощью Zeppelin
На момент написания этой статьи в компании Cardsmobile, которая разрабатывает мобильное приложение «Кошелёк», работает 195 человек: 8 аналитиков и 187 потенциальных заказчиков аналитиков. Мы делаем приложение для конечных пользователей, а также работаем с ритейлом, банками, брендами и другими партнерами. Долгое время работа аналитика в Кошельке состояла не только из исследований поведения пользователя, но и из различных выгрузок, типовых анализов для партнеров и прогнозов для потенциальных клиентов. Конечно, дашборды сильно спасали нам жизнь и позволяли всей компании следить за показателями продукта. Но мы всё ещё тратили время на остальную текучку, и с ростом команды (заказчиков) и бизнеса упёрлись: Ad-hoc задач стало слишком много, а исследования, желание развиваться и светлое будущее простаивали в отсутствие у нас времени.
Так много вокруг классных конференций, интересных статей про различные аналитические исследования, data-science, data-driven, data-счастье. А мы смотрели на всю эту красоту и не знали, где среди всего потока текучки найти время на эксперименты. Многие рассказывают, как сделать классно, но мало кто рассказывает, КАК преодолеть нарастающую текучку и освободить ресурсы для интересных и творческих задач. В этой статье я расскажу про наш опыт выхода в светлое будущее. Дальше будут примеры, как мы автоматизируем Ad-hoc задачи аналитиков в Zeppelin.
Что такое Zeppelin
Zeppelin – это OpenSource Notebook от Apache, который позволяет обращаться к различным БД на разных языках (Python, R, SQL, Spark). Но что делает его особенно кайфовым, так это набор визуальных элементов – dynamic forms.
В одном ноутбуке мы можем извлекать данные по api из Amplitude, быстро считать агрегаты из Clickhouse, дополнять результат данными из MSSQL и обрабатывать все это на Python. А готовые отчеты заворачивать в Excel в удобном заказчику формате и класть в html-ссылку, по которой их можно легко скачать.
Изначально мы начали использовать его просто как notebook, в котором было удобно писать на разных языках. Потом изучили возможности Zeppelin получше, нашли встроенные динамические формы: инбоксы, выпадающие списки и чеклиты – лампочка над головой загорелась! Сразу придумали, сколько всего мы можем автоматизировать. У нас было много типовых задач с готовым кодом, в котором надо было просто менять значения переменных. Мы перенесли весь наш код в Zeppelin, вынесли переменные в динамические формы и дали заказчикам возможность самостоятельно заполнять их и запускать скрипты. Идея понравилась и нам, и всей остальной команде!
Какие динамические формы есть
Input – текстовое поле. Мы используем его, для того чтобы задать временной диапазон для ввода идентификаторов. Другими словами, для всего, вариаций чего бывает много.
Select – выпадающий список. К каждому элементу списка можно прописать сразу готовый кусок кода. Мы предлагаем пользователю выбрать один из нескольких типовых вариантов. Например, одну из метрик для типового отчета.
Checkbox – форма для множественного выбора вариаций. Мы даем его пользователю, чтобы он, к примеру, сам мог выбрать список необходимых полей в выгрузке. Пожалуй, у нас это самый популярный кейс. Или когда мы даем возможность выбрать несколько метрик, сегментов пользователей.
Какие задачи мы автоматизируем в Zeppelin
Выгрузки простые и сложные, с использованием фильтров по дате, партнеру, задавая набор столбцов.
Чаще всего запросы на выгрузки приходят от аккаунт-менеджеров. А еще, с большой вероятностью, они поступают внезапно и срочно. Сами по себе задачи на выгрузку типовые и быстрые в выполнении. Но в действительности они отвлекают от тех самых интересных аналитических исследований, и их число растет по мере роста партнерской сети.
С какими задачами обычно приходят:
Мы создали отчеты для всех частых задач на выгрузки, с которыми к нам обращались. Ускорили процессы наших коллег и высвободили время и внимание для более интересных задач. Теперь только дорабатываем эти отчеты по мере необходимости.
Типовые задачи, в которых надо просто запустить готовый скрипт. Тут тоже применяем фильтры, даём задать значение переменных. Например, пересчет какой-то метрики или отчета, которые используются редко и не хочется ставить их на расписание.
Более изощренный кейс из жизни. Отдел маркетинга совместно с нашими стратегическими партнерами решили провести промо-акцию с определенной механикой. Пользователи нашего приложения должны были совершить цепочку действий, становясь участниками розыгрыша подарков. Раз в неделю мы хотели получать список участников недели, рандомно определять победителей, поздравлять их и отправлять подарки. Аналитик направления создал notebook в Zeppelin, который собирал пользователей, соответствующих условиям участия в розыгрыше за прошедшую календарную неделю. Маркетолог самостоятельно запускал notebook и забирал участников недели.
Подведение итогов А/B-тестов, измерение base-line метрик в тестовой и контрольной группах. Когда мы тестируем новый функционал или триггерную коммуникацию, мы смотрим не только на изменение целевой метрики, но и на то, как в целом меняется поведение пользователя. Мы выделили 4 base-line метрики пользовательского поведения:
Тут Zeppelin дает нам свободу в том, как мы хотим подводить итоги, какие метрики считать, как отрисовывать графики и как объяснять результат тем, кто будет пользоваться этим инструментом.
Собираем базы для коммуникаций и ретаргетинговых кампаний на основе выгружаемой из Amplitude когорты. Когда-то мы отказались от готовых коммуникационных платформ в пользу собственной разработки (возможно, это тема для отдельной статьи, а мы тут не об этом). Наше внутреннее решение было в первую очередь заточено под партнерские рассылки: выбери партнера и отправь сообщение на всю базу. А вот подготовка баз для продуктовых и маркетинговых коммуникаций — то есть собственных коммуникаций Кошелька — легла на плечи аналитиков. Типизировать все запросы от маркетинга и продактов казалось невозможным. Мы все стремились выделить наиболее релевантные сегменты, не ограничивая свои возможности. Например, вымышленный запрос, но запросы аналогичной сложности с нами случались:
Конечно, мы сохраняли код после каждой такой задачи и собирали его в некий монструозный конструктор. Но это все еще было время и внимание аналитика. А ошибка из-за невнимательности могла стоить нам волны негодующих пользователей, которые получили очевидно нерелевантную для них коммуникацию.
И все это так и было, пока один аналитик не обленился достаточно, чтобы не писать код для выборки пользователей в Clickhouse, а собрать когорту в Amplitude и выгрузить ее по api. Что, согласитесь, сильно проще и быстрее. Привычный и уже понятный интерфейс Amplitude, где любой менеджер может самостоятельно собрать когорту со всеми фильтрами из примера выше, проверить ее размер, дополнительно проконтролировать себя и проверить пользователей из когорты, что они попали в нее верно.
Как выглядит механика:
Что происходит в это время:
Я привела пример именно с пуш-рассылками, но у наших коллег быстро возникли идеи, где еще мы можем применять похожий инструмент: любые выгрузки списка пользователей с определенным пользовательским поведением. Сейчас мы используем когорты из Amplitude еще и для запуска ретаргетинговых кампаний. И, думаю, будем использовать и для многих других задач.
Системы мониторинга
Есть еще одна удобная фича, которая правда не относится к динамическим формам и, наверное, не совсем про автоматизацию – запуск по расписанию. Мы используем ее для пересчета дашбордов, запуска разных расчетов. Но самая полезная аналитическая задача, которую мы с ее помощью решаем, это мониторинг. Аномалии в событиях, в поведении метрик, что угодно, за чем должен регулярно следить аналитик, но что тоже хочется автоматизировать. Мы настроили систему алертов в slack и теперь можем вовремя реагировать на изменения, о которых хотим знать:
Success. Победили текучку, освободили время для развития аналитики в компании
Самый приятный абзац этой статьи – наступило светлое будущее! Мы уже автоматизировали большую часть наших Ad-hoc задач. Теперь в спринте их меньше 10%. В освободившееся время мы проводим исследования, выдвигаем и проверяем гипотезы, усложняем наши продукты аналитики и применяем подходы из тех самых статей и выступлений на конференциях. Другими словами, мы наконец занимаемся интересной аналитической работой. А главное, у нас появилось время принимать активное участие в развитии Кошелька.
Совет начинающим автоматизаторам: все частые и типовые куски кода выносите в библиотеки. Это позволит писать быстрее, улучшать качество написания кода всей команды аналитиков и править код в одном месте, а не во всех ноутбуках. И не забывайте, что вы делаете инструмент не для себя, а для своих коллег. А у них разный бэкграунд. Не пугайте их сложными интерфейсами и формулировками, делайте проще и понятнее.
Data-счастье еще впереди, но мы уже сильно воодушевились, ожили и бежим ему навстречу.
Ad hoc
Из Википедии — свободной энциклопедии
Ad hoc — латинская фраза, означающая «специально для этого», «по особому случаю». Как правило, фраза обозначает способ решения специфической проблемы или задачи, который невозможно приспособить для решения других задач и который не вписывается в общую стратегию решений, составляет некоторое исключение. Например, закон ad hoc — это закон, принятый в связи с каким-то конкретным инцидентом или для решения какой-то особой задачи, который не вписывается в законодательную практику и не решает других схожих проблем; отдел ad hoc — это подразделение в организации, созданное для решения какой-то узкой задачи, не попадающей в сферу компетенции ни одной из постоянных структур. В некоторых случаях выражение ad hoc может иметь негативный подтекст, предполагая отсутствие стратегического планирования и реакционные непродуманные действия.
В менеджменте управление ad hoc — это ситуационное управление (в противовес, или как дополнение к стратегическому управлению).
В международном праве термин ad hoc также используется для обозначения формы международно-правового признания при необходимости установления разовых контактов между сторонами, которые категорически не желают признавать друг друга.
В науке и философии имеется понятие гипотезы ad hoc — гипотезы, выдвинутой для объяснения какого-то особого явления или результатов конкретного эксперимента, не объясняющая при этом другие явления или результаты других экспериментов. При этом ученые зачастую скептически относятся к научным теориям, которые опираются на гипотезы ad hoc. Специальные гипотезы часто характерны для псевдонаучных предметов, таких как гомеопатия.
В армии специальные подразделения создаются в непредсказуемых ситуациях, когда сотрудничество между различными подразделениями внезапно необходимо для быстрых действий или из остатков предыдущих подразделений, которые были захвачены или иным образом сокращены.
В компьютерной технике имеется понятие беспроводные ad-hoc-сети — это сети, не имеющие постоянной структуры, в которых клиентские устройства соединяются «на лету», образуя собой сеть.
Что такое ad hoc запросы
Ad hoc queries — узкоспециализированные запросы, то есть запросы, созданные для решения единоразовой проблемы. В общем смысле термин ad hoc используется для обозначения решений под конкретные проблемы и задачи, без обобщенности.
К примеру выяснилось, что у какого-то пользователя в таблице users неточная информация о стране. Следующий код и будет ad hoc запросом:
Обновление информации о стране в БД
Ad-hoc запросы и отчеты часто применяются в системах бизнес-аналитики (BI) для ответа на специфические вопросы, которые отсутствуют в основном отчете.
Также может быть ad-hoc тестирование — полная импровизация для выявления ошибок без единого правила или схемы.
Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность.
Что такое индексы в Mysql и как их использовать для оптимизации запросов
Как исправить ошибку доступа к базе 1045 Access denied for user
Основные понятия о шардинге и репликации
Настройка Master-Master репликации на MySQL за 6 шагов
Как создать и использовать составной индекс в Mysql
Анализ медленных запросов (профилирование) в MySQL с помощью Percona Toolkit
Синтаксис и оптимизация Mysql LIMIT
Типы и способы применения репликации на примере MySQL
Настройка Master-Slave репликации на MySQL за 6 простых шагов
Check-unused-keys для определения неиспользуемых индексов в базе данных
Правильная настройка Mysql под нагрузки и не только. Обновлено.
Запрос для определения версии Mysql: SELECT version()
3 примера установки индексов в JOIN запросах
И как правильно работать с длительными соединениями в MySQL
Быстрый подсчет уникальных значений за разные периоды времени
Анализ медленных запросов с помощью EXPLAIN
Описание, рекомендации и значение параметра query_cache_size
Что значит и как это починить
Использование партиций для ускорения сложных удалений
Правила выбора типов данных для максимальной производительности в Mysql
Включение и использование логов ошибок, запросов и медленных запросов, бинарного лога для проверки работы MySQL