Tag Archives: data

What to name your Tableau Server?

Posted on by
Reply

Hello all. Yes, contrary to popular belief, I did indeed survive Tableau Conference 2017. I’ll admit it was a close thing, but I got through it!

Now back to business..

This one all started with a tweet from my good pal, the Wizard of Excel (and Tableau genius) Mr Dan Harrison (@danosirra) who was wondering what to name his Tableau server host.

This awakened the server admin in me (not that it’s ever asleep).. It also made me question Dan’s taste in music.

An example being…

And this is the point. Server naming is critical in any organisation, large or small.

Picture the situation – you get woken up at 2am by an alert or a call from an operator – server “superman” is down. Fine if you’re experienced and know the environment inside out, but what if you’ve only just joined the company. You know the servers are named after superheroes, but that’s it. Was the production server superman or spiderman? Or was it WonderWoman? Do you need to take action? It’s not clear and you need to dig into a server inventory system to get more info, and that takes time. And you’re new, so you can’t remember the URL for the inventory system.

You assume superman is your production server. But it’s not reachable via console, and you need to call someone to get into the datacenter to fix it. So you call the hardware team – sure they’ll go in, but they need to know if the server is in the London or the Birmingham datacenter? Errrr…

So you dispatch Server 5’O to fix the box, and then the next day you find out it’s a development machine and could wait. What a waste of time.

So you get the problem here. It’s very tempting to name servers after Simpsons characters or animals (I’d choose sharks obviously), but those names convey no organisational information and as such, are useless.

So what should you do?

There are tons of different naming conventions you can use. Here’s one that I like

When I get that call in the middle of the night I (or the hardware technician) will want to know..

  • Where is the server?
  • Is it production, Disaster Recovery, UAT or development?
  • What application is it? Tableau, obviously.
  • Which worker of my Tableau cluster is it?
  • What operating system is it?

So I get called and am told server lnpwtsw3.company.com is down. Let me think..

  • ln – London
  • p – Production
  • w – Windows
  • ts – Tableau Server
  • w3 – Worker 3

And with that info, I know it needs acting on now, which platform admin to call if it’s an OS issue, and where to send the hardware technician if it needs physically addressing. I also know which worker it is so what the potential impact to my cluster is.

Yes the server name is a little harder to remember, but that soon comes and it is possible to create a DNS alias to reflect a friendlier name if needed. There’s also a balance to be had in terms of character count etc.

Another example – this time server name is lndwtsw1

  • ln – London
  • d – Development
  • w – Windows
  • ts – Tableau Server
  • w1 – Worker 1

Fine, that’s development. I’ll go back to sleep and deal with it in the morning.

So as you can see, it’s pretty important. Not just for me and my Tableau environment, what if you’re a server admin in charge of 5000 servers across the globe? This needs to be right!

Anyway, that’s it. Pretty simple. For the record, Dan made his choice…

See you next time, Paul

Advertisements

Data driven interviewing with Tableau

Posted on by
1

Hi

Continuing the series of posts where I explain how we are building an enterprise grade Tableau Centre of Excellence.

Here at Vizninja towers we pride ourselves on knowing Tableau & data. After all, we need to be able to add value and help users with their myriad queries.

So when we get the chance to hire, it is critical that we get the correct people. People with great skills in Tableau, data & visual analytics. People that can tell stories and make data come to life. People who want to help others see and understand their data. And being a data driven team we use data and visualisation to help us make the selection.

Our interview process goes like this.

  1. An initial screening call with the Agile BI service manager (that’s me!)
  2. A technical interview with the team
  3. An exercise involving Tableau Public
  4. A final chat with the big boss (that’ll be me one day)

Some more detail on a couple of these steps.

 

The Technical Interview

We have a series of technical questions that the team asks each candidate. The questions are split between Tableau Server and Tableau Desktop and also categorised in terms of complexity – e.g. Level 1, Level 2 & Level 3, (see here) with the more complex questions being at L3 level. So I wait until my team are in a bad mood and then I let them off their leash at the candidate….

Our interview viz. Created by @jakesviz

Click the image to get a better view of the tooltips. Apologies if they’re not so clear. Here’s what some of them look like. So we can see the exact question asked, points achieved and any comments.

