АВ
Лучше пришлите приложение с тестовыми данными. Иначе очень сложно сказать что у вас там и как это сделать.
Пример данных
Size: a a a
2019 November 29
АВ
Вот пока не пойму с какой стороны подойти)
DS
Вот пока не пойму с какой стороны подойти)
Держите.
Основная идея:
Генерируете недостающие даты для каждого клиента.
Ставите флаг, если заявка есть, то 1, нет 0. И делаете RangeSum по 6 предыдущим месяцам
Основная идея:
Генерируете недостающие даты для каждого клиента.
Ставите флаг, если заявка есть, то 1, нет 0. И делаете RangeSum по 6 предыдущим месяцам
АВ
Спасибо! это тестовый пример, боевой содержит 2 таблицы фактов по 35 и 28 млн записей, это еще + 350 млн недостающих дат, чтобы каждый клиент получил свои наборы за 12 месяцев. Не подходит для действующей модели :(
DS
ну, можно сделать и на текущих данных.
Генерация пустых нужна, чтобы, допустим смотря на месяц в котором заявок не было, он бы увидел там 0 или количество за прошлые 6.
Генерация пустых нужна, чтобы, допустим смотря на месяц в котором заявок не было, он бы увидел там 0 или количество за прошлые 6.
GE
Спасибо! это тестовый пример, боевой содержит 2 таблицы фактов по 35 и 28 млн записей, это еще + 350 млн недостающих дат, чтобы каждый клиент получил свои наборы за 12 месяцев. Не подходит для действующей модели :(
У вас даты должны повторятся, а флаг много место не займёт, так что объем приложения не должен увеличится. А формула будет простая и считаться должна быстро.
АВ
У вас даты должны повторятся, а флаг много место не займёт, так что объем приложения не должен увеличится. А формула будет простая и считаться должна быстро.
Попробую
OT
Пробовал схему предложенную выше:
"Zayav:
NoConcatenate LOAD
USERID,
DATE,
IDZAYAV,
Autonumber(recno(), USERID) as ZayvNo
Resident Zayav_temp
WHERE Autonumber(recno(), USERID) <=1
Order by USERID,DATE desc;
drop table Zayav_temp;"
На поверку оказалось ещё медленнее чем group by.
"Zayav:
NoConcatenate LOAD
USERID,
DATE,
IDZAYAV,
Autonumber(recno(), USERID) as ZayvNo
Resident Zayav_temp
WHERE Autonumber(recno(), USERID) <=1
Order by USERID,DATE desc;
drop table Zayav_temp;"
На поверку оказалось ещё медленнее чем group by.
Да, не удивлюсь... Можно и ещё проще, без Autonumber, с помощью where not exists, это может быть немного быстрее, но сортировка большой таблицы сама по себе тоже медленная.
СК
Круто))
АВ
слушайте, а что будет быстрее? у меня есть большая таблица со столбцом, по которому я считаю уникальные значения, там всего 10% повторений на 100% записей. Высокая кардинальность в общем. и вот. быстрее посчитать Count(distinct Field) или создать связанную таблицу по этому полю, добавить туда флаг с 1 и потом брать по нему Sum(Field_ind). Как быстрее будет?
YL
У меня на 180 млн строк и 80 тыс уникальных distinct работает очень быстро
АВ
Держите.
Основная идея:
Генерируете недостающие даты для каждого клиента.
Ставите флаг, если заявка есть, то 1, нет 0. И делаете RangeSum по 6 предыдущим месяцам
Основная идея:
Генерируете недостающие даты для каждого клиента.
Ставите флаг, если заявка есть, то 1, нет 0. И делаете RangeSum по 6 предыдущим месяцам
Вот изучаю пример. в измерениях по столбцу вместо количества повторов вижу номер абонента. А надо сколько попыток было и посчитать количество абонентов, которые обращались повторно указанное количестов раз. +RangeSum с After работает только если в таблицу прогружены все месяцы, а если выберу три последних, то он вернет некорректные данные (относительно изначального запроса). Есть другие варианты?
АВ
+ задвоить все строки не получится, там есть праметры, которые я суммирую в других мерах, и это приведет к искажениям других метрик.
АВ
я вот думаю по другому сделать. Создать отдельную таблицу, в которой будет ID абонента и дата приземления (сделаю не по дням, а по месяцам, мне детальнее пока не надо) и там на каждого абонента будет 3 поля: ID абонента, Прошло месяцев с даты обращения, дата учета повторного обращения. в горзинте пол года, на каждую запись будет 6 записей:
для инцидента ID=1, [Дата обращения]=15.06.2019 получим 6 записей:
ID абонента|Сдвиг месяцев|Период учета
1|0|01.06.2019
1|1|01.07.2019
1|2|01.08.2019
1|3|01.09.2019
1|4|01.10.2019
1|5|01.11.2019
И потом по полю период учета я смогу считать сколько на каждого абонента приходится повторов через Value List
Это рабочая схема?
для инцидента ID=1, [Дата обращения]=15.06.2019 получим 6 записей:
ID абонента|Сдвиг месяцев|Период учета
1|0|01.06.2019
1|1|01.07.2019
1|2|01.08.2019
1|3|01.09.2019
1|4|01.10.2019
1|5|01.11.2019
И потом по полю период учета я смогу считать сколько на каждого абонента приходится повторов через Value List
Это рабочая схема?
2019 November 30
ЕС
Коллеги, подскажите. Будет ли мера sum({<Field1=a, Field2=b>} Field3) принципиально отличаться по производительности от sum({<Field1=a>}*{<Field2=b>} Field3)?
OT
Коллеги, подскажите. Будет ли мера sum({<Field1=a, Field2=b>} Field3) принципиально отличаться по производительности от sum({<Field1=a>}*{<Field2=b>} Field3)?
Принципиально разницы не должно быть, то есть ответ должен быть тот же. Но технически, первое условие затрагивает только 2 поля, по которым прописаны условия, а второе условие касается всех полей в базе данных. То есть, я не удивлюсь если на больших данных второе условие будет считаться несколько медленнее и потребует чуть больше памяти для хранения.
ZS
Oleg Troyansky
Принципиально разницы не должно быть, то есть ответ должен быть тот же. Но технически, первое условие затрагивает только 2 поля, по которым прописаны условия, а второе условие касается всех полей в базе данных. То есть, я не удивлюсь если на больших данных второе условие будет считаться несколько медленнее и потребует чуть больше памяти для хранения.
Вот этот пост Джона Визерспуна может немного добавить идей, о том, как оно считается, https://community.qlik.com/t5/QlikView-Creating-Analytics/Performance-Set-Analysis-vs-IF-vs-Multiplication/td-p/146655 а именно речь идёт о сравнении IF, умножения и сет анализа с точки зрения скорости расчёта на том же дата сете.