#lasr server

One of the  most underestimated controls in Visual Analytics Report Designer is Stored Process Control. Probably, this is more of a psychological bias, some kind of deep fear in post-SAS-9.1.3 users souls: what is an STP for in a Visual Reporting Tool? Why should I run some kind of SAS code when the GUI is already doing everything I need? Should we really awake and unleash the ancient demons resting behind the execution of plain user written SAS code?

They say the Dark Side of the Force is evil, but they don’t tell you about freebies. Just think of your nastiest end user accessing a troublesome report. Wouldn’t Darth Vader use the Force to fill the user mailbox with porn spam right in that moment, misleading him and taking his attention away from the report? Just embed in your report an STP using proc http to call youPorn APIs and the job is done.

The light side of the Force benefits as well from STPs. Main uses comprehends tricky layouts, advanced functionalities, LASR server management, and filling browsers with furry chubby heart-shaped-eyed pets.

On one hand, by using STPs you can show in a frame any kind of output. It doesn’t just mean you can show a number you wouldn’t be able to show in a table. It means you can have the STP writing out your own HTML output, including images, advanced css, javascript interactions, you can even include external js libraries such as jquery. It means having a real web application inside your report, providing advanced functionalities, including external content, calling other STPs, handling advanced side effects.

On the other hand, you can have the STP managing the LASR sword. Err…  I was meaning LASR server, of course. An STP natively has the capability to present the user with prompts. By asking the user which kind of data he is going to use, you can have LASR specific procedures such as proc imstat to dynamically load in-memory just the tailored portion of data that is needed, maybe setting constraints on the number of rows you are going to load, resulting in dramatic performance boosts when you deal with huge amounts of data being held on unfit architectures. By the end of the story, you have the elephant getting into the matchbox. One bit at a time. Jabba the Hut would approve.

  “Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering. Suffering leads to STP.”

When I was I little child, I used to think a star schema is some kind of query, and when a star schema falls down from the sky, you have the right to make a wish. Actually, when a star schema falls down, the only wish you have to make is about not having too much data in it. Don't tell anyone, or your wish won't come true. In particular, don't tell your SAS Visual Analytics.

Sometimes reports and data explorations lay on very big datasources, and your machine is not sized the right way to handle that much effort. Just think about the number of times you got blown off by a girl. Every single facepalm is a fact. Around facts, you place dimensions: the girl anagraphical information, the place you got bounced, the brothel she works in, err...

On a two years window I'm talking about 400 millions refusal events (35GB table), 6.000 girls, 800 locations, 250 approaching tactics, 80 denial excuses. If  you are using Visual Analytics query builder to join these tables, it might mean you are loading on your LASR server a 270GB denormalized dataset as your analysis datamart. Multiply this by the number of your alcohol self-support group mates asking you to have their own analysis. I'm telling you: first thing you'll do is using the compress option. I mean you are using it on your data! The second one is changing your psychiatrist, because compress option might save you 10-15 times the RAM consumption, however when using the datamart, decompression translates to  "CPU time", which might become a major problem. What's the use of strategical analysis if the query ends up when I'm 80?

In this scenario, one good option might be avoiding building your datamart as a query and creating it as a star schema, having the "create as view" option turned on. Be warned: in star schemas it really does what it means, in queries it's just a sadistic joke. In this case you are not loading the full denormalized table on your LASR server, for you are just loading the very single tables, consuming just the arithmetic sum of the datasets size. The tables join is performed by blocks (that is: just a few girls at a time saying you are not tall enough to speak with them). On big volumes, the time it takes to join the blocks is much less than the time it would take to decompress the denormalized table.