On the dashboard, you can see the questions asked, the max points available per question and then the points attained per category and complexity. At the end we spit out a KPI that gives us some indication of a candidate’s capability. Note that a low score doesn’t necessarily indicate that a candidate is unsuitable. Often we see people who are super-skilled in Tableau Desktop but not experienced in Server (as in this case). A few weeks with the team will soon change that though. Our job is to create all-rounders in all aspects of Tableau.

So if the data checks out then the candidate moves on to the next stage.

 

The Tableau Public Exercise

For the next test we ask a candidate to choose a dataset from these public datasets and then create a viz on Tableau Public. The candidate then presents their viz to us and we look for the following

  • Good visual analytics best practice
  • Ability to create an engaging story and develop insight
  • Structured design process and ability to justify design choices

And if they’re really unlucky then @jakesviz will download the workbook and rip it to bits in front of them! Yes we are looking to see if you’ve commented your calculated fields!

Here’s what Jakub Jaros came up with..

https://public.tableau.com/profile/jakub.jaros#!/vizhome/SignigicantVolcanicEruptions/Main

Nice work huh? We thought so. So now you know where to go for your volcano information. This is a really important part of the interview process as the candidate presents their work to us and it can lead to discussion, debate and even argument. But it really gives a sense of whether someone loves dataviz and you sure need that if you want to work for me. We plan to add some data points to this stage so that we can come up with a final rating for each candidate.

After this, it’s a final chat with the big boss and hopefully a role with the team. And that’s when the fun really starts!

This approach has really resonated with senior management and as a result we are helping several other teams to adopt a similar process.

So there you are. That’s how we ensure we have the correct people to deliver a great service. Feedback appreciated in the comments.

Cheers, Paul

Meet the Penguins!

Posted on by
1

makingof

 

OK here we go. Iron Viz competition time. I don’t viz that much so pleased to dust off Tableau Desktop and have a go. This competition is all about the natural world. A very interesting theme for me being a massive nature fan.

1. The Idea

I love nature. Thinking of a theme I reached back into childhood memories and for some reason I thought of long afternoons with my family at the zoo. Aside from the usual animals we always used to make a beeline for the penguins, something that still happens when I take my own family to the zoo. Everyone loves penguins!

However, I don’t think that many people know just how many different flavours of penguin there are. They live in varied locations, come in a host of different sizes and looks and not all of them live in cold countries. They do all stink though.

So I thought I’d use Penguins of the World as my subject for this viz. And here it is.

Go take a look at the viz!

 

2. Data

I got the data from a single source- https://seaworld.org/en/animal-info/animal-infobooks/penguin/

References to sited data is always good to see

Although I didn’t conduct any lengthy data validation exercise I was given some degree of confidence that the website has a detailed references section, siting the data sources. That’s always good to see and something that is mandatory in scientific papers and such like.

Now there’s tons of penguin data available out there. But I really didn’t have the time to spend days looking for that perfect data source. I also didn’t want to spend days transforming the data before I started vizzing so I settled on this one pretty quickly.  Then it was a copy and paste into Excel and I was off.

Always be on the lookout for good images to incorporate into your viz

One thing I did like was the fact that this page had some cool drawings of each penguin species. That instantly got me thinking of using them as Tableau shapes. It’s always a good idea to be on the lookout for images and drawings that can you can incorporate into your visualisations.

 

3. Viz Design

Now I’m probably not the only person in this competition to be heavily influenced by the master of these kind of visualisations, Sir Jonni of Walker. (@jonni_walker). And with that I thought I’d steal like an artist and try to emulate him.

Key design choices were to use a black background, with plenty of large images and the use of BANs (Big Assed Numbers) as callouts. Things that Jonni does all the time and that really create a visual impact. I also wanted to utilise the penguin images as a “penguin picker” to create some interactivity.

I also wanted a map to be a main feature of the viz as maps are not only informative, but visually striking, highly customisable and also act as a canvas on which to overlay images (in oceans etc.). I had a problem at first with the fact that Antarctica was one of the main locations, and that meant the bottom of the map had a straight edge, which looked ugly. This meant the map would have to meet the bottom of the viz to draw attention away from the abrupt edge.

The IUCN scale

I was pretty pleased with the highlighted IUCN status of each species. The icons looked nice and almost acted as a traffic light theme. Jonni thought they should be greyscale but I overruled him. Pfft – what does he know anyway?

