Overview of Qlikview by Quontra Solutions

Information about Overview of Qlikview by Quontra Solutions

Published on July 21, 2014

Author: quontra123

Source: authorstream.com

Content

OverView Of QlikView: OverView Of QlikView Presented By QuontraSolutions IT Online Training Visit: www.quontrasolutions.com Call Us: (404)-900-9988 [email protected] Presentation Roadmap: A brief history of QlikView How Traditional BI works How QlikView works How QlikView works internally? QlikView Competition What are the implications for OLAP and the data warehouse Presentation Roadmap [email protected] A Brief History of QlikView: Founded in Lund, Sweden in 1993 by Björn Berg and Staffan Gestrelius originally as a consultancy Originally called “ QuikView ” as in “Quality, Understanding, Interaction, Knowledge” Product was designed to mimic the way the brain works A key aspect was the colour -coding scheme whereby selected values are highlighted in green, linked values in white, and excluded values in highlighted grey First two versions were basically written in Excel using VLOOKUPs Håkan Wolgé was later hired as lead software engineer to re-architect/re-write QlikView from the ground up as an in-memory application Renamed as “ QlikView ” in 1996 IPOed on Nasdaq in 2010 under symbol “QLIK” and had 7 th best IPO of 2010 Now has over 24,000 customers in 100 countries and employs over 1,000 people worldwide Market cap: $2.5 billion A Brief History of QlikView How Traditional BI tools works: Traditional OLAP/cube technologies primarily provide the ability to drill up and down through “dimension” hierarchies, allowing the end-user to see pre-aggregated “measures” Dimensions and measures must be know a priori A small team is usually required to complete a BI project A data warehouse or data mart is usually required as a pre-requisite before OLAP cubes can be built This can often lie on the critical path of other data warehouse projects. Since data warehouse usage cannot be anticipated, a “single version of the truth” can often bog down development ETL is very slow to test, which in turn slows down development time If a detail drill down report (e.g. to see all point-of-sale records), a “drill through” query link is made to the operational data store to retrieve these data Introduces another point-of-failure Associations between dimensions are not computed – only resulting measures (e.g. counts) How Traditional BI tools works How QlikView works: The “secret sauce” is: An experienced QlikView can build and test a dashboard solution (including user acceptance testing) faster than any other BI tool I have evaluated This makes “Agile BI” possible Users and developers can remain focused on insights and outcomes The resulting dashboards are effectively by-products of the analysis process More flexible data model allows normalized data to be imported with fewer transformations ETL development is in-memory. ETL jobs can be tested orders of magnitude faster than traditional ETL tools All data is automatically profiled on import QlikView uses the word “associative” to distinguish itself from other BI vendors Associative is a tricky concept to explain, but most people will “get it” when they see it “Associative” puts emphasis on understanding how sets of data relate to one another All those tricky SQL queries involving “NOT EXISTS” or “LEFT/RIGHT OUTER JOIN” are but a mouse click away How QlikView works [email protected] How QlikView Works: How QlikView Works QlikView uses the word “associative” to distinguish itself from other BI vendors Associative is a tricky concept to explain, but most people will “get it” when they see it “Associative” puts emphasis on understanding how sets of data relate to one another All those tricky SQL queries involving “NOT EXISTS” or “LEFT/RIGHT OUTER JOIN” are but a mouse click away [email protected] Traditional BI workflow: Traditional BI workflow [email protected] QlikView workflow: QlikView workflow [email protected] How Does QlikView Work Internally? : How Does QlikView Work Internally? [email protected] How Does QlikView Work Internally?: At the centre of QlikView is a large “ Multi-Dimensional Cube Table ”, with one column for each table, and each row containing pointers back to the original table’s row index Also uses a: Global Symbol Table; Value Tables; and Data Tables The “machine code” most likely refers to bitmap indexes. QlikView heavily relies on bitmap indexes to perform its JOINs QlikView may have the best known solution to Kimball’s “Big JOIN” problem ( JOINing a billion dimensions with a trillion facts), since a single row is effectively being represented by a single bit Consider that a 64 rows can be JOINed in less than a clock cycle Intel and AMD now support “Active Vector Extensions” (AVX), which will allow 256 rows to be JOINed in less than a clock cycle Unclear if this architecture lends itself to map/reduce The embedded example shows in detail how the indexes work How Does QlikView Work Internally? [email protected] QlikView Competition: Only true competitor is Microsoft Power Pivot Available as free plug-in for Excel 2010 and can be deployed in SharePoint 2010 Started as Project Gemini, which was announced 21 months in advanced – the farthest out for any MS project MS has done their best to mimic QlikView’s associative experience Will now be rolling out “Power View” as part of SQLServer 2012 SSRS Other vendors have greatly simplified the cube/OLAP approach, and can be considered somewhat Agile, although they lack the “Associative” experience. Primarily: Tableau TIBCO SpotFire Many vendors have jumped on the “in memory” bandwagon, but ultimately have just moved their existing cubes “in memory” – effectively just speeding up user interaction, but offering nothing new in terms of user experience or development timelines Some “big data” analytical DB vendors (e.g. SAP HANA) are feigning competition with QlikView – but none of these get to the “last mile” of user experience QlikView Competition [email protected] What are the implications for OLAP and the data warehouse?: No longer need to maintain star schemas The data warehouse is going through a transition, and will likely be much simpler to maintain Bitemporal data types, which can already be found in TeraData and DB2, and have been ratified in ISO SQL:2011 will handle all issues related to Slowly Changing Dimensions, and other time related issues (e.g. when data was loaded vs. when original transaction occurred) Change Data Capture tables should be used to load data warehouse Data quality, de-duplication, and fuzzy matching should be treated as operational issues, e.g. fuzzy matching tables should be maintained operationally Dashboard schemas will be built in tools like QlikView , as needed. Star and snowflake schemas are still useful, but should be built as needed on-the-fly The data warehouse should more-or-less be a time invariant mirror of the ODS, and more-or-less maintain itself What are the implications for OLAP and the data warehouse ? [email protected] Thank You : Thank You

Related presentations


Other presentations created by quontra123