Использование в LOAD ... Resident нескольких таблиц (Qlikview & Qlik Sense)

Автор Иван, 04 сентября 2015, 12:06:22

« назад - далее »

Иван

Коллеги, привет!

Пытаюсь реализовать участок ETL-процесса с PL/SQL средствами QlikView. И что-то застрял вот на чем (привожу ограниченный абстрактный пример):

Tbl1:
LOAD * Inline[
field1, field2
Ivan, 29
Victor, 32
Marina, 23
Anna, 26
];

Tbl2:
LOAD * Inline[
field3, field4
Ivan, m
Marina, w
];

NoConcatenate
Tbl3:
LOAD Tbl1.field1, Tbl1.field2,
Tbl2.field3, Tbl2.field4
Resident Tbl1, Tbl2
Where Tbl1.field1=Tbl2.field3 AND Tbl2.field4='m';


Понятно, что можно организовать в текущем абстрактном примере действие с LEFT JOIN, но в случае, если условий WHERE много, переделать огромный код с PLSQL в QlikView не получится так просто (можно просидеть несколько часов или весь день только над одним запросом).

Подскажите, как организовывать такие запросы в QlikView. Не хочется трогать логику исходного ETL-процесса, т.к. трудозатраты по переносу кода возрастают в несколько раз.

С уважением,
Иван

kvv

#1
Привет.
Думаю, можно так:
Tbl1:
LOAD * Inline [
field1, field2
Ivan, 29
Victor, 32
Marina, 23
Anna, 26
];

left join (Tbl1)
//Tbl2:
LOAD * Inline [
[b]field1[/b], field4
Ivan, m
Marina, w
];



Логика QlikView такова, что поля с одинаковыми названиями соединяются.
Насчет PL/SQL - нужно писать такой SQL, чтобы "вытянутые" данные с БД удовлетворяли запросы разработчика.

Иван

#2
kvv,

к сожалению, такой вариант очень трудоемок при наличии более чем 4х условий внутри WHERE.
Есть еще варианты без LEFT JOIN?

Расковыривать каждый запрос нереально долго. Либо нужно обозначить данную задачу как "недостаток QlikView" при разработке.

Конечно же всегда можно оставить:

Table:
SQL
//нужный код, в котором используется WHERE


Но меня интересуют именно приемы выборки из нескольких полей + условие WHERE в QlikView.

С уважением,
Иван

kvv

#3
Прошлый пример, был с условием только в QlikView.

Попробуй вот это:
Tbl1:
LOAD * Inline [
field1, field2
Ivan, 29
Victor, 32
Marina, 23
Anna, 26
];
store Tbl1 into .\Tbl1.qvd (qvd);
DROP Table Tbl1;

Tbl2:
LOAD * Inline [
field3, field4
Ivan, m
Marina, w
];
store Tbl2 into .\Tbl2.qvd (qvd);
DROP Table Tbl2;

Tbl1:
LOAD field1,
     field2
FROM .\Tbl1.qvd (qvd);

left join(Tbl1)
LOAD field3 as field1,
     field4
FROM .\Tbl2.qvd (qvd);

Tbl3:
LOAD field1 as field1_01,
     field2 as field2_01,
     field4 as field4_01
Resident Tbl1
where field4 = 'm';

DROP Table Tbl1;


В любом случае, нужно потратить некоторое время, чтобы достичь результата.

bibis

#4
Добрый день. Вы пытаетесь натянуть на qv  несвойственную ему логику.
Таблицы объединяются по названиям полей (считайте, что там  natural join) и никак иначе.
Т.е. вам не нужно писать : tbl1.field.1=tbl2.field2 , это будет подразумеваться, если вы переименуете оба поля   в  какой-нибудь key1_2.
Я действительно не вижу никакой сложности, ваш вариант мне кажется более вымученным.

В принципе доступ к ячейкам другой таблицы есть см. функцию peek . Но тут оно не нужно вообще совсем

Иван

У меня есть очень медленный ETL процесс на PL/SQL. Написан он не мной. При этом он достаточно громоздкий. Документации никакой нет. Я решил поразмыслить, а можно ли перенести ETL-процесс из PL/SQL на ETL-процесс в QlikView. Пока что получается, что QlikView предназначен больше на работу с уже подготовленными данными, нежели для обработки данных из реляционных баз данных.