In terms of Tableau content, only a couple of charts to show population, location, height and weight; but that was fine. It didn’t really need anything else.

I also wanted to include a section on famous penguins but it ended up overloading the viz and spoiling the theme. Although it did make me smile. Bonus question – can you name all of these famous penguins?

How many of these famous penguins can you name?

I also considered the use of an embedded YouTube video but decided against it.

I had fun choosing the title font, something that I think can make a huge difference to the viewer if chosen well. Regular fonts were somehow boring, and fonts with penguin characters looked too cluttered. I finally managed to settle on an Austin Powers style font, and then had the idea of alternating the colours to give that penguiny feel. I like it!

In the end I think the final result was ok. However this wasn’t one that I enjoyed. See below.

 

4. Challenges

This was my first viz in a while. I’ve spent the last 3 years knee-deep in Tableau Server and have a crazy busy job building a Tableau Centre of Excellence, supporting thousands of demanding users so I’m the first one to admit I don’t have the Tableau Desktop skills of people like Adam Crahen, Neil Richards, Pooja Gandhi et al.

The standard of skill out there in the community is crazy good. And that really was the main challenge. I found this viz a fairly stressful experience, it made me feel like a newbie all over again, simply because I’d be putting this out there against some stunning competition. I even considered not entering for a while. But hey, that’s not what the Tableau community is all about so I thought I’d have a go at it.

As mentioned earlier, I was deliberately trying to emulate Jonni’s style. Now that proved to be pretty difficult. I managed to create something reasonable, and fairly quickly, and began thinking to myself that hey this is a piece of cake, Jonni who?? But then it got harder. My ideas began to dry up and I found myself staring at an okay-ish viz but being unable to take that next step to make it better. Felt like vizzers block.

And that’s when I realised that the people who create these REALLY good vizzes have a lot of inherent natural skills and imagination that folks like me lack. So I gave Jonni a call and asked his advice. He came back with a number of suggestions, none of them earth-shattering, but much more subtle and delicate. Making the map larger, bringing highlight colours out from the penguin plumage were a couple of suggestions that made a huge difference to the impact of the viz. My point here is that the real geniuses of visual design have these thoughts occur naturally and without significant effort, folks like me have to learn them, or at least work a little harder than some others.

But hey, IronViz (and any vizzing) is all about learning. So I’m good with that.

Another challenge was that the Tableau part of this was pretty easy. That’s obviously great and what we want from our favourite application, but in terms of this viz I spent more time in image manipulation tools than in Tableau. And that really did detract from enjoyment. Come on Tableau! Make it harder for us to complete our vizzes!

 

5. Analysis & Story

So what can we take from this story? Here are some of the key observations that Tableau has allowed me to glean from the dataset.

  • All penguins live in the southern hemisphere, and some in hot countries
  • There are some seriously big populations, although some are endangered
  • They range from massive to teeny tiny
  • Main predators are Leopard Seals & Sea Lions
  • There are not one, but two penguin days in the calendar

So that’s it. I hope you enjoy the visualisation. If you do then please consider voting for me in the IronViz competition. And thanks to Jonni Walker for providing advice for this viz. Top man.

Good luck to all the other entries this year. Especially blinders like this from Ken Flerlage. – The Killing Fields – Viz / Blog.

Hmm. After all that writing I could do with a chocolate biscuit. Now which one……

Regards, Paul

What we got wrong building our Tableau service

Posted on by
4

Hi

I spend a lot of time talking to other companies about how to put together a decent Tableau Centre of Excellence. And that’s cool. I love to help people and I also learn a ton from all the other great setups out there.

But that also gets me thinking. We are far from perfect. And we made a whole lot of mistakes on the way to building our service. So instead of talking about the good stuff we did, I thought I’d highlight what I think we got wrong.

So in no particular order of importance, here are our top mistakes

Onboarding

So you’ve done the demo, shown the capabilities of Tableau and your audience is wowed. They want it and they want it NOW! So how do you get them from wanting to having?

Well we didn’t do so well. Our purchasing is handled by another team and the process is fairly complicated. Our mistake was not building a solid enough relationship with the purchasing team early on and making an effort to understand the points of the process that could be improved. We kind of just let them get on with it when we could have offered more assistance. This meant that on occasion users had to wait up to 2 months before they actually got their licence! And sometimes that cost us users, who gave up during the process.

