Search results matching tags 'Career' and 'Data Professional'

A SQL Saturday in Cambridge – Buck Woody’s Ragtime Database Workshop

BuckWoody — Mon, 30 Jul 2012 20:49:00 GMT

The SQL Server community is really engaged. They are an active bunch on Twitter, Facebook and LinkedIn, they help each other on forums, they attend conferences. But that isn’t enough interaction – the community started a grass-roots effort to hold local conferences on a Saturday. Free conferences. Odds are there’s one near you… http://www.sqlsaturday.com/default.aspx … and if not, you can start one.

Sessions at SQL Saturdays are all over the map, and there’s something for (almost) everyone, from Business Intelligence to Database Administration and Development. Some of these events have “training days” associated with them – longer, more in-depth training that has a fee. I’ve taught quite a few of these, and of course I’ve done my share of other presentations at the events as well.

I’m honored to be presenting at the Cambridge, UK SQL Saturday this year (http://www.sqlsaturday.com/162/eventhome.aspx) in September. For one thing, I used to live near there and plan to take the family with me to show them my old stomping grounds. For another, I’m excited about the sessions I get to present.

The Training Day

Friday I’ll be leading one of those training days – and I’ll be delivering a very important workshop, where I’ll cover SQL Server – all of it. OK, maybe not *all* of it, and maybe you won’t be a complete PhD after the class, but we’ll do a complete immersion in learning SQL Server as a product from the ground up. It’s a workshop format, so no sitting and listening to someone droning on and on for hours. You’ll be asked to bring a laptop, and do actual work on the product from the first few minutes of the 8-hour day to the last of the workshop. You’ll be jumping in from the very start, and in deep until the end of the day.

But wait – this is kind of a “beginner” thing, isn’t it? Shouldn’t I be doing something on the internals of the locking mechanism of the hashing system in memory on x64 architectures, with complete code diagrams? Shouldn’t you be able to snatch the T-SQL pebble from the master’s hand when you’re done, or be able to shoot the wings off of an XML fly when you’re done?

No.

We need this kind of session. For one thing, you can get that depth in other sessions. For another, we need to have a place for someone that wants to learn SQL Server but doesn’t have a lot of time to do that. We need something relatively inexpensive that a boss can send a developer, administrator or new employee to learn how to take over the SQL Server, or augment the DBA team. We need a place where good habits are formed, and where someone can branch out into a new part of technology, into one of the best places in tech to be – data.

After you’re done with this session, stick around for Saturday – now all those presentations will make more sense. And you’ll be able to network with a lot of folks that already do what you learn about on Friday, and who knows – find out where to look for work in this amazing career field.

What will you learn?

You’ll start with knowing that SQL Server is a database product by Microsoft. That’s all the pre-requisite you need, other than being the technology industry. From there we’ll cover:

The Data Professional Career
Installing, setting up and configuring the right Edition of SQL Server for the job (including SQL Azure)
Database engine fundamentals – How does the engine work, what are the components, what can you configure and tune
Transactions, Locking and Blocking
Creating and managing databases
Database options and their impact
Database Objects including Tables, Views, Stored Procedures, Functions and more
General maintenance including backups and recovery
Security fundamentals including users, roles, and object security
Performance tuning fundamentals including indexes and query research tools
Multiple resources to help you get to the next level

In 8-hours. Come ready to learn. You’ll need a laptop, and complete focus for a few hours. You’ll leave with the ability to manage and work with a SQL Server system – and you’ll learn what to do next.

Who should go?

If you’re new to Relational Database Management Systems (RDBMS’s) but not technology, and you’re looking to expand your technical reach, coming from another platform (to be sure, there will be some repeat info here), want to explore a new tech career area, want to learn more about developing against an RDBMS or know someone who does.

The registration for the training day is here: https://www.regonline.co.uk/?eventID=1120017&rTypeID=242030

What else are you doing whilst (I love saying whilst) there?

I’m also pleased to be providing the keynote on Saturday. (I can’t wait to see what I’m going to say), as well as two other sessions – more on those soon. My daughter wants to be a Zoologist, so while we’re there we’ll be visiting the Zoology museum at one of the colleges, I’ll probably eat too much and potentially go punting. I’ll also mingle with you, my SQL Family, and we’ll just generally have a good time.

If you’re not busy in September, and even if you are, make plans to come check all this out. It promises to be awesome. (Americans think everything is awesome)

See you there.

The Data Scientist

BuckWoody — Tue, 15 Nov 2011 15:00:18 GMT

A new term - well, perhaps not that new - has come up and I’m actually very excited about it. The term is Data Scientist, and since it’s new, it’s fairly undefined. I’ll explain what I think it means, and why I’m excited about it.

In general, I’ve found the term deals at its most basic with analyzing data. Of course, we all do that, and the term itself in that definition is redundant. There is no science that I know of that does not work with analyzing lots of data. But the term seems to refer to more than the common practices of looking at data visually, putting it in a spreadsheet or report, or even using simple coding to examine data sets.

The term Data Scientist (as far as I can make out this early in it’s use) is someone who has a strong understanding of data sources, relevance (statistical and otherwise) and processing methods as well as front-end displays of large sets of complicated data. Some - but not all - Business Intelligence professionals have these skills. In other cases, senior developers, database architects or others fill these needs, but in my experience, many lack the strong mathematical skills needed to make these choices properly.

I’ve divided the knowledge base for someone that would wear this title into three large segments. It remains to be seen if a given Data Scientist would be responsible for knowing all these areas or would specialize. There are pretty high requirements on the math side, specifically in graduate-degree level statistics, but in my experience a company will only have a few of these folks, so they are expected to know quite a bit in each of these areas.

Persistence

The first area is finding, cleaning and storing the data. In some cases, no cleaning is done prior to storage - it’s just identified and the cleansing is done in a later step. This area is where the professional would be able to tell if a particular data set should be stored in a Relational Database Management System (RDBMS), across a set of key/value pair storage (NoSQL) or in a file system like HDFS (part of the Hadoop landscape) or other methods. Or do you examine the stream of data without storing it in another system at all?

This is an important decision - it’s a foundation choice that deals not only with a lot of expense of purchasing systems or even using Cloud Computing (PaaS, SaaS or IaaS) to source it, but also the skillsets and other resources needed to care and feed the system for a long time. The Data Scientist sets something into motion that will probably outlast his or her career at a company or organization.

Often these choices are made by senior developers, database administrators or architects in a company. But sometimes each of these has a certain bias towards making a decision one way or another. The Data Scientist would examine these choices in light of the data itself, starting perhaps even before the business requirements are created. The business may not even be aware of all the strategic and tactical data sources that they have access to.

Processing

Once the decision is made to store the data, the next set of decisions are based around how to process the data. An RDBMS scales well to a certain level, and provides a high degree of ACID compliance as well as offering a well-known set-based language to work with this data. In other cases, scale should be spread among multiple nodes (as in the case of Hadoop landscapes or NoSQL offerings) or even across a Cloud provider like Windows Azure Table Storage. In fact, in many cases - most of the ones I’m dealing with lately - the data should be split among multiple types of processing environments. This is a newer idea. Many data professionals simply pick a methodology (RDBMS with Star Schemas, NoSQL, etc.) and put all data there, regardless of its shape, processing needs and so on.

A Data Scientist is familiar not only with the various processing methods, but how they work, so that they can choose the right one for a given need. This is a huge time commitment, hence the need for a dedicated title like this one.

Presentation

This is where the need for a Data Scientist is most often already being filled, sometimes with more or less success. The latest Business Intelligence systems are quite good at allowing you to create amazing graphics - but it’s the data behind the graphics that are the most important component of truly effective displays.

This is where the mathematics requirement of the Data Scientist title is the most unforgiving. In fact, someone without a good foundation in statistics is not a good candidate for creating reports. Even a basic level of statistics can be dangerous. Anyone who works in analyzing data will tell you that there are multiple errors possible when data just seems right - and basic statistics bears out that you’re on the right track - that are only solvable when you understanding why the statistical formula works the way it does.

And there are lots of ways of presenting data. Sometimes all you need is a “yes” or “no” answer that can only come after heavy analysis work. In that case, a simple e-mail might be all the reporting you need. In others, complex relationships and multiple components require a deep understanding of the various graphical methods of presenting data. Knowing which kind of chart, color, graphic or shape conveys a particular datum best is essential knowledge for the Data Scientist.

Why I’m excited

I love this area of study. I like math, stats, and computing technologies, but it goes beyond that. I love what data can do - how it can help an organization. I’ve been fortunate enough in my professional career these past two decades to work with lots of folks who perform this role at companies from aerospace to medical firms, from manufacturing to retail.

Interestingly, the size of the company really isn’t germane here. I worked with one very small bio-tech (cryogenics) company that worked deeply with analysis of complex interrelated data.

So watch this space. No, I’m not leaving Azure or distributed computing or Microsoft. In fact, I think I’m perfectly situated to investigate this role further. We have a huge set of tools, from RDBMS to Hadoop to allow me to explore. And I’m happy to share what I learn along the way.

Big Data and the Cloud - More Hype or a Real Workload?

BuckWoody — Tue, 18 Oct 2011 13:57:36 GMT

Last week Microsoft announced several new offerings for “Big Data” - and since I’m a stickler for definitions, I wanted to make sure I understood what that really means. What is “Big Data”? What size hard drive is that? After all, my laptop has 1TB of storage - is my laptop “Big Data”?

There are actually a few definitions for this term, most notably those involving the “Four V’s” Volume, Velocity, Variety and Variability. Others disagree with this definition. I tend to try and get things into their simplest form, so I’m using this definition for myself:

Big data is defined as a large set of computationally expensive data that is worked on simultaneously.

Let me flesh that out a little. To be sure, “Big Data” has a larger size than say a few megabytes. The reason this is important is that it takes special hardware to be able to move large sets of data around, store it, process it and so on. (large set)

If you store a LOT of data, but only use a small portion of it at a time, that really isn’t super-hard to do. It’s mainly a storage issue at that point. But, if you do need to work with a large portion of the data at one time, then the memory, CPU and transfer components of the system have to adapt to be responsive - new ways to work with that data (game theory, knot-algorithms, map-reduce, etc.) need to be brought into play. (computationally expensive)

Once that data is loaded into the processing area (memory or whatever other mechanism is used) it must be worked on in parallel to come back in a reasonable time. You have two options here - you can scale the system up with more internal hardware (CPU’s, memory and so on) or you can scale it out to have multiple systems work on it at the same time using paradigms such as map/reduce and so on. Actually, when you lay this out in an architecture diagram, scale up or out doesn’t actually change the logical structure of the process - in scale out the network becomes the bus, and the nodes become more RAM and computing power. Of course, there are changes in code for how you stitch the workload back together. (worked on simultaneously)

So back to the original question. Is Big Data, as I have defined it here, a workload for Windows and SQL Azure? Absolutely! In fact, it’s probably one of the main workloads, and I believe it represents the latest, and perhaps also the earliest frontier of computing. Jim Gray, a former researcher here at Microsoft and a hero of mine, was working on this very topic. I believe as he did - all computing is simply an interface over data.

Microsoft has multiple offerings on the topic of Big Data. In posts that follow from myself and my co-workers, we’ll explore when and where you use each one. Whether you are a data professional or a developer, this is the new frontier - don’t wait to educate yourself on how to leverage Big Data for your organization.

Hadoop on Windows Azure and SQL Server - Microsoft’s partnership to include Hadoop workloads on Windows Azure and SQL Server/Parallel Data Warehouse (PDW)

LINQ to HPC - Microsoft’s High-Performance Computing SKU of HPC is now in Azure

Windows Azure Table Storage - A key/value pair type storage with full partitioning that is immediately consistent, able to handle huge loads of data and works with any REST-compatible language

Other offerings - Including the new Data Explorer, Project Daytona (with a Big Data Toolkit for Scientists and researchers), Power View and more.

The era of Big Data is here. And you can use Windows and SQL Azure to bring it to your organization.

The New World of Work: Swarms

BuckWoody — Tue, 24 Aug 2010 11:11:09 GMT

I’ve been reading some excerpts from Gartner, Inc. and information from others on the changes they are seeing in the workplace. It’s holding true where I work and in the workplaces of the other data professionals I work with. One of those new trends is called “Swarming” – where informal teams get together to work on a particular project, and in some cases a single task, as a group. They then move on to another task, and so on, like a swarm of bees. These are less formal than the “Tiger Teams” I used to be part of that were also temporary, but had a more formal banding and dis-banding. The Gartner article states that this is more often the norm in companies than not.

This is interesting to the data professional because there are usually so few of us in the organization. There are on average a single data professional for every five to ten developers, or in an operational sense, one DBA for every several hundred servers in my experience. So when a “swarm”, or “tiger team” or any other kind of tactical group is assembled, the data professional is usually required to be part of it. That’s fine, but it ends up with a few outcomes that you might not expect.

For one, the rate of burn-out or overwork can be higher, since not everyone else works on every project like you do. The data professional has to take part in all of them, so you move from high-stress project to project. The key here is that since not everyone is on every project (except you) they may not notice it happening. They only see you on "their" projects, so they assume you're working at the same level as they are.

Another impact of a swarm on a data professional is that over time you might become more tactical than you want, and you might also be perceived that way by others. After all, if they only see you responding to fires, perhaps they’ll think that’s what you like or what you are good at.

So how do you mitigate these problems associated with this new way of work? Communication. You need to let your boss know, in a non-complaining way, what your workload looks like. No, not how *much* work you have, but what *kind*. They need to understand that you would like the ability to have a good pace to allow for the best quality work, and most importantly that you would like to build some time into your schedule for strategic work along with the tactical requirements. Of course, you need to balance this with actually getting your work done, but I have a few ideas about that which I think might be able to help. I’ll blog about those another time.