В результате роста расходов, вызванного инфляцией, предприятия активно ищут творческие подходы, такие как анализ гистограмм, чтобы справиться с последствиями для своих цепочек поставок и операций. Используя этот метод, компании могут получить представление о потенциальных последствиях различных событий, что позволит им адаптировать свои стратегии к экономическим колебаниям и непредвиденным сбоям. В этом блоге будет обсуждаться практическое применение анализа гистограмм для оптимизации бизнес-операций, включая реальный пример, когда мы помогли производителю полупроводников определить узкое место в его деятельности.
Обзор
Аналитика гистограмм — это методология, которая моделирует транзакционные данные обо всем, что проходит через несколько этапов обработки (последовательных/параллельных). Вы можете использовать его, создавая гистограммы для каждого шага в каждом времени цикла, а затем создавая таблицу путей, которая показывает переход каждого шага с определенной вероятностью. Затем эти вероятности перехода можно агрегировать, используя определенный набор правил, чтобы выполнить следующее:
- Местоположение элементов: текущее или последнее известное местоположение всех интересующих элементов, эффективное определение шага или очереди в пути/канале. Эта метрика используется с моделями времени цикла, доходности и выбора пути для установления границ прогнозирования.
- Количество элементов, отслеживаемых на текущем этапе (используется с моделью доходности для прогнозирования выходного количества).
- Время последнего события (используется с моделью времени цикла для прогнозирования времени завершения).
Некоторые варианты использования, в которых можно использовать гистограммную аналитику, включают:
- Цепочки поставок, включающие товары, которые должны пройти ряд этапов, прежде чем они достигнут места назначения. (т.е. производство, упаковка, транспортировка, склад, полка)
- Производственные отрасли, требующие ряда шагов для преобразования сырья в готовую продукцию.
- Допуск службы безопасности аэропорта, когда человек должен пройти несколько этапов, прежде чем он сядет в самолет.
Подход
Подход к внедрению гистограммной аналитики включает следующие шаги:
- Организуйте цепочку поставок/производственную последовательность в виде последовательных событий.
- Определите (ожидаемые) пути через последовательность с вероятностями,
- Определить межсобытийные модели (подробный уровень) для базового времени цикла и/или доходности
- Агрегируйте модели по нескольким событиям и последовательностям в соответствии с ожидаемыми путями, чтобы оценить производительность и сделать прогнозы.
Теперь давайте подробнее рассмотрим каждый шаг.
События, сегменты и очереди
События
По мере сбора транзакционных данных транзакции можно использовать для разграничения начала и конца процессов. Это предполагает определение сегмента как интервала процесса между соответствующими событиями сбора данных.
В этом контексте событие сбора данных должно содержать следующее:
- Отметка времени события
- Наблюдаемые предметы (например, отгрузки, продукты)
- Место в цепочке поставок (например, физическое, логическое, оборудование)
Этот момент времени сбора информации называется событием. События могут быть определены из большинства используемых транзакционных систем, таких как системы цехов, складские системы, системы логистики и доставки.
Сегменты
Затем сегмент определяется как процесс между двумя значительными последовательными событиями. Обратите внимание, что было бы разумно игнорировать некоторые точки сбора данных (слишком много данных) и сосредоточиться на наиболее важных событиях для определения сегмента.
Сегментный процесс следует рассматривать в очень общем виде. Это может быть физическое преобразование (например, производство), перемещение (логистика), проверка (тестирование, проверка) или другие действия. Обратите внимание, что с этими определениями производственная деятельность и цепочки поставок фактически имеют одинаковую структуру.
Затем идентификация сегмента ассоциируется (как минимум) с начальным и конечным событиями. В некоторых случаях может оказаться выгодным включить атрибуты элементов в сегмент, хотя часто они могут быть включены в определения событий или обрабатываться независимо с помощью управления элементами.
Очереди
Конечное событие сегмента может соответствовать начальному событию следующего сегмента. Например, транзакция грузовика во дворе начнет следующий процесс, процесс стыковки. В этих случаях между сегментами нет очередей или других мест хранения запасов.
Однако часто конец одного сегмента не соответствует началу следующего. В этом случае будет существовать очередь, в которой продукты временно удерживаются в ожидании начала следующего сегмента. Фактически очередь имеет свои собственные начальные и конечные события, соответствующие конечному событию последнего сегмента и начальному событию следующего, соответственно. Очередь моделируется иначе, чем сегмент, однако время цикла очереди обычно зависит от количества элементов в очереди и скорости обработки следующего процесса.
Мы рассмотрим реальный сценарий, когда производитель полупроводников столкнулся с узкими местами в процессе цепочки поставок. Используя методологию анализа гистограмм, обсуждаемую в этом блоге, мы смогли выявить и решить эти конкретные проблемы.
Модели гистограмм
В быстро меняющемся мире производства полупроводников оптимизация процесса цепочки поставок имеет жизненно важное значение для точного прогнозирования выхода пластин и общей эффективности. Однако возникают проблемы, поскольку изменчивость и узкие места влияют на бесперебойный ход операций. Вот где проявляется мощь гистограммной аналитики. Используя эту методологию, мы глубоко погружаемся в цепочку поставок, выявляем конкретные процессы, которые действуют как узкие места, и визуализируем их с помощью графических данных. Это позволяет нам не только выявлять проблемные области, но и прокладывать путь для точных исправлений и улучшений, обеспечивая бесперебойное производство и раскрывая истинный потенциал производства полупроводников.
Производитель полупроводников предоставил пошаговое определение для определения номера потока деталей на основе комбинации {сайт, технология, технический код, деталь, стадия, тип оборудования}. Затем мы создали таблицу для извлечения номеров потоков деталей и фильтрации только тех партий, которые находятся в производстве.
Затем таблица и лежащие в ее основе данные используются для построения моделей гистограмм.
Для каждого из шагов мы построили модели гистограмм для времени цикла шага, времени цикла очереди и времени цикла процесса:
- Время цикла шага (метрика=’sCT’) — время, затрачиваемое лотом на выполнение всего шага от поступления до окончания обработки
- Время цикла очереди (метрика=’qCT’) — время ожидания в очереди на обработку партии
- Время цикла обработки (метрика=’pCT’) — время, необходимое для обработки партии машиной.
Этот процесс использовался для построения гистограммных моделей времени цикла по времени машинного процесса (pCT), времени ожидания (qCT) и общему времени шага (sCT = pCT + qCT).
SQL для построения моделей включал следующее:
- Пределы данных вычисляются на основе пределов выбросов Тьюки — мы рассчитали верхний квартиль (Q3) и нижний квартиль (Q1), чтобы сгладить хвост гистограммы, сделав гистограммы близкими к нормальному распределению.
- Фактические модели хранятся в базе данных в виде двоичных объектов (BLOB).
Предел Тьюки — это предел для удаления выбросов на основе квантиля. Все, что ниже Q1–1,5 (Q3–Q1) или выше Q3+1,5 (Q3–Q1), считается выбросом, где Q1 — первый квартиль, а Q3 — третий квартиль распределения.
Мы можем получить различную информацию из разного времени цикла, например времени цикла очереди, которое может сказать нам, где на каждом этапе есть узкое место, влияющее на общее время или общую производительность.
Во-первых, для начала нам нужно построить модели гистограмм на базовых таблицах.
create table histogram_models as (
WITH tmp_data AS (
SELECT
a.model_id,
a.model_type,
a.segment_step -- keeping model_type for convenience
,
CASE WHEN a.model_type = 'sCT' THEN d.endinst_fday - d.startinst_fday WHEN a.model_type = 'pCT' THEN d.trackoutinst_fday - d.trackininst_fday WHEN a.model_type = 'qCT' THEN d.endinst_fday - d.startinst_fday -(
d.trackoutinst_fday - d.trackininst_fday
) ELSE NULL END AS CT_fday,
Count(*) Over (
PARTITION BY a.model_id, a.model_type
) AS data_cnt -- how many data points
FROM
Your_database.client_base_table1
JOIN (
-- get segment information from SME table
-- model ID for all possible technologies, parts, etc. built here for example
SELECT
Row_Number() Over (
ORDER BY
1
) AS model_id,
s.partflow AS segment_step,
s.site,
s.technology,
s.techcode,
s.part,
s.stage,
s.eqpType,
CASE c.day_of_calendar WHEN 1 THEN 'sCT' WHEN 2 THEN 'pCT' WHEN 3 THEN 'qCT' END AS model_type
FROM
database_name.client_base_table s,
sys_calendar.CALENDAR c
WHERE
c.day_of_calendar < 4
GROUP BY
2,
3,
4,
5,
6,
7,
8,
9
) a ON a.technology = d.technology
AND a.site = d.site
AND a.part = d.part
AND a.stage = d.stage
AND a.eqptype = d.eqptype
WHERE
d.technology = '******' -- most common technology
AND d.part = '*******'
AND d.lotType = 'P' -- production lot
AND d.prcdKind = 'N' -- normal processing
),
tmp_limits AS (
SELECT
t.model_id,
t.model_type,
t.segment_step,
Percentile_Cont(0.25) Within GROUP (
ORDER BY
ct_fday
) AS q25_ct,
Percentile_Cont(0.75) Within GROUP (
ORDER BY
ct_fday
) AS q75_ct,
CASE WHEN q25_ct < (
1.5 *(q75_ct - q25_ct)
) THEN 0 ELSE q25_ct - 1.5 *(q75_ct - q25_ct) END AS lcl_ct,
q75_ct + (
1.5 *(q75_ct - q25_ct)
) AS ucl_ct
FROM
tmp_data t
GROUP BY
1,
2,
3
)
SELECT
model_id,
segment_step AS xIn,
1 AS yIn,
model_type,
data_cnt,
avg_val,
stdev_val -- added some additional stats for info
,
Current_Timestamp(0) AS model_create_dttm,
-- if data points less than bins, use normal distribution.
CASE WHEN data_cnt < 50 THEN customfunctions.histgrgendistnorm(avg_val, stdev_val, 4, 1, 50) ELSE customfunctions.histgrgendataquant(
tb.lcl_ct, tb.ucl_ct, 50, 0, tb.ct_fday
) END AS histgrmdl
FROM
(
SELECT
d.model_id,
d.segment_step,
d.model_type,
d.ct_fday,
l.lcl_ct,
l.ucl_ct,
d.data_cnt,
Average(ct_fday) Over (
PARTITION BY d.model_id, d.segment_step,
d.model_type
) AS avg_val,
StdDev_Pop(d.ct_fday) Over (
PARTITION BY d.model_id, d.segment_step,
d.model_type
) AS stdev_val
FROM
tmp_limits l
JOIN tmp_data d ON d.model_id = l.model_id
AND d.segment_step = l.segment_step
AND d.model_type = l.model_type
WHERE
d.ct_fday BETWEEN l.lcl_ct
AND l.ucl_ct
AND l.ucl_ct > l.lcl_ct
) tb
GROUP BY
1,
2,
3,
4,
5,
6,
avg_val,
stdev_val
) with data;
Теперь мы должны создать представление поверх базовых таблиц, определяющее поток деталей для каждой партии, и применить фильтры к определенным столбцам (чтобы выбрать только те партии, которые находятся в производстве).
REPLACE VIEW v384_Some_view AS LOCKING ROW FOR ACCESS
SELECT
t1.partflow,
t2.*
FROM
Your_database.client_base_table1 t1
JOIN Your_database.client_base_table2 t2 ON t1.site = t2.site
AND t1.technology = t2.technology
AND t1.techcode = t2.techcode
AND t1.part = t2.part
AND t1.eqptype = t2.eqptype
AND t1.stage = t2.stage
WHERE
t2.part IN (
SELECT
part
FROM
Your_database.client_base_table1
WHERE
site = '***'
AND technology = '******'
AND techcode = '******'
HAVING
Max(partflow) = 384
GROUP BY
1
)
AND lottype = 'P';
Генерация потока процесса
Соединение сегментов с другими сегментами и очередями формирует пути, согласующиеся с последовательностью обработки. Пути можно рассматривать как дорожную карту, соединяющую сегмент с сегментом и позволяющую разделять и объединять этапы (например, параллельную обработку компонентов элемента). Важной концепцией, требуемой описанной здесь методологией, является требование взвешивания путей, чтобы можно было выполнить ожидаемую нагрузку на процесс или спрогнозированный путь. Это эквивалентно назначению вероятностей при разделении (вероятности не нужны при слиянии).
Переходят от события к событию по цепочке поставок наборы товаров. Это элементы, которые отслеживаются через события и сегменты. Некоторые ожидаемые характеристики набора товаров по мере его развития включают:
- Могут использоваться различные идентификаторы отслеживания — в зависимости от сегмента/процесса/канала.
- Могут произойти изменения единиц измерения (многие на несколько или несколько на многие или изменение имени)
- Объединение или «разделение» (например, несколько упаковок в ящик или грузовик на несколько поддонов).
- Виртуальные и реальные товары (отслеживание статуса заказа по сравнению с фактическими отгрузками).
Набор товаров может влиять на выбор пути. Например, в производстве полупроводников для партии (т. е. набора товаров), которая проходит тестирование с очень высокой скоростью, может потребоваться другая упаковка, чтобы выдерживать ожидаемое тепло и профили использования. Как только результат теста известен, можно выбрать конкретный путь для этой партии.
Сегменты (и очереди) могут быть получены из последовательностей наборов товаров от события к событию. Хотя и сегменты, и очереди определяются как интервал (процесс) между двумя последовательными событиями, аналитические модели для сегмента процесса отличаются от моделей для очереди. Поэтому необходимо явно идентифицировать очереди — исходя из вероятности того, что запасы хранятся в очереди до обработки.
Оценка данных от события к событию также предоставляет информацию о путях и взаимосвязях (соединениях между сегментами). Поскольку пути разделяются и сливаются, исторические данные обычно используются для оценки вероятности разделения. Обратите внимание, что существует два различных типа разделения:
- Разделение пути — в этом случае набор товаров сохраняется и производится выбор одного или нескольких путей. Это эквивалентно выбору конкретной дороги при наличии двух или более дорог на перекрестке.
- Разделение лота — в этом случае отдельные компоненты в наборе товаров физически разделяются и идут разными путями. Это аналогично разделению одного пассажира на несколько самолетов в хабе.
Поток процесса получается из отслеживания элемента в процессе. Это удобно сделать с помощью функции Teradata nPath® в последовательности событий. Поскольку некоторые шаги пропущены, необходимо внести дополнительные изменения для построения декартова пути. Затем n-path используется для отслеживания лотов по шагам.
nPath — это аналитическая функция Teradata Vantage™, которая ищет заданный шаблон путем сканирования набора строк в базе данных. Эта функция предоставляет пользователям гибкость для определения сложного шаблона во входных данных и определения значений, которые выводятся для каждого совпадающего входного набора.
nPath очень полезен, когда основной целью является определение определенного пути, ведущего к результату, и именно поэтому он широко используется в различных отраслях.
create table path_table as(
WITH path_tmp AS (
SELECT
path_from AS from_xVal,
1 AS from_yVal,
path_to AS to_xVal,
1 AS to_yVal,
path_to - path_from - 1 AS nmbr_skip -- compute if next step skipped
,
Count(
DISTINCT(lotid)
) AS no_of_lots
FROM
NPath (
ON (
SELECT
*
FROM
partflow_model_view
WHERE
lotType = 'P' -- production lots
AND prcdKind = 'N' -- normal lots
) PARTITION BY lotId -- traceable unit through process
ORDER BY
startinst -- step start time
USING MODE(OVERLAPPING) PATTERN ('A.B') Symbols(True AS A, True AS B) RESULT(
First(lotid OF A) AS lotid,
First(partflow OF A) AS path_from,
-- defines numeric sequence
First(partflow OF B) AS path_to
)
) AS dt
GROUP BY
1,
3
HAVING
no_of_lots > 15
)
SELECT
t2.*,
Sum(t2.step_move) Over (PARTITION BY t2.from_x, t2.from_y) AS ttl_move,
(
t2.step_move(FLOAT)
)/(
NullIfZero(ttl_move)
) AS fract_move -- split fraction
FROM
(
SELECT
new_from_xval AS from_x,
new_from_yval AS from_y,
new_to_xval AS to_x,
new_to_yval AS to_y,
Sum(no_of_lots) AS step_move -- compute lots that moved into 2 (or more) steps
FROM
(
SELECT
t1.*,
c.day_of_calendar AS adder -- handle skipped steps
,
from_xval + adder - 1 AS new_from_xval,
CASE WHEN adder > 1 THEN 2 ELSE from_yVal END AS new_from_yVal,
new_from_xval + 1 AS new_to_xval,
CASE WHEN new_to_xval = to_xVal THEN to_yval ELSE 2 END AS new_to_yval
FROM
path_tmp t1
LEFT JOIN sys_calendar.CALENDAR c ON nmbr_skip + 1 >= c.day_of_calendar
WHERE
nmbr_skip >= 0
) x
GROUP BY
1,
2,
3,
4
) t2
) with data;
Вывод приведенного выше SQL будет таким:
Теперь мы должны добавить конечные шаги в таблицу путей:
insert into path_table values (0,0,1,1,null,null,1.00); insert into path_table values (384,1,0,0,null,null,1.00);
Комбинации сегментов
Основная функциональность анализа гистограмм — это комбинация сегментов. Есть 2 возможности для этой комбинации:
- Последовательные комбинации: один сегмент сразу следует за другим, без разделения или слияния между ними.
- Параллельные комбинации: два сегмента перемещают предметы на одинаковые расстояния параллельно.
Эти простые комбинации подробно описаны в следующих разделах.
Теперь нам нужно добавить нулевые гистограммы, используя таблицу путей и моделей, где y=2 (это генерируется в таблице путей). Затем эту таблицу можно использовать для агрегирования гистограмм.
create table path_mdls_d as(
select
a.model_id,
a.xin,
case when b.from_y = 1 then 1 else 2 end as yin,
a.model_type as metric,
a.model_create_dttm,
case when b.from_y = 1 then a.histgrmdl else null end as histgrblob
from
histogram_models a
inner join (
select
distinct from_x,
from_y
from
path_table
) b on a.xin = b.from_x
) with data;
Прогнозы
Основываясь на текущих позициях, моделях отдельных сегментов и известных вероятностях пути, статистику можно применять к статистике времени выполнения проекта и доходности для будущих позиций. Это можно сделать из любого существующего местоположения в любое место, выполнив следующие действия:
- Определить все возможные пути между локациями
- Агрегируйте модели гистограмм для всех сегментов по возможным путям, чтобы построить единую агрегированную гистограмму.
- Вычислите вероятность обнаружения предмета в будущем местоположении (т. е. процент загрузки пути).
- Вычислить требуемую статистику из полученной гистограммы (обычно любое известное время или доходность в текущем сегменте смещается из этого расчета).
Эта возможность позволяет прогнозировать доходность, время выполнения заказов и наиболее вероятные пути на основе статистических моделей. Концептуально этот метод аналогичен запуску моделирования методом Монте-Карло и построению гистограммы для представления вероятных результатов.
Наиболее сложной частью прогнозов является построение единой агрегированной гистограммы для представления всех вероятных путей доставки груза или продукта. По мере перемещения товаров в цепочке поставок расчеты необходимо повторять для обновления агрегированной модели.
Для проекции была создана хранимая процедура, поскольку мы начинаем с последнего шага и объединяем все модели гистограмм и агрегируем их вероятности от начала до начала на основе определенных условий. Модели гистограмм постоянно добавляются последовательно в соответствии с таблицей путей, пока у нас не будет точки слияния и разделения, то есть когда мы объединяем пути разделения параллельно и умножаем их соответствующие вероятности. Шаги повторялись до тех пор, пока мы не получили окончательную агрегированную гистограмму — комбинацию всех шагов, которую затем можно использовать для дальнейших вычислений.
Процедура хранения SQL приведена ниже:
REPLACE PROCEDURE projection_procedure(
IN xstop INTEGER,
IN met varchar(5)
) SQL SECURITY INVOKER BEGIN DECLARE xstart INTEGER;
-- starting point at end of path
DECLARE cntr INTEGER;
-- general purpose counter
DECLARE vDummy CHAR(1);
-- create handler for nonexistent volatile tables
DECLARE CONTINUE HANDLER FOR SqlState '42000'
SET
vDummy = 'd';
/* output table. Assumes 1st model is always singular */
/* may need modification for more complex systems */
DROP
TABLE tmp_mdlAgg_out;
CREATE VOLATILE TABLE tmp_mdlAgg_out AS (
SELECT
from_x AS last_x,
from_y AS last_y,
fract_move AS path_fraction,
histgrblob AS curr_model
FROM
path_table p
JOIN tw_path_mdls_d m ON p.from_x = m.xin -- model always associated with from step
AND p.from_y = m.yin
WHERE
m.metric = met
AND p.to_x = 0
AND p.to_y = 0
) WITH DATA PRIMARY INDEX (last_x, last_y) ON COMMIT PRESERVE ROWS;
/* create work table for holding intermediate results */
DROP
TABLE tmp_mdlAgg;
CREATE VOLATILE TABLE tmp_mdlAgg (
last_x INTEGER,
last_y INTEGER,
path_fraction FLOAT,
curr_model VARBYTE(30000),
nmbr_rows SMALLINT,
row_ID SMALLINT
) PRIMARY INDEX(last_x, last_y) ON COMMIT PRESERVE ROWS;
SELECT
Max(last_x) INTO xstart
FROM
tmp_mdlAgg_out;
WHILE xstart > xstop DO
DELETE FROM
tmp_mdlagg;
INSERT INTO tmp_mdlagg
SELECT
p.from_x,
p.from_y,
p.fract_move * t.path_fraction AS path_fract,
CASE WHEN m.histgrblob IS NULL THEN t.curr_model ELSE customfunctions.histgrcombseradd(
t.curr_model, m.histgrblob, 50, 1E - 6
) END AS curr_model,
Count(*) Over (PARTITION BY p.from_x, p.from_y) AS nmbr_rows,
Row_Number() Over (
PARTITION BY p.from_x,
p.from_y
ORDER BY
path_fract
) AS row_id
FROM
tmp_mdlagg_Out t
JOIN path_table p ON p.to_x = t.last_x
AND p.to_y = t.last_y
JOIN path_mdls_d m ON m.xin = p.from_x
AND m.yin = p.from_y
AND t.last_x = (
SELECT
Min(last_x)
FROM
tmp_mdlagg_out
)
WHERE
m.metric = met;
INSERT INTO tmp_mdlAgg_out
SELECT
last_x,
last_y,
path_fraction,
curr_model
FROM
tmp_mdlagg
WHERE
nmbr_rows = 1;
DELETE FROM
tmp_mdlagg
WHERE
nmbr_rows = 1;
SELECT
Count(*) INTO cntr
FROM
tmp_mdlagg;
IF cntr > 1 THEN
/* only works for 2 paths currently */
INSERT INTO tmp_mdlagg_out
SELECT
t1.last_x,
t2.last_y,
1.0,
customfunctions.histgrcombpar(
t1.curr_model, t2.curr_model, t1.path_fraction,
t2.path_fraction, 50, 1.0E - 6
)
FROM
tmp_mdlagg t1
JOIN tmp_mdlagg t2 ON t1.last_x = t2.last_x
AND t1.last_y = t2.last_y
AND t1.nmbr_rows = 2
AND t2.nmbr_rows = t1.nmbr_rows
WHERE
t1.row_id = 1
AND t2.row_id = 2;
END IF;
SELECT
Min(last_x) INTO xstart
FROM
tmp_mdlagg_out;
END WHILE;
DROP
TABLE tmp_mdlagg;
END;
Вызов процедуры для времени цикла шага:
call projection_procedure(1,'sCT')
Результаты можно запросить с помощью простого запроса, например:
SELECT last_x , customfunctions.histgrcalcquant2val(curr_model, 0.05) AS q05 , customfunctions.histgrcalcmed(curr_model) AS median_val , customfunctions.histgrcalcquant2val(curr_model, 0.95) AS q95 , customfunctions.histgrplot(curr_model) AS histgrplot FROM tmp_mdlAgg_out WHERE last_x = 1
Материализовать изменчивую таблицу, созданную процедурой, в постоянную таблицу.
CREATE TABLE outproj_sct_days AS ( SELECT * FROM tmp_mdlAgg_out ) WITH DATA;
Описанную выше процедуру можно вызывать несколько раз для времени цикла обработки (pCT) или времени цикла очереди (qCT).
Вычисление статистики
После проекции окончательной гистограммы требуются определенные расчеты для изучения изменчивости и узких мест. Пользовательские функции SQL использовались для вычисления различных процентилей окончательной гистограммы, а результаты использовались для построения графика изменчивости.
Ниже приведен SQL для извлечения процентилей из гистограммы.
CREATE TABLE cumulative_distribution_sct_days AS( SELECT last_x , customfunctions.histgrcalcmin(curr_model) AS min_time , customfunctions.histgrcalcquant2val(curr_model, 0.01) AS q01_time , customfunctions.histgrcalcquant2val(curr_model, 0.02) AS q02_time , customfunctions.histgrcalcquant2val(curr_model, 0.05) AS q05_time , customfunctions.histgrcalcquant2val(curr_model, 0.1) AS q10_time , customfunctions.histgrcalcquant2val(curr_model, 0.20) AS q20_time , customfunctions.histgrcalcquant2val(curr_model, 0.25) AS q25_time , customfunctions.histgrcalcquant2val(curr_model, 0.5) AS q50_time , customfunctions.histgrcalcquant2val(curr_model, 0.75) AS q75_time , customfunctions.histgrcalcquant2val(curr_model, 0.8) AS q80_time , customfunctions.histgrcalcquant2val(curr_model, 0.9) AS q90_time , customfunctions.histgrcalcquant2val(curr_model, 0.95) AS q95_time , customfunctions.histgrcalcquant2val(curr_model, 0.98) AS q98_time , customfunctions.histgrcalcquant2val(curr_model, 0.99) AS q99_time , customfunctions.histgrcalcmax(curr_model) AS max_time FROM outproj_sct_days WHERE last_y = 1 ) with data;
Теперь мы можем использовать результаты в Python для построения графика изменчивости с помощью Matplotlib.
td_df = tdml.DataFrame(tdml.in_schema("YourDatabase","cumulative_distribution_sct_days"))
py_df=td_df.to_pandas()
py_df['projected_average'] = py_df.mean(axis=1)
fig,ax=plt.subplots(figsize=(12,5))
sns.lineplot(py_df.index,py_df["q01_time"],label="Projected 01st pctile")
sns.lineplot(py_df.index,py_df["q05_time"],label="Projected 05th pctile")
sns.lineplot(py_df.index,py_df["q95_time"],label="Projected 95th pctile")
sns.lineplot(py_df.index,py_df["q99_time"],label="Projected 99th pctile")
sns.lineplot(py_df.index,py_df["q50_time"],label="Projected median")
ax.set_title('Projected Time to out (CHD)',fontsize=20,loc='center',fontdict=dict(weight='bold'))
ax.set_xlabel('Partflow',fontsize=16,fontdict=dict(weight='bold'))
ax.set_ylabel('Hours', fontsize=16,fontdict=dict(weight='bold'))
Выходной график, созданный из приведенного выше скрипта Python:
Пользователь может наблюдать на графике и исследовать, что этап 302 имеет некоторую неопределенность, которую можно дополнительно исследовать на уровне аппаратных средств (производственное оборудование и т. д.). То же самое можно подтвердить с помощью диаграммы, где мы видим, что шаг 302 занимает наибольшее время в очереди.
Вся статистика и расчеты выполняются в Teradata Vantage. Общее количество шагов в нашем случае равно 384, поэтому для визуализации данных было извлечено только 384 строки, но это можно масштабировать для больших наборов данных.
Ключевые выводы
Мы разработали проверенную и запатентованную методологию, которая значительно улучшит прогнозирование времени цикла в последовательных событиях.
Эта методология может полностью работать на Teradata. Нет необходимости перемещать ваши данные, и все остается в безопасности в экосистеме Teradata, что экономит ваше время, усилия и потенциальные проблемы.
Наше решение невероятно масштабируемо. Независимо от того, имеете ли вы дело с небольшим проектом или масштабной операцией, вы можете использовать это решение.
После того, как вы внедрите нашу методологию, вы получите ценную информацию о ваших последовательных событиях. Используя эти знания, вы сможете принимать решения на основе данных и точно оптимизировать свои процессы. Вы получите более четкое представление о продолжительности цикла, что позволит оптимизировать операции, выявить узкие места и эффективно распределять ресурсы.
Отзывы и вопросы
Мы ценим ваше мнение и точку зрения! Поделитесь своими мыслями, отзывами и идеями в комментариях ниже. Не стесняйтесь также исследовать множество ресурсов, доступных на Портале разработчиков Teradata и Сообществе разработчиков Teradata.
Об авторе
Таха более двух лет работает специалистом по данным в отделе Data Science в Teradata. Ему нравится использовать свой опыт в Python, SQL, SAS и машинном обучении для участия в проектах в области финансов, розничной торговли и цепочки поставок.
Таха имеет степень бакалавра компьютерных наук Национального университета компьютерных и новых наук — FAST.