Eventually we got together and helped the purchasing team out. And now things are a lot better. My advice – if you see a team you have a dependency on are struggling, then speak to them and help them out. Sounds obvious, but on this occasion we didn’t.

Setting Expectations

I spend a lot of time talking to users, often at a senior level, asking them to feedback on their experience with Tableau. On the whole it’s great stuff that comes back, but occasionally I used to get surprised with users informing me that their experience was poor. Tableau didn’t do what they wanted, it was inflexible and hard to use.

That didn’t sound like the Tableau I know and love. So I did some more research and it turned out that the users who didn’t like Tableau were trying to get it to do something that it wasn’t designed for. Now that’s fine if you’re Allan Walker or Noah Salvaterra but most of my users aren’t that level – in fact few people are. And of course that meant the users were getting frustrated.

I think the comment that really resonated was “Tableau? That’s Excel online isn’t it?”. Er – NO IT ISN’T!

The problem was obvious. Users thought Tableau was something it wasn’t. And naturally they would get a degraded experience. So we created a document that clearly states what Tableau is good at, and what it isn’t good at. We make users read this doc when they sign up for the service so they know exactly what they are getting.

This was very successful and really cut down the instances of poor feedback.

Some related posts on this subject from Dan Murray, Matt Francis & Peter Gilks

Training from the Get-Go

I’m a self-learner. So is my team, and most of the people I work with. I’m sure you are as well, that’s why you’re here reading this. And as a result I expect others to be the same. And for the self-learner, the world of Tableau is great. Tons of bloggers, forums, help articles, Tweeters, online videos and all sorts of quality learning materials. It really is one of the strengths of Tableau IMHO.

So we created guides & 101 pages etc and told users to go and help themselves. And to be fair, some of them did. But not as many as we’d have liked. And as a result we got tons of newbie questions and consequently poor quality content on our server.

About 8 months into the service we decided to implement a structured, instructor led training programme, amongst other training initiatives. More details here. Much of the syllabus is covered by Tableau’s own online videos and other resources but for some reason, new users really responded to this structured course. As a result we saw a corresponding improvement in the quality of published content and a reduction in the basic level questions to the team. In hindsight we should have implemented this right at the start, rather than assuming everyone would be keen to self-learn.

Commercials

Much as I love Tableau, their commercial operation isn’t the most flexible. That’s not just my opinion, it has been mentioned in Gartner reports. As a result we’ve struggled to negotiate the most competitive packages that we could have done. There have been some valid reasons for that but I don’t think we put as much effort into resolving the related issues as we should have.

And that’s important. I don’t want to get the best price for the sake of it, in big enterprises there are a lot of competitive threats from other tools. If Tableau isn’t competitive with pricing then the people that make the technology decisions will be perfectly happy to rip it out and replace it with something else. Not what anyone wants.

Again much of this is down to relationship building. As our relationship with Tableau has grown, we’ve seen improvement in this area.

Gamification

I’m a big fan of gamification. It can really boost engagement and turn a good initiative into an awesome one. We’ve had a couple of half-hearted stabs at competitions, to try and get things going but there is so much more we can do. Hackathons, viz games, competitions and internal Iron Viz – we’ve got a ton of ideas but never made it happen yet.

I think that’s partially down to the wide geographical spread of my user base. It would be really hard to get people to show up in a particular location. Users are also insanely busy, would I be able to round up enough people to make it worthwhile? So lots of excuses and not a lot of achievement in this area. I’m open to ideas if you’ve got this one nailed.

That’s it for now. There may well be a part 2 to this as I’m sure there are more things that will come to mind as I cry myself to sleep thinking what a mess we’ve made of it all… 🙂

Thanks to the awesome Matt Francis for inspiring this post.

Happy vizzing, VN

Tableau Server – all about the… Backgrounder

Posted on by
8

Hello everyone.

You may know me as a Tableau Centre of Excellence manager. That can involve a lot of paperclip pushing skills, with the real work being done by my excellent team (thx @jakesviz & The Information Lab). But I do try and get down and dirty with my lovely Tableau Server environment to keep my skills fresh. Obviously I don’t mess with it – @jakesviz gets pretty protective about his Server.

