50 Shades Of Fail Geneva

www.dimensionality.ch @Nephentur freenode | obihackers slide 1
50 Shades of #Fail
Analytics Worst Practices in Real Life

• Oracle ACE Director Business Analytics
• Hacking OBI since 2001 (nQuire + Peregrin aquisitions by Siebel)
• Speaker at OpenWorld, KScope, regional Oracle User Groups...
• Part-time blogger on Analytics, BI, DWH (http://dimensionality.ch)
• Full-time IRC (freenode | #obihackers) and OTN addict
• Oracle Analytics trainer for Oracle University since 2006
Who am I?

Why this presentation?
• BI / Analytics / Data Science has matured
• Considered as being a commodity know-how
• As a result it’s often done worse than ever…
• …especially compared to when it was a niche skill
• Hence: Back to basics presentation series
• And: Worst Practices means someone else ran into the wall!

Basics
No tool or technology can replace
comprehension and understanding.

Basics
Just because someone states a
“requirement” does not mean it is
correct or worth doing.

Basics
Being a professional means
understanding as well as questioning
helping companies fulfill their needs
– not wants.

Where things go wrong
• Data and logic
• Front-end
• System, lifecycle, admin etc.

Where things
• Data and logic
• Front-end

Data types
Incorrect handling of data types
Example? INT vs. DOUBLE
Why?
• “In our source we store it as an integer.”
• Proper data type handling underestimated or simply ignored

Data types
Result? • (−)2’147’483’647 or hard error

Data types

Hint
Never assume you know exactly how a data type
will behave.
A DOUBLE is not an INT just because it’s numeric.
Think of the lowest common denominator when
working with heterogeneous sources.

Database specificities
Randomly setting database features
Why?
• “Because you read it on a blog / forum“
Result?
• Generated SQL changes sometimes drastically
• Painful troubleshooting

Someone thought
hard about these!

Especially more specific
ones people like to pick out
of SRs / blog pposts and use
out of context!

Hint
Never just copy / paste things from a blog or white paper.
Especially not if the document is called “Best Practices” or
“Performance Tuning”!

Hint
Don’t fall into the trap of “I know this database so I will work
with others the same way”.
Again: source-agnostic tool means relational databases, XML,
multi-dimensional, Hadoop, etc.

Joins and mashups
Data type conversion on columns used for join specifications and
mashups
(or similar “workarounds”)

Joins and mashups

Joins and mashups
Why?
• Existing data models are either not properly built and clean or were
never meant to be used together for analytical purposes
• Database developers can’t be bothered to change their table creation
scripts
• “Best practices” of how to create tables are organizational rules
Result?
• Bye-bye data source optimization, hello full table scans

Joins and mashups

Hint
Push back on inadequate or inappropriate physical design.
“The tool should be able to do this” is not a justification.
Do it right once physically vs do it “ok” 50’000 times logically.

Aggregations
Unwittingly returning wrong calculation results due to ignorance
of the impact of pre-aggregation / post-aggregation
Background?
• Physical mapping calculations are executed pre-aggregation
• Row-by-row

Aggregations

Aggregations
Unwittingly returning wrong calculation results due to ignorance
of the impact of pre-aggregation / post-aggregation
Background?
• Derived logical columns are execute post-aggregation
• Data set

Aggregations

Aggregations
Why?
• Simply one of the most often misunderstood facts about aggregations
• “It’s the same formula so it will do the same thing!”
Result?
• “Wrong” results depending on interpretation and expectation

Hint
Question things when you are handed a formula.
In case of doubt just go the extra miles and prepare both.

Mixing models
• Not everything can be ETL’ed together
• Not all data matches on all attributes and dimensionalities
• Multi-fact models and non-conformed dimensionality are still crucial
Problems:
• Missing results from cross-star queries
• Analyses simply won’t run due to front-end post-calculations failing
• Wrong results when queries implicitly hit wrong facts

Missing models – e.g. OAC
Non-conformed dimensionality / LTS content levels

Hint
Try to be as precise as possible from the start. Going through a 5
fact, 30 dimension model post-construction is a recipe for
disaster.
A workaround is never a solution.
You will believe me once you have effectively your first
environment which combines detailed relational data with huge,
sparse cubes, XML files and a Hadoop cluster.

Dimensional hierarchies
• Don’t forget your business users and ease of use
• Some developers don’t see the point of content levels!
(Don’t believe me? Just do a search StackOverflow.)
• “We didn’t need that in OtherReportDrawingTool42.”

BMM #4

Hint
Work invested here will pay off a hundred-fold.
Be smart. Think LEGO! Think re-usable pieces.
Forget cell-oriented “reporting tool” … aka Excel!

BMM #4
Nay
Yay

Time dimensions
• Business should be able to use time in a consistent way
• Temporal calculations should be easy

Time dimensions
Again: someone
actually thought
about this

Time dimensions
So why should
one go and do
this 500 times?

Hint
Be smart and think analytical.
Blindly reproducing Excel formulas isn’t being productive.
The how you do something is at least as important as what it
achieves.

Hint
Your clients are actually paying you to do this.
Have the courtesy of delivering something of quality.
Guess what: repeat customers and follow-up work because they
liked things trump you coming back to fix rubbish.
Anybody doing it nice and usable from day 1 will win the
business’ heart and budgets.

• Data and logic
• Front-end

Wasteful construction

And here only 4
are excluded!

Analyses construction

Null values

Null values
Why?
• “We might miss something otherwise.”
• “Fix” data quality and modelling issues
Result?
As usual: performance.

Hint
An analytics solution is not the place to fix your messed up data!

Excel Excel everywhere
Using analytical platforms as an Excel exporting tool
Why?
• Everyone has Excel
• Data on their Excel sheets makes users feel secure
• “BI systems never give you enough.”
• “I must able to change the data.”

Excel Excel everywhere
Using OAC / OBI as an Excel exporting tool
Result?
• Data pushed DB -> OBIS -> OBIPS -> Browser -> Excel
• Even worse for cloud roundtrips
• Data multiplied in static form and open to change for everyone
Supreme surprise: Even Oracle says this is not a good idea!
https://support.oracle.com/epmos/faces/DocumentDisplay?id=1558070.1

Hint
Never be afraid to reject data dump “requirements”.
Focus on what are the actual needs.
Focus on what your users are trying to achieve.

Front-end usage
Using OBI as an Excel exporting tool
Why? • Everyone has Excel
• Data on their Excel sheets makes users feel secure
•“BI systems never give you enough.”
•“I must able to change the data.”
Result? • Data pushed DB -> OBIS -> OBIPS -> Browser -> Excel
• Data multiplied in static form and open to change for everyone
Multi-million row settings and hundreds of columns in instanceconfig.xml
Why? See above
Result? Taking down whole OBI farms when generating 5m row, 200 column PDFs
based on an analysis with alternating row highlighting and conditional icons.

Write-back
Using analytical tools as a data entry tool
Why?
• “It is a web application and must support this”.
• “We don’t want to buy or use another tool.”
Result?
• Have you ever heard of APEX?
• Analytical write-back or scenario updates does NOT mean arbitrary data entry!
•

• Data and logic
• Front-end

Cache
Turning on caching for performance
Why?
• It’s a quick fix and an easy smoke screen to hide actual issues in the DB.
Result?
• Without proper cache purging and seeding strategy stale data is assured.
• The ACTUAL problem for performance is never addressed and will persist!

Data Quality
Using your analytical tool to “solve” data quality issues
Example? CAST, CASE WHEN, FILTER as smoke
Why? As above plus: visible data quality issues = YOU are responsible
Result? • Performance degradation
• Data quality issues are hidden rather than solved
• Additional errors when source data changes
• Disappearing data when new source data outside the hardcoded cases
• ELSE statement becomes the only possible savior (“Invalid conversion”)

Source Control and Versioning
Not using source control for all your artifact
Why? Admin effort perceived as waste of time / non-productive
Result?
• Deployment pains when chasing files and configurations
• Ever tried to go back to a certain state of an environment?
• Source Control and Concurrent Development for OBIEE
• Several tools exist
- http://redpillanalytics.com/checkmate/
- https://github.com/RittmanMead/obi-concurrent-develop

Source Control and Versioning

Usage Tracking
• Trace and monitor usage
• Who does what, when and how
• Who accesses what, when and how

Usage Tracking

GDPR
• Dangerously misunderstood / underestimated
• Will become law 25th May 2018
• “Who can access which data why?”
• “Which data gets transformed how?”
– Think “data lineage on steroids”…

GDPR for OAC and OBIEE
Full SampleApp
completely
graphed out

Full relationships
for DB column
“Name”

Start from one
user and find all
security
relationships

Map out all
pertinent security
relationships for
the given user

Hint
Graphing out your environment helps you for more than just EU
law
Security assessments and reviews become child’s play
Impact analysis is instantaneous
Just ask and we’ll follow up

50 Shades Of Fail Geneva

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 50 Shades Of Fail Geneva

Semelhante a 50 Shades Of Fail Geneva (20)

Último

Último (20)

50 Shades Of Fail Geneva