Специфика реляционных баз данных как раз и заключается в множестве различных WHERE, а использовать JOIN вместо WHERE не рационально как минимум.

Я прекрасно понимаю, что клик цепляет при join поля с одинаковыми названиями, прекрасно понимаю, как строить приложения. Но практическая задача по переносу ETL-процесса на QlikView получается крайне сложна для скрипта QlikView.

Можно сделать предварительный вывод: ETL-процесс на QlikView лучше не строить. Для QlikView лучше всего использовать готовые данные в виде отдельных интерфейсных таблиц.

Мой вывод корректен?  :)

Иван

Нашел на кликовском форуме следующий комментарий, с которым можно согласиться:
ЦитироватьI read this discussion with interest, but I have to mention that everybody here have their own idea what ETL tool is. I also started to learn QV some time ago, and from my previous experience with working with industrial ETL tools I can rank Qlikview by following domains:
1) Extraction - good
2) Transformation - poor
3) Loading - good

So why I think transformation is performing poor? First of all, ETL tool cannot do regular tasks much more better than SQL script or Excel, it allows to do such tasks that were almost impossible for others.

I don't know Qlikview very well, but features listed below must present in ETL tool:

1) Creating SCD type2 from regular table, which actually is a snapshot without any dates
2) Ability to write into several targets at one moment in parallel
3) visual interface for designing ETL proccesses (ability to view dataflows, not the plain script code)
So from my point today Qlikview cannot be named as ETL tool - it's just have some abilities for ETL.

Best regards, Andrei.
PS. I was impressioned by crosstable and hierarchy functionality in Qlikview, but this is not enough for ETL :)

Источник: https://community.qlik.com/thread/11850

Иван

Вообщем, поразмыслив, добавляю следующее замечание:
В QlikView можно сделать ETL-процесс, но основные преобразования данных должны быть реализованы посредством SQL-запроса, который отправляется на сервак и возвращает результат. Синтаксис такой:
TargetTable:
SQL
   SELECT <поля из разных таблиц>
   FROM <таблицы-источники, возможно даже подзапросы>
   WHERE <условия, необходимые для обращения к реляционным данным>;

STORE TargetTable INTO '$(PATH_QVD)TargetTable.qvd' (qvd);


В остальном, инструменты скрипта QlikView предназначены для добавления дополнительных полей (операции, наподобие расчета новых метрик).

ИТОГО: ETL-процесс на QlikView можно организовать только с применением SQL запросов.

Возможно у кого-то буду дополнения, буду рад услышать Вас. А пока что отказываюсь от переноса ETL-процесса с PL/SQL на QlikView.

Иван

Цитата: kvv от 04 сентября  2015, 12:40:57  
Насчет PL/SQL - нужно писать такой SQL, чтобы "вытянутые" данные с БД удовлетворяли запросы разработчика.

kvv, тут ты прав)

bibis

#9
Нет конечно.  QV  ничуть не хуже собирает данные
ваша проблема в том,что вы хотите сделать это так же,как в вашей СУБД.
Можно же построить etl  на QV, а потом сказать,что ваша система для etl не подходит, ибо скрипт qv нельзя на неё перенести без проблем ;D
Хотя каждому своё конечно и может я как-то не проникся вашими трудностями. С конкретикой было бы продуктивнее.

Иван

bibis, хорошо.
1) Приведите тогда пример для схемы, как можно организовать обработку данных в QlikView без использования JOIN. Схема:


2) Как можно распарсить переменную строчного вида с разделителем "," и загрузить распарсенные значения в отдельную таблицу?

3) Как в скрипте QlikView сделать вложенный подзапрос?

4) Как в скрипте QlikView сделать пользовательскую функцию для использования в скрипте загрузки данных?

Я работал с промышленными ETL-системами, у них возможности намного больше чем у QlikView. Объективно говоря, это инструмент для простого ETL-процесса (имею ввиду QlikView). Я не говорю, что QlikView - плохая система, наоборот - это отличный инструмент. Только нужно правильно его использовать. И одним из критериев правильного использования является предварительно подготовленные данные.

