Voice of the DBA

Category: Editorial

  • Milk

    cow
    It’s amazing how much knowledge goes into selecting cows for milk production.

    I love this quote: “[we] ran it through a fairly sophisticated computing gobbledygook. It spit out at the other end predicted transmitting ability, predicted genetic values of whatever sort.”  How would you like to explain your complex analysis to a business user using those terms? In most cases, those might be the best way to describe things to most users.

    However that quote comes from a scientist that has spent a lot of time and knowledge refining models and using lots of data to try and predict the bulls whose progeny will result in the best dairy cow performance. The article is very interesting and talks a bit about the complexity of using genome data on cattle and how far it is from the experiments Mendel performed on pea plants. I still remember the dominant/recessive gene explanations from biology, though that explanation seems simplistic now. Comparing it to the work done by scientists predicting cow performance is like comparing horse drawn carriages to Formula 1 race cars.

    Big data is in the news, with so many companies building products they want to sell to help you tame, analyze, and use the data your organization has available. However as this article hints, it’s much more than managing all that data. There is a tremendous amount of knowledge and intelligence needed to use those tools and actually generate useful information.

    As data professionals, we don’t necessarily need all that knowledge, but we do need to communicate with those individuals that may have the knowledge and work closely with them to ensure their ideas are accurately applied against data in the algorithms we write. In addition to writing code and understanding statistics, strong communication skills are important to moving your career forward.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • No Limits

    Google Compute Engine
    No limits for the Google Compute Engine, at least not any practical limits.

    We’ve had Amazon Web Services (AWS) available for some time, and used for some interesting projects that wouldn’t be possible if groups had to purchase their own equipment. From password cracking to cancer research, there are some amazing possibilities. Windows Azure works as well, and there are customers such as banks, using the cloud to perform complex analysis of data. Not to be left out, Google announced recently they were provide their Google Compute Engine to anyone, without any limits on scale. You have to pay for it, but if you want 770,000 cores to solve a problem, they’ll provide them if you can pay for the resources. It’s US$2m/day, but it’s there.

    I don’t know what that means for us as data professionals, but I suspect there will be any number of companies that will consider using these types of resources to work on complex analysis of problems. Running a simulation might be something that costs a few hundred dollars a day, using resources for minutes at a time. Looking over some of the different projects people have used cloud computing engines for, it seems that many businesses might find this to be a cost effective way to perform data mining or BI type workloads.

    If you can get the data to the engine. I still wonder how challenging this is, apart from all the security concerns. Just moving that much data around, refreshing it, removing the stale data, could be very complex. It concerns me that as more people attempt this type of work, we will have more and more poor decisions made because of data quality, age, or accuracy. After all, garbage in, garbage out has been a tenet of data professionals for decades.

    If you’re using cloud resources for computation, I’d love to know about it. I know many of the data professionals out there have reservations, and that’s healthy. It shouldn’t blind you to the possibilities that this is a most cost effective way of actually getting analysis and answers for your users.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Separate Accounts

    Separated Strawberry
    Is separation that much of a hassle? I don’t think so.

    Many years ago I worked in a small company that only had about 5 or 6 servers. We had one system administrator whose job it was to manage all the servers. One day our sysadmin was on vacation when there was a problem with the Exchange server. One of the other developers worked on the system and ended up fixing it, but changed the service account password while doing so. The next day I walked into the office to find a group of people stymied as to what was wrong with the development server and version control system. Everyone claimed they hadn’t changed anything on that server, and they were right. However our admin used the same domain account for all servers, including my SQL Servers. I changed the SQL service account that day.

    One of the recommendations that I learned a long time ago, and one that I make regularly, is that every SQL Server instance should have a separate security account. In that case, I had separate accounts created for each database instance, and for each SQL Agent instance. We used long, random passwords that were never stored, and if we needed to access a password, we just changed it. That kind of flexibility and separation prevented any crosstalk issues between services, and it allowed us to easily alter permissions or passwords for one service without affecting any others.

    The other day I saw someone recommending a single service account for all SQL Servers. Someone else recommended a single account for each version of SQL Server, using separate accounts where it’s really needed. That’s a better recommendation, but I still prefer completely separate accounts. I know that some security groups don’t like that, but is it that big a problem? This Friday I wanted to ask you about your experiences.

    Do you find separate accounts for each instance (or Agent) to be a security or administrative issue?

    I’m not sure why this is unwieldy. Service accounts rarely change, and you could easily script changes to a group of accounts with PowerShell or some other tool. Once I set a service account, the only thing I might ever do later is alter the permissions to add access to a folder. When that happens, I definitely want to have separate accounts for each instance.

    Let us know this Friday how you feel and what works for you.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • A Data Hub

    Hub and spokes
    The idea of a data hub seems very interesting to me as a DBA.

    One great promise of data warehousing over the years has been a “single view of the truth” for companies. By moving, cleaning, transforming, and standardizing data from other systems, we can put together a single location for the most accurate data a company can have. I suspect there are some organizations that have had success here, but many are struggling. The idea behind some of the newer SSIS tasks, Master Data Services (MDS), and Data Quality Services (DQS) in SQL Server is that we have some functions in the SQL Server platform to make this easier to achieve. Or perhaps to ensure we do so at a high level of success.

    However just moving data to a central location isn’t necessarily the only way to deal with the challenges of data. Perhaps there’s a better way, a more distributed way that provides a framework for centralization, but distributes the ownership and knowledge of the data to others. Buck Woody recently wrote about data hubs as a project and idea that Microsoft is making available. It’s a place to publish data for your organization, but groups inside your company, but available for others to use.

    Many of us have experienced the issues of each developer or each department attempting to manage their own sources and lookup data. Even well known data such as postal codes can change and easily become stale quickly. How many developers are willing to write import routines to update this data for something such as postal codes, let alone internal data such as customer names.

    Ideally I think we should pull lots of our initial data from corporate sources, and establish central data hubs for all new types of information we gather and support. From there, a variety of import and update routines could be written and shared by all applications people use. It wouldn’t provide perfection in terms of data quality and freshness, but it would be better than allowing each individual developer to make their own decisions.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.