This series of posts is my attempt to shed some light on the internals of Server. Note there are many more experts in this field than me (Craig Bloodworth, Mark Jackson, Jen Vaughan, Tamas Foldi, Mike Roberts, Angie Greenhaw – to name but a few) so please do comment if anything is incorrect here. Maybe you guys could help me evolve this post?

What is the backgrounder?

The backgrounder is a process that runs as part of the Tableau Server application. As the name suggests, it handles background tasks such as refreshing extracts, running subscriptions and also processes tasks initiated from tabcmd.

Here are the backgrounder processes. The .exe file and the .war file. The WAR file is a Web Application Archive, and contains all the necessary components and resources needed for a Web Application such as Backgrounder.

On a clustered environment you’ll find these files in D:\Program Files\Tableau\Tableau Server\worker.1\bin (may vary slightly with your installation).

28-01-2016 14-07-52

Other files related to the backgrounder.

Template (.templ) files – These files TBD

28-01-2016 14-13-09

There are also a few .rb files in D:\Program Files\Tableau\Tableau Server\worker.1\tabmigrate\db\migrate.

And we also have a .properties file which contains all the config entries relevant to the backgrounder. It also has almost all of the other stuff that you’d find in the main workgroup.yml file which is odd. I’d  have expected it to be just the backgrounder config.

backprops

Here is the location of the backgrounder log files

backlogs

Here are 2 instances of backgrounder.exe running on my server (from Task Manager).

28-01-2016 14-01-08

 

Can I mess with it?

Backgrounder can be configured. There are several settings present in both workgroup.yml and backgrounder.properties. Workgroup.yml is the master config file, and it populates the backgrounder.properties (and other .properties files) when a ‘tabadmin configure’ is run.

I don’t know what all of these do (yet) and the only one I’ve ever edited is ‘backgrounder.extra_timeout_in_seconds‘ which sets the max time in seconds that a backgrounder session can run for. Tableau kills off the session if this threshold is reached. Useful for forcing users to optimise their extract times!

I also pay attention to the ‘backgrounder.vmopts‘ parameter, as this defines the size of the java heap space for this component. All components have a vmopts setting and I’ve had to increase them on occasion due to out of memory problems.

You may also want to change the ‘backgrounder.log.level‘ if you need more debug info, although Tableau logs are chatty enough for me.

If there’s a golden parameter in this lot that you get value from then let me know in the comments.

backgrounder.deploy.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/backgrounder
backgrounder.external_cache.concurrency_limit: 10
backgrounder.external_cache.enabled: true
backgrounder.external_cache.num_connections: 1
backgrounder.external_native_query_cache_disable: true
backgrounder.extra_timeout_in_seconds: 1800
backgrounder.failure_threshold_for_run_prevention: -1
backgrounder.jdbc.wg.connections: 8
backgrounder.jdbc.wg.idle_connections: 4
backgrounder.log.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/logs/backgrounder
backgrounder.log.level: info
backgrounder.native_api.log.level: info
backgrounder.out_of_date_schedule_minutes: 240
backgrounder.ping_dataengine.millis_to_wait: 5000
backgrounder.ping_dataengine.num_retries: 24
backgrounder.ping_services.num_retries: 10000000
backgrounder.ping_services.time_to_wait: 5000
backgrounder.purge_directories.directories: ""
backgrounder.querylimit: 7200
backgrounder.restart_interval_in_minutes: 480
backgrounder.restrict_serial_collections_to_site_level: true
backgrounder.search_index_verification.enabled: true
backgrounder.sheet_image_api.max_age: 240
backgrounder.sleep_interval: 10
backgrounder.sort_jobs_by_run_time_history_observable_hours: -1
backgrounder.sort_jobs_by_type_schedule_boundary_heuristics_milliSeconds: -1
backgrounder.timeout_tasks: refresh_extracts, increment_extracts, subscription_notify, single_subscription_notify
backgrounder.tomcat.threads: 4
backgrounder.urlprefix: backgrounder
backgrounder.vmopts: -XX:+UseConcMarkSweepGC -Xmx512m

Note that Tableau Support don’t like you to edit config files manually, they recommend that you use the tabadmin set commands to change any parameters. They might have to change that recommendation when we see Tableau Server on Linux.