ЗЫ: "сбор данных" != "трансформация данных"

admin

#11
Любой отлаженный процесс из одной системы в другую перенести непросто, тем более когда речь идет о преобразовании данных.
С конкретикой конечно было бы интереснее обсудить.

P.S. Опа, вот и конкретика  :)

kvv

Иван.
Все 4 пункта так или иначе можно реализовать в QlikView.
1. Без join-ов нельзя работать и в SQL.
2. Ниже пример:
Data_101:
LOAD * Inline [
ID, NAME
01, Name_01
02, Name_02
03, Name_03
04, Name_04
05, Name_05
];

Cell:
LOAD Concat(ID, ', ') as ONE_CELL_01,
Concat(NAME, ', ') as ONE_CELL_02
Resident Data_101;

LET a1 = FieldValue('ONE_CELL_01', 1);
LET a2 = FieldValue('ONE_CELL_02', 1);

3. Можно "выкрутиться" через несколько таблиц или через циклы.
4. Скорее всего можно. Смотря что подразумевается под "Пользовательской функцией".


А, вообще, начали обсуждать разные вещи (крокодил зеленее или шире).
И SQL хорош и QlikView хорош. Просто в QlikView немного другая логика - ассоциативная.
Работаю в QlikView 6 месяцев и в целом он мне нравиться. Правда SQL есть SQL.
Некоторые вещи лучше реализовать через SQL, некоторые через QlikView.
Как-то так.

Иван

Ну ок, даю структуру запроса на PL/SQL, который сложно перебросить в QlikView (на мой взгляд):
  INSERT INTO TargetTable(
Field1, ..., FieldN
  )
  WITH
  A AS(
    <complex SQL>
  ),
  B AS(
    <complex SQL>
  ),
  C AS(
    <complex SQL>
  ),
  D as(
    <complex SQL>
  ),
  E AS(
    <complex SQL>
  )
 
  SELECT <many fields>
  FROM A, B, C, D, E
  WHERE 1=1
  AND A.FIELD(+)=D.FIELD
  AND B.FIELD=D.FIELD
  AND C.FIELD(+)=D.FIELD AND C.FIELD(+)=D.FIELD
  AND E.FIELD(+)=D.FIELD AND E.FIELD(+)=D.FIELD
  AND E.FIELD(+)=D.FIELD AND E.FIELD(+)=D.FIELD;


Совсем конкретный пример не могу приводить, т.к. все равно без источника данных ничего не понятно.

Предположим, что можно сначала в QlikView грузануть вспомогательные таблицы A, B, C, D, E. Тогда вопрос: что с ними дальше делать, чтобы получить TargetTable?

Иван

Цитата: kvv от 04 сентября  2015, 03:59:08  
Иван.
Все 4 пункта так или иначе можно реализовать в QlikView.
1. Без join-ов нельзя работать и в SQL.
2. Ниже пример:
Data_101:
LOAD * Inline [
ID, NAME
01, Name_01
02, Name_02
03, Name_03
04, Name_04
05, Name_05
];

Cell:
LOAD Concat(ID, ', ') as ONE_CELL_01,
Concat(NAME, ', ') as ONE_CELL_02
Resident Data_101;

LET a1 = FieldValue('ONE_CELL_01', 1);
LET a2 = FieldValue('ONE_CELL_02', 1);

3. Можно "выкрутиться" через несколько таблиц или через циклы.
4. Скорее всего можно. Смотря что подразумевается под "Пользовательской функцией".

А, вообще, начали обсуждать разные вещи (крокодил зеленее или шире).
И SQL хорош и QlikView хорош. Просто в QlikView немного другая логика - ассоциативная.
Работаю в QlikView 6 месяцев и в целом он мне нравиться. Правда SQL есть SQL.
Некоторые вещи лучше реализовать через SQL, некоторые через QlikView.
Как-то так.

Я про это и говорю, что QlikView - это "поглотитель" информации, но не "заготовитель". Я работал с SAS, там действительно очень охрененный инструментарий для ETL-разработчика. Но QlikView предназначен в первую очередь для визуализации информации, а не для обработки сырых данных.

Яндекс.Метрика