Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
By reading the Product Innovation blog, you will learn about what's new across all of the products in our growing Qlik product portfolio.
The Support Updates blog delivers important and useful Qlik Support information about end-of-product support, new service releases, and general support topics.
This blog was created for professors and students using Qlik within academia.
Hear it from your Community Managers! The Community News blog provides updates about the Qlik Community Platform and other news and important announcements.
The Qlik Digest is your essential monthly low-down of the need-to-know product updates, events, and resources from Qlik.
The Qlik Learning blog offers information about the latest updates to our courses and programs, as well as insights from the Qlik Learning team.

Inshights e visualizações incriveis.

Simulação do crescimento das vendas assim conseguimos estimar o crescimento da empresa no quesito volume de vendas.

Analista, Pricyng

Simulações e estudos de venda.

Absenteeism rate, Turnover rate, Anticipation of leaving employment, Industries with higher turnover rate

It is possible to predict the abandonment of staff employment, it is possible to predict the rate of staff absenteeism

The application can be used by HR departments (such as management control manager, finance manager, etc.) of companies to make informed decisions.

KPIs are used with statistical and predictive analysis. Time-based and behavior-based analysis.
本ブログは Launching Qlik Open Lakehouse の翻訳です。
著者:Vijay Raja
Apache Iceberg を搭載したオープンレイクハウスは、データ管理の風景を再定義します。レイクハウスは、データレイクのスケーラビリティとデータウェアハウスのパフォーマンスと信頼性を融合させることで、オープンスタンダードを受け入れながら、データに対するこれまでにない柔軟性と制御を提供します。
ますます多くの組織が、データサイロを打破し、相互運用性を高め、クラウドで大幅なコスト削減を達成するために、Apache Iceberg によるオープンレイクハウスに目を向けています。最近の業界調査によると、半数以上の大規模組織が、レイクハウスアーキテクチャを採用することで分析コストを50%以上削減できると予想しており、一部は最大75%の削減を予想しています。これらの劇的な削減は、データの重複を排除し、データ移動を合理化し、ストレージとコンピューティングを独立してスケーリングし、必要な分だけを支払うことを保証することによるものです。
しかし、これはまだ急速に進化している領域であり、組織はレイクハウスから最大の価値を得て、Apache Iceberg の真の約束を実現するために、いくつかの不透明な海域をナビゲートする必要があります。主な課題には以下が含まれます。
この度、Qlik Open Lakehouse を発表できることを嬉しく思います。Qlik Talend Cloud の新機能で、Apache Iceberg ベースのレイクハウスによりデータの取り込み、管理、最適化の方法を根本的に簡素化します。
ほんの数ヶ月前、私たちは Apache Iceberg への革新とコミットメントを加速するために Upsolverの買収を発表しました。そして今、Upsolver プラットフォームを Qlik Talend Cloud に統合し、Qlik Open Lakehouse を発表できることを嬉しく思います。この統合により、ユーザーは Amazon S3 環境にレイクハウスアーキテクチャを簡単に展開し、数回クリックするだけでバッチとリアルタイムの両方のデータを Iceberg テーブルに直接ロードできます。複雑で壊れやすいパイプライン、ボトルネック、手動設定はありません。
Iceberg の実装に通常伴う運用の複雑さにとらわれる必要はありません。Qlik Open Lakehouse は、すべての難しい部分を自動的に処理します。ソーススキーマをターゲット構造にマッピングします。データタイプの競合を解決し、インテリジェントなパーティションを適用し、自動ファイル圧縮を実行し、スキーマの進化を管理し、更新と削除を正確に処理します。手動による作業なしで継続的に実行します。舞台裏では、Qlikの Adaptive Iceberg Optimizer が Iceberg テーブルを継続的に監視およびリアルタイムで最適化し、パフォーマンスを向上させ、ストレージ使用量を最小限に抑えます。
そして、その結果をご紹介しましょう。
さらに、これらの機能はすべて、Qlik Talend Cloud のStandard Edition 以上に含まれ、Apache Icebergの採用と作業がさらに簡単で手頃な価格になります。バッチデータでもリアルタイムデータでも、Qlik Open Lakehouse を使用すると、運用上の負担なしに Apache Iceberg のパワーを最大限に活用できます。
Qlik Open Lakehouse はプライベートプレビューで利用可能になり、2025年 7月に一般公開されます。Qlik Open Lakehouse の早期アクセスプログラム(EAP)に参加することに興味がある場合は、こちらのリンクからサインアップしてください。
Apache Iceberg に大量のバッチとリアルタイムのデータを取り込むことは、かつてないほど簡単になりました。Qlik Open Lakehouse を使用すると、運用データベース、SaaS アプリ、SAP、メインフレーム、ファイルソース、CDC ストリームなど、数百のソースからデータを Iceberg テーブルに直接取得できます。お客様は既存の 200以上の Qlik Talend Cloud ソースから AWS S3 環境の Iceberg テーブルに直接低遅延のデータ取り込みを実行できるようになります。
運用システムからのリアルタイム更新であれ、履歴スナップショットであれ、Qlik はデータの書き込み、マージ、最適化を迅速に実行します。タイプ 1 とタイプ 2 両方の変更履歴をサポートし、最も厳しい SLA を満たします。
Qlikはお客様に代わり以下の複雑さを処理します。
✅自動スキーママッピング
✅ 競合解決のタイプ
✅インテリジェントなパーティション作成
✅スキーマの進化
✅ 処理の更新/削除
さらに重要なことは、お客様は AWS スポットインスタンスを使用して、費用対効果の高い Qlik コンピューティングを活用して、取り込みとブロンズレイヤーをサポートし、コンピューティングの節約と効率をさらに高めることができることです。
その結果は?高速、効率的、費用対効果の高いデータ取り込みをコードも手作業も不要で行えるのです。
業界をリードする Qlik のAdaptive Iceberg Optimizer テクノロジーは、テーブルを継続的に監視し、各テーブルの固有の特性に基づいて実行する理想的な最適化、圧縮、クリーンアップを決定し、比類のないパフォーマンス向上(最大2.5倍から5倍のパフォーマンス改善)と最大50%のコスト削減を実現します。
他の Iceberg 最適化サービスでは、ユーザーは各テーブルを手動で設定して最適化動作を調整および微調整する必要があります。このプロセスは退屈で複雑で、単にスケーラブルではありません。Qlik のAdaptive Iceberg Optimizer は、各テーブルを監視し、独自の特性に動的に適応し、手動で調整されたテーブルと比較して、クエリのパフォーマンスが向上し、コストを削減します。それはすべてのエンジニアリングのないパフォーマンスなのです。
Upsolver プラットフォームを使用して大幅なコスト削減とビジネスへの影響をどのように推進できたか、Iron Source や Cox Automotive などの大手組織の詳細をご覧ください。
データウェアハウスミラーリングにより、ユーザーは Qlik Open Lakehouse Iceberg テーブルからクラウドデータウェアハウス(Snowflake など)にデータを自動的に複製して、データの複製やコピーを作成することなく、クエリや追加のダウンストリーム変換を有効にすることができます。これにより、既存のシステムとの相互運用性が保証され、データの重複が最小限に抑えられ、さらにコスト削減が実現されます。ユーザーは、費用対効果の高い Qlik コンピューティングを利用してインジェストとブロンズレイヤーを実行するオプションもあり、データを Snowflake に簡単にミラーリングして、さらに下流の処理と変換を行い、両方の長所を提供します。
Qlik Open Lakehouse は、オープンでプラットフォームに依存しないように設計されています。それはベンダーロックインの回避を意味します。AWS Glue、Apache Polaris(incubating)、Snowflake Open Catalog などの業界をリードするカタログと統合されているため、ユーザーは主要な Iceberg 互換プラットフォームまたはクエリエンジンのいずれかを使用して、ペタバイトのデータに対して高性能クエリを達成できます。お好みのクエリエンジン、カタログ、または分析プラットフォームを使用してください。私たちはそれらをネイティブに統合します。
お客様は妥協することなく、自分に合ったアーキテクチャを自由に構築できます。
最終的に、Qlik Talend Cloud と Open Lakehouse を使用すると、お客様は単一のエンドツーエンドのソリューションを展開して、Iceberg ベースのレイクハウスのデータパイプラインを取り込み、変換、管理、最適化、管理することができます。同時に、包括的なデータ品質と信頼を確保します。他のマネージドのIceberg オプションは、通常、Icebergの取り込みまたは最適化のみを実行しますが、Qlik Talend Cloud は、データソースから分析や AI アプリケーションまで、Iceberg ベースのオープンレイクハウスのエンドツーエンドのパイプラインを管理するための統合ソリューションを提供します。
Qlik Talend Cloudの詳細はこちらをご覧ください。
Qlik Open Lakehouse を使用すると、データがプライベートクラウド環境を離れることはありません。データ取り込みと最適化は、AWS VPC 内の Amazon EC2 Spot インスタンスで実行されている Qlik 管理コンピューティングリソースを利用します。お好みのインスタンスタイプを設定できるため、Qlik は需要に合わせてリソースを自動的にスケールアップおよびスケールダウンし、自己管理のオープンソースツールまたはデータウェアハウスのコストのほんの一部で低遅延クエリを提供します。低コストから低レイテンシーまで構成可能なスケーリング戦略により、お客様は適切な組み合わせを選択して、適切なコスト構造で適切なレイテンシーで適切なデータを確実に配信できます。つまり、コンピューティング、独自のクラウド、ルールを選択でき、パフォーマンス、セキュリティ、コストを完全に制御できます。
|
Iceberg への高スループットな取込み データベース、SaaS ソース、SAPなどの数百のソースからリアルタイムでデータを Iceberg に直接取り込む |
Adaptive Iceberg Optimizer Adaptive Optimizer で Iceberg テーブルを最適化し、手作業で5倍のクエリパフォーマンスを実現 |
5倍高速なクエリで50%のコスト削減を実現 最適化とストレージコストの削減により、クエリを高速化し、50%を超えるコスト削減を実現 |
|
オープンで相互運用可能 主要な Iceberg カタログ、処理プラットフォーム、クエリエンジンで作業する |
データをデータウェアハウスにミラーリングする データをコピーすることなく、Snowflake ウェアハウスにシームレスにデータをミラーリングします |
ペタバイトスケールで実績のあるパフォーマンス PBスケールでデータを取り込み、管理するための、テスト済みで実績のあるソリューションです。 |
Qlik Talend Cloud は、Open Lakehouse とともに、Amazon S3 で Apache Iceberg テーブルを取り込み、最適化し、処理し、管理する独立したソリューションを提供し、比類のないクエリパフォーマンスとスケーラビリティを50%低コストで提供します。Qlik Talend Cloud の低遅延の取り込みと効率的なコンピューティングリソースを、Upsolver の Adaptive Iceberg Optimization 機能と組み合わせ、クエリパフォーマンスを5倍向上させ、50%のコスト削減を実現します。
すでに何千人ものお客様が、データウェアハウスとデータレイクを使用したデータ取り込み、統合、変換、データ品質、分析について Qlik を信頼しています。現在、同じ機能を拡張して、Iceberg をエンドポイントとしてサポートできるようになりました。Qlik Open Lakehouse は、AWS、Snowflake などの既存の投資と統合されているため、使用するクエリや処理エンジンに関係なく、手動の手間をかけずに、最高のパフォーマンスで Iceberg テーブルからデータを読み書きできます。
Qlik Talend Cloud 上で Open Lakehouse の構築を開始してください。Qlik Open Lakehouse の早期アクセスプログラムに参加するには、サインアップしてください。
もっと詳しく知る
Handling simple calendar dates in Qlik is "usually straightforward". Timestamps, on the other hand are a different story. Fractions of a day, time-zone offsets, and “why won’t this sort?” moments can slow you down when developing an app.
In this blog post, I compiled 7 tips that can help you when dealing with Timestamps in Qlik.
Every Qlik timestamp has two sides:
Num(MyTS) // 45435.6542 (barcode)
Text(MyTS) // 2024-05-22 15:42:05 (tag)
|
|
Purpose |
Example |
|
Formatters |
Change only the display text (tag) |
Date(MyTS, 'MMM-YYYY') |
|
Interpreters |
Take raw text, build a new dual value, i.e. create the barcode. |
Timestamp#('2024-05-22 15:42', 'YYYY-MM-DD hh:mm') |
Raw timestamps often land in your Qlik Sense App in different ways:
Instead of trying to print them in a pretty way everywhere, you can instead:
LOAD
RawTS, // original column
Timestamp#(RawTS,'YYYY-MM-DD hh:mm:ss') AS TS // dual value
...
You can use "TS" for date calculations, for instance:
- Floor(TS) AS OrderDate
- Frac(TS) AS TimeKey
and keep "RawTS" hidden for QA, or re-parsing later.
Timestamps captured to the second (or millisecond) contain far more detail than most analyses need.
Using that raw granularity in filter panes or chart axes can crowd the UI with millions of distinct values and add unnecessary processing overhead, so a better approach would be to split each timestamp into a date part and a time part so you can control it better
|
|
Function |
Example result |
Why? |
|
OrderDate |
Floor(TS) |
2024-05-22 |
Links neatly to your master calendar—great for YTD, MoM, etc... |
|
TimeKey |
Frac(TS) |
0.60486… (14:31) |
Lets you build a small “clock” dimension for charts |
LOAD
Floor(TS) AS OrderDate, // 2024-05-22
Round( Frac(TS), 1/1440 ) AS TimeKey_1min // 00:00 … 23:59
...
Why round?
For 15-min blocks, you'd do this:
Round( Frac(TS), 1/96 ) AS TimeKey_15min
After you’ve split the timestamp into Date and TimeKey, you still need a small lookup table so charts can show friendly labels like “14 : 30.” That’s where a Master Time table comes in. Below, we generate exactly one row per minute, no more no less, so that our app gets a clean predictable clock dimension.
|
|
Explanation |
|
IterNo() |
Produces 0 … 1439 during AUTOGENERATE. |
|
/ 1440 |
Turns each integer into the fraction of a day (1 = 24 h). |
|
Round(…, 1/1440) |
Rounds the fraction exactly on the minute boundary. |
|
Time(…, 'hh:mm') |
Formats the fraction as “00:00”, “00:01”, … “23:59”. |
Need 15-minute buckets? Change 1440 to 96 and 1/1440 to 1/96.
Check out Hic's blog post here for more in-depth information on this topic.
Not every data source delivers nice ISO date strings. Two formats you'll encounter most of the time:
|
|
What it means |
Typical sources |
|
Unix Epoch |
An integer that counts seconds since 1970-01-01 00:00 UTC. |
REST APIs, server logs, Kafka streams etc... |
|
Excel Serial |
A decimal that counts days since “1899-12-30 00:00” (Excel's day 0). |
CSVs saved from Excel etc... |
Load once, store as a proper dual, format later however you like.
// Unix Epoch (seconds) to Qlik timestamp
(Epoch / 86400) + 25569 AS TS_UTC // 86400 = sec per day
// Excel Serial to Qlik timestamp
ExcelSerial + Date#('1899-12-30') AS TS_Excel
Why 25569?
-> That's the number of days between Qlik (& Excel)'s day 0 (1899-12-30) and Unix's day 0 (1970-01-01).
If you need a static timezone conversion? Add or subtract the offset in days:
(Epoch/86400)+25569 + (-4/24) AS TS_Local // convert to UTC-4
When you subtract two timestamps Qlik gives you a fraction of a day and gives you something like: 0.0027. But this doesn't really tell you the actual duration. You probably would understand something like this instead: 00:03:55.
That’s what the Interval() function is for, to convert numeric time spans into clean, readable timestamps.
// Average call duration → 03:55
Interval( Avg(EndTS - StartTS) , 'hh:mm' )
If you need the raw number too, you can pair Interval() with Num():
// friendly + raw seconds
Interval(Avg(EndTS - StartTS),'hh:mm') AS AvgDuration,
Num( Avg(EndTS - StartTS) * 86400 ) AS SecDuration
The result: The dashboard objects show 03:55 while any export still carries the raw value 222 seconds for downstream math.
Interval() is the quickest way to turn fractions of a day into durations everyone understands.
Qlik stores every timestamp as a serial day-count with no built-in timezone. If your source data arrives in UTC but end users need to view time in Eastern Time, you can apply a static offset right in the load script:
// 1 hour = 1/24 of a day
LET vOffset = -4 / 24; // EST (UTC - 4 hours)
...
LOAD
UTC_TS,
UTC_TS + $(vOffset) AS LocalTS
...
Result:
LocalTS shows 08:00 when UTC_TS is 12:00.
When a static shift is enough
Handling daylight-saving shifts
If you need results for different regions that switch between standard and daylight time:
|
|
How |
|
|
ConvertToLocalTime() |
ConvertToLocalTime(UTC_TS, 'US/Eastern', 1) |
- Built-in Qlik function |
|
Handle at the source |
Do the conversion at the source DB, ETL tool, or API |
Keeps Qlik lean and avoids re-computing on every app reload. |
• For a fixed zone, add or subtract hours / 24.
• For regions with daylight changes, use ConvertToLocalTime() or adjust before the data hits Qlik.
That's all for this post. Time is certainly tricky, but once you understand Qlik’s dual-value modeland leverage the tips and tricks above, it becomes just another dimension in your analytics!
Thanks for reading!
In this episode of Do More with Qlik: Tips and Tricks Edition, I walk you through how to create dependent task chains in Qlik Cloud. Whether you're managing scripts, data flows, or apps, building a task chain ensures that each process runs in sequence—only when the previous one succeeds.
We’ll be working in a demo space called “Tasks Demo,” using three core objects:
A script that pulls pricing data and stores it in cloud storage.
A data flow that combines that data with inventory details to create a QVD.
An app that visualizes the results in a clear and simple dashboard.
In this video, you’ll learn how to:
Set up a scheduled time-based task.
Configure tasks to trigger only when a prior task succeeds.
Monitor task progress and view refresh statuses in real time.
This approach not only improves the reliability of your data updates but also helps you build a foundation for more complex automation across your Qlik environment.
👇 Watch the video below to see the full walkthrough and learn how to build your own dependent task chain in just a few clicks.
Have questions? Drop them in the comments where the video is posted—I'm here to help!
Resources:
The holiday season is upon us and it’s a time for giving thanks. As the end of year draws near, we reflect back on all of new capabilities released to Qlik Cloud. Today, we are thankful and excited to share that many of these capabilities are now available in our latest client-managed analytics offering, Qlik Sense November 2024. This version is packed full with so many visualization improvements that you must take a look below to view the full list. Users will also appreciate new data prep capabilities with script and editor improvements.
Hi everyone,
Want to stay a step ahead of important Qlik support issues? Then sign up for our monthly webinar series where you can get first-hand insights from Qlik experts.
The Techspert Talks session from May was Qlik Cloud Admin 101.
But wait, what is it exactly?
Techspert Talks is a free webinar held on a monthly basis, where you can hear directly from Qlik Techsperts on topics that are relevant to Customers and Partners today.
In this session we will cover:
The following public URLs will have their IP addresses changed on the 19th of May 2025:
This change is being done in a consolidation effort and will only affect your environment if you have previously created firewall exceptions for the old set of IP addresses. Note that Qlik does not recommend the use of IP addresses in exceptions. Add domain names to your allowlists wherever possible.
For a list of changes and to review what possible impact this may have, see Qlik Talend: Public IP address changes.
Thank you for choosing Qlik,
Qlik Support