For more about .templ, Ruby & properties files check out this from Tamas Foldi.

 

What are the problems with the backgrounder?

Here are some of the things that can be problematic with the backgrounder.

  • Single Threaded – This means the backgrounder process can only run one thread at a time, a thread being a set of executable instructions that a process can perform. The upshot of this is that your backgrounder works through a queue of tasks one-by-one.
  • Latency – Due to the single threaded nature of backgrounder, you may see delays or ‘latency’. For example, if you have one backgrounder, and 2 tasks for it to perform at 2am, then task 2 will have to wait until task 1 has finished. If task 1 takes an hour then task 2 won’t start until 3am. This can be annoying for users that expect their data to be refreshed by a certain time.
  • Resource Intensive – The backgrounder can consume a significant amount of processing power (CPU) and input / output (I/O) on your server. This is dependent on the type of task it is performing. It’s not uncommon to see a backgrounder node consuming 100% CPU.
  • Other Stuff – The backgrounder process also does other stuff on Tableau Server that isn’t concerned with extract refreshes. For example – reaping extracts, checking disk space, synching Active Directory groups, rebuilding the search index etc. Bear that in mind when building your system. In reality these tasks don’t take up too much resource but they do take some and you should be aware.

 

Isolating the backgrounders

A common configuration in a clustered environment is to dedicate one of your worker nodes to the backgrounder processes. This means you can dial up the number of backgrounders and let them do their stuff without worrying about any impact on other processes. This is one of the most common performance recommendations from Tableau support.

You can also get a lot of info out of the Postgres DB relating to backgrounder usage and performance. Nelson Davis has posted a guide to getting started here.

 

Improvements I’d like to see

Ok so here are a bunch of improvements I’d like to see to the topic of backgrounders and extract management. I know some of this will drop in upcoming releases and some of these problems have been solved with custom solutions at some customer sites.

Alerting – Tableau Server doesn’t alert (email / IM / SMS) when a task fails. This means you’ll need to set up external monitoring to detect issues. I know Tableau are on this though so expect to see it in an upcoming version. Some people in the community have also coded their own solutions to this problem but it really should be native functionality.

Control per site – We segregate our dev / test / prod user environments using sites , all on the same server. We run 8 backgrounder processes on that server, which are shared across the tasks on all sites. As an administrator I’d really like to be able to bind backgrounder processes to specific sites. For example, 2 backgrounders on each of dev & test sites, then the other 4 dedicated to the production site. That would ensure production tasks always have enough resource to be able to execute on time.

Control per process – I’d like to be able to stop / pause / mess with individual backgrounder processes easily. It is possible – see this from Toby Erkson, but it would be good to have this as part of an administrator console or something.

Control per type / size / pattern of extracts – It would be good if I could dedicate specific backgrounder processes to particular extracts based on their characteristics. In particular I’d like to allocate one backgrounder to all the extracts that take less than 1 minute to complete. Or even use this to reward users that show diligence with their extract management by dynamically prioritizing incremental refreshes or extracts that have a low failure rate.

Better metrics – I’d like to see exactly how much CPU is taken up by a particular backgrounder process or task / schedule or per project. This would be useful for chargeback.

Dynamic reprioritisation – I love all my users. But in particular the ones that take good care of their extract refreshes. I’d like Tableau to be able to dynamically increase the priority of tasks that complete quickly, are incremental and that have a low failure rate. The message being, if you want your stuff to get the best slice of available resource then help us out with best practice.65

Disable run now – We’ve had some issues with the “run now” option that allows users to kick off an extract refresh on-demand using the UI. In particular we’ve seen some trigger-happy users bring our server down by hammering on the run now option multiple times. I’d like to disable that or maybe throttle it somehow.

Better guidelines from Tableau – The documentation from Tableau isn’t great in this area.

05-05-2016 13-09-11

I have an 8 core 128GB server and  run 8 backgrounders with no capacity issues. And I know of other organisations running way more than that. According to this doc I should be running between 2-4. That would be some serious under-utilization of the server. I’d like to see some clearer recommendations, maybe taking into account the variety of use cases that I’ve seen in other big enterprise deployments.

 

