Что такое ad hoc запрос
Ad hoc
Ad hoc (лат. Ad hoc — «по месту») является латинской фразой, означающей «к этому, для данного случая, для этой цели». Как правило, используется для обозначения решения, предназначенного для конкретной проблемы или задачи и не предназначенного для какого-либо обобщения или адаптации для других целей. Сравните с Априори.
Типичными примерами являются организации, комитеты и комиссии, созданные на национальном или международном уровне для решения конкретной задачи. В других областях термин может относиться, например, к воинской части, созданной при особых обстоятельствах, к костюму, сшитому по специальному заказу, к разработанному вручную сетевому протоколу или к уравнению, разработанному для конкретной цели.
Выражение Ad hoc может иметь также негативный подтекст, предполагая временные решения, неадекватное планирование или импровизированные события.
Содержание
Комитеты, комиссии и организации Ad hoc
Ad hoc организации, включая комитеты и частные некоммерческие организации, создаются при возникновении объективной необходимости решения какой-либо важной проблемы, не попадающей в сферу компетенции ни одной из постоянных организаций или комитетов. Как правило, эти комитеты создаются на временной основе в рамках уставов и правил, регулирующих деятельность организации, на период времени, необходимый для полного решения поставленной проблемы.
Ad hoc организация может иногда иметь долгосрочный или неопределенный срок существования. В этих случаях первоначальная рабочая группа или форум может уступить место более постоянным формам организации. Типичным примером крупного масштаба такой организации является ОБСЕ.
Гипотезы Ad hoc
В науке и философии ad hoc означает добавление к теории чуждых ей (т.е. не вытекающих из неё гармонично, не являющихся её следствием) гипотез, чтобы «спасти» её от опровержения. Ad hoc гипотезы компенсируют аномалии, не предвидимые теорией в её исходной форме. Учёные часто скептически относятся к теориям, которые требуют для своего поддержания частых корректировок, поскольку при этом страдает её фальсифицируемость. Ad hoc гипотезы часто характеризуют псевдонаучность направления. [1] Многие научные понятия возникли на основании гипотез и модификаций существующих теорий, но эти модификации отличаются от ad hoc гипотез тем, что они дают объяснения возникшим аномалиям и предлагают новые способы развития теории.
Ad hoc гипотезы не обязательно являются некорректными. Интересным примером явной поддержки ad hoc гипотез было добавление Альбертом Эйнштейном космологической постоянной к общей теории относительности, чтобы разрешить проблему существования статической Вселенной. Хотя позднее он называл эту идею своей «величайшей ошибкой», было установлено, что она довольно точно соответствует теории тёмной энергии. [2]
Ad hoc в военном деле
В военном деле при непредсказуемом развитии ситуации могут создаваться специальные воинские формирования, когда для быстроты действий требуется оперативное взаимодействие между различными подразделениями. В качестве примера можно привести организацию военного прорыва.
Запросы Ad hoc
Ad hoc запросы — это термин из информатики.
Многие системы прикладного программного обеспечения имеют основную базу данных, которая доступна только через ограниченное число запросов и отчетов. Как правило, обращение к ним организовано через какое-то меню, и все они были тщательно спроектированы, запрограммированы и оптимизированы для исполнения квалифицированными программистами.
В противоположность этому, системы отчетности «ad hoc» позволяют пользователям самим создавать специфические, индивидуальные запросы. Как правило, это делается с помощью удобного графического интерфейса системы без необходимости в глубоком знании SQL или схемы базы данных. Потенциально такая возможность может серьёзно ухудшить работу живой системы, создавая шанс переполнения хранилища данных.
Запросы и отчёты Ad hoc относятся к подразделу бизнес-аналитики, наряду с OLAP, хранилищем данных, интеллектуальным анализом данных и другими средствами.
Сети компьютеров Ad hoc
Термин ad hoc по отношению к компьютерной сети обычно относится к системе сетевых элементов, которые в совокупности образуют сеть, требующую незначительного планирования, или не требующую никакого планирования вообще.
Как мы автоматизировали выгрузки и другие 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 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
Настройка Master-Slave репликации на MySQL за 6 простых шагов
Синтаксис и оптимизация Mysql LIMIT
Правильная настройка Mysql под нагрузки и не только. Обновлено.
И как правильно работать с длительными соединениями в MySQL
Запрос для определения версии Mysql: SELECT version()
Check-unused-keys для определения неиспользуемых индексов в базе данных
3 примера установки индексов в JOIN запросах
Анализ медленных запросов с помощью EXPLAIN
Что значит и как это починить
Описание, рекомендации и значение параметра query_cache_size
Быстрый подсчет уникальных значений за разные периоды времени
Использование партиций для ускорения сложных удалений
Правила выбора типов данных для максимальной производительности в Mysql
Включение и использование логов ошибок, запросов и медленных запросов, бинарного лога для проверки работы MySQL
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). На верхнем уровне описывается предметный процесс. Нижний уровень — технический, на нём описываются подпроцессы для верхнего уровня.
Золотое правило моделирования процессов: упрощайте предметный уровень и всё сложное переносите на технический.
Желаю всем простого, понятного и лёгкого моделирования!