OK that’s all for now. This post could have been more detailed but I figure that I’ll get some valuable inputs from the community that will help me expand it. Actually in the time I was writing this, Mike Roberts was doing the same – check his post for some excellent info.

Cheers, Paul

 

The Svalbard Global Seed Vault

Posted on by
Reply

makingof

Hi all,

OK here we go. Iron Viz competition time. My first viz in a long time, so it’s good to get back using Desktop again. The first competition this year is the Food Viz contest!

1. The Idea

So this one’s all about food. Plenty of potential ideas here but I love to deviate from the norm and go a little bit off the wall, a little bit unusual.

I got thinking about food. But then I thought what would we do if there was NO food? If we had nothing to grow. If all the crops in the world failed overnight. What would we do? That would be a pretty bad situation for sure and someone must have a backup plan. I’m in IT as you might know so I do love a good backup plan.

And it turns out there is one. The Svarlbad Global Seed Vault. Buried 130m into the Norwegian permafrost, this building looks more like a Bond villain’s hideout than a critical storage facility. Once I saw this website my mind started racing with questions and that’s a good sign that you’ve got a decent subject for a viz.

 

Screen Shot 2016-04-19 at 08.36.51

The Svalbard Global Seed Vault

Go take a look at the viz!

 

2. Data

I got the data from 3 main sources.

The main seed stocks data

Plenty of detail in the data which gives some good potential for analysis. The main seed stats xls was pretty tricky to work with. There were a lot of nulls and gaps which I had to exclude from the dataset, and the file was pretty untidy. There were also close to a million rows in the file and that meant my pc struggled at times. All of this made manipulating the data tricker than I would have liked.

 

3. Viz Design

As with last year’s entry I thought I’d use Story Points again. This format has limitations but I think it works well for visualisations that answer multiple questions. In terms of formatting, I’ll be honest. I just didn’t have the time to mess about so I pretty much went with the same style that I used for my Evolution of the Speed Record viz last year.

Screen Shot 2016-04-18 at 22.35.49

Construction stats

I also thought I’d use a lot of images with this viz. The seed vault is an impressive construction and had a load of really good quality images available for use. I found it was useful to use a text box to provide additional commentary on each slide.

 

 

 

Screen Shot 2016-04-18 at 22.39.29

Seed vault funding

Most of the information about the seed vault made a big deal about how this was a big global project. This led me to question who was contributing and supporting the project and who was pretending to? I was pretty sure there would be a big difference in contributions, both in terms of stock and also finance.

 

 

Screen Shot 2016-04-18 at 22.40.21

Embedded Wikipedia page

A technique I learned last year was embedding a contextual Wikipedia page into the viz. This provides more detail for anyone wanting to know more about the data points.  A good tip is to append “?printable=yes” to the URL to display a more cut down page, as well as using the mobile URL (thanks to David Pires for that tip). Some of the links didn’t work as there wasn’t a direct Wiki page – no big deal.

 

So there you go. An interesting story for sure and one that was pretty enjoyable to put together.

 

4. Challenges

This was my first viz in a while. I’ve spent the last year knee-deep in Tableau Server and have a crazy busy job building a Tableau Centre of Excellence, supporting thousands of demanding users.

So my biggest challenge wasn’t data, or thinking of a subject, it was my own lack of ability with Tableau Desktop. I was shocked at how rusty I’d become and even some basic tasks took way longer than they should have. On the plus side it was great to be back on the vizzing horse again! I’m now inspired to get stuck into some of the online training and boost my skills.

Another challenge was actually deciding to have a go. The standards in the Tableau Community have gone through the roof in the last year, and the level of quality out there is absolutely amazing. So for the first time ever I was nervous about even getting my entry out there.

 

5. Analysis & Story

So what can we take from this story? Here are some of the key observations that Tableau has allowed me to glean from the dataset.

  • The Svalbard Global Seed Vault was a decent build. Didn’t cost too much and also only took 20 months. Pretty impressive going.
  • Some unusual crops stored in the seed vault. Rice at the top, and mostly concentrated around the Triticeae tribe of crop – wheat, maize etc. Surprisingly few fruit. I like blueberries so I’d be stuffed without them for my doomsday breakfast.
  • Probably not a surprise to see India top the seed donations chart but it was curious to see several African nations amongst the top donators.
  • I was surprised to see seed donation amounts tailing off big time in recent years. I wonder if that’s down to project apathy or maybe we’ve just got all the samples we need for now?

Wanna know even more? Go check out this Interactive 360 tool.

So that’s it. I hope you enjoy the visualisation. If you do then please consider voting for me in the IronViz competition.

Regards, Paul

How To Set Up Your Tableau Server Environments

Posted on by
3

Hi,

Guess what this post is about – yes TABLE CALCULATIONS…. haha. No chance. Talk to Jonathan Drummey about those. This is of course yet more info that I hope will help you guys set up a dream Enterprise Tableau deployment.

Today we are gonna talk about Environments – i.e. what Tableau environments should you create in your organisation to give your team the best chance of success and keep your lovely users happy?

As always, I’m not saying this is THE way to do it. There are tons of great setups out there. I’ll just tell you what we have. Feel free to suggest better methods in the comments.

 

Environments for your users

This section is concerned with environments that you will provide for your Tableau users to do their work. Typically this will follow the standard Information Technology Infrastructure Library (ITIL) environment definitions, but there are a few things you can do to add extra options for your users.

These are the environments our users have at their disposal:

  • Production – The main business & user facing environment. Content published here is authoritative, follows best practice (hopefully) and is actively supported.
  • Testing – aka UAT. Generally used for final testing of uploaded content
  • Development – The environment where content is first shared as part of the development process.
  • Scratch – An extra environment for content that doesn’t need environment management. E.g. User wants to temporarily share content with a couple of colleagues.

Providing these environments gives users crucial options and flexibility. Your Tableau service will most likely serve many different business areas and teams, each with different practices for content development and release management. Some teams will rigorously follow Systems Development Lifecycle (SDLC) processes, creating content in development, promoting to User Acceptance Testing (UAT) and then eventually to Production. Other teams are totally happy to change content directly in Production, as and when they feel like it.

Crucially we don’t mandate what our users do, it’s a self-service model and so long as they follow their own due-diligence and governance procedures then that’s cool with me. The important thing is that we give them options to work with Tableau in the way that they want. If they break anything then they know it’s down to them.

The scratch environment is an interesting concept. It started with good intentions but realistically not many people are using it. So it looks like we might bin that.

Note that we use Tableau sites to segregate our environments.

 

Environments for your team

This is different from the above user-facing environments. These are the environments that your team uses for the service you provide. Obviously all this costs money in terms of hardware procurement and usage, depending on the spec you choose.

  • Production – Main environment that serves your users. In our environment this also includes the UAT, Development & Scratch sites for users – but we class it all as production. That might seem odd, but remember that many teams will be development teams, and to them the development site / area is their equivalent of production. So if the development site is down then they can’t work.
  • Disaster Recovery (DR) – For use in the event of a Production outage that can’t be easily restored. Exact same spec as Production. Totally identical, so that config can be restored and this server can be used as Production. You’ll need to make sure this environment gets the same upgrades as your Production environment.
  • UAT – This is UAT for my team. If we want to make a change to Production, it gets final testing here. This environment is also the exact same spec as Production to ensure an accurate test. If it fails here then it’s likely to fail in Production as well. We use UAT for testing maintenance releases, config changes and other potentially disruptive non-Tableau related changes to the server. Additionally, we make this environment available to users for a couple of weeks UAT prior to releasing new versions to production.
  • Engineering – Lower spec than prod & UAT. For testing the latest available release from Tableau. That is likely to be a higher version than production. Is useful for spotting bugs in new versions or confirming that bug-fixes work.
  • Beta Test – We are proud to be part of Tableau’s pre-release testing audience. We use this server to test releases in the Beta programme. Lower spec than engineering. To the point that the server only just meets the minimum requirements.
  • Alpha Test – We use this to test the alpha releases or any extra work we may be doing with developers at Tableau. We love to be involved in the genesis of new functionality.

So that’s what we are lucky enough to have. It’s not perfect but it allows us to give our users a ton of flexibility in how they use Tableau, and also my own team always has a place to test new releases, plan upgrades and help Tableau with their pre-release programmes.

Interested to see what the community has in terms of environments. Let me know in the comments. Remember there are a load of other posts on this blog about Enterprise Tableau considerations.

Cheers, Paul