Voice of the DBA

Category: Editorial

  • Do I Need to Learn Linux and R and Python?

    The big changes coming in SQL Server 2017 are the Linux version and the addition of Python as a language used to analyze data. In SQL Server 2016, we had the R language added, and quite a few people have been on crash courses learning R, or worrying about the fact they don’t understand how to write an R script. Now many of these same DBAs and data professionals worry that they also need to find time to pick up some Python and Linux.

    I really like Python. I spent some time with the language and still dabble here and there. It’s a clean, easy to write and read language. My son took an intro CS course this spring in college and we shared some programming thoughts and ideas in Python. If you’re interested, I’d recommend the Dive Into Python book, as well as the meeting series from SDTIG. If you want to learn R, I’ve been dabbling at TryR from CodeSchool. There are also resources from Grant Fritchey and Buck Woody. For Linux, there are tons of resources out on the Internet. I don’t have a recommendation, but feel free to leave one in the discussion.

    If you are a data professional that works with data scientists or others that might want to incorporate some machine learning or complex analysis inside SQL Server, do you need to learn R and Python? Is that the feeling that you have? Are these languages require to ensure that you can perform your job?

    I’d argue that for many of us, we don’t need to understand the language or be able to write R or Python scripts that are being run in SQL Server, or even in a tool like Power BI, to support our users. We should understand how to execute these scripts, and maybe how to correct simple typos. A working knowledge of HTML has come in handy many times for me when helping users display their data and a quick change was needed. However, I wasn’t the person you’d call to design a complex CSS and interactive HTML pages. I can just fix a few simple mistakes.

    You might feel differently, but I don’t think most SQL Server professionals, developer or DBA, really need to learn R or Python. Feel free to do so if you like, and I’d put in a recommendation for Python, which I really like, but I don’t expect that either one will be a significant part of your job in the future. Learn Linux if you want to experiment with another OS, but for the most part, SQL Server on Linux is just SQL Server. Learn some rudimentary Linux skills, but spend most of your time making sure you understand the SQL platform and you’ll be fine.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Audio Attacks

    There are running jokes about how Amazon Alexa and Google Home are susceptible to visitors in your home. It’s become a bit of test from some geeks who will walk in your house and call “Hey, Alexa” out loud to see if you have a device that’s available. I even had an accidental Siri activation while recording some content recently. I said something that started Siri listening on my phone and then a few people nearby kept trying to duplicate the effort. Fortunately Siri wouldn’t come on, so no one was able to cause too much trouble. I suspect that the speakers in the recording room weren’t positioned well enough to allow the control room based hacking.

    I know that will change. In fact, even if Apple and other companies manage to get digital assistants to recognize specific people’s voices (as rumored), technology marches on. People are already starting to fake audio data. The fidelity of digital recording and capabilities of speakers improve constantly. This is going to be a greater and greater issue over time, and I have no idea what security technique will prevent things. Maybe we need two factor authentication for audio commands? Won’t that defeat the purpose?

    As data professionals, we are going to be dealing with more and more types of data, and trying to process, analyze, and act on information. This is one reason that I think understanding data lakes and being able to import and combine many types and formats of data will be a valuable skill for all data professionals. Whether you use something like Azure Data Lake or another platform, I expect to be combining data in all sorts of ways and providing information to users.

    While speech recognition might not be something many of us worry about, will we want to extract information from audio or video and use it? Do we expect that audio files have more integrity than other sources? I worry that we give some types of data more veracity than others, when all types are subject to hacking. Some of us may get audio files as data, and it’s only a matter of time before we get hacked, perhaps with fake audio.

    One of the issues we have with some data is determining the source of record. If I record my voice as a sample, and you compare all future audio of me to that sample, you can verify my identity, right? What if someone can fake my voice with simple software? It sounds crazy, but those days are coming, especially if our systems are susceptible to a person stitching together words from different captures, such as some of Baracksdubs. What might be worse is when we find someone hacking a database and replacing the samples. What’s the source of record then?

    As I spend more time in this business, I become more convinced that auditing and monitoring are more important that security. We want them all, but I’d rather know I have an issue than assume my systems are protected because the security doesn’t appear to be broken.

    Steve Jones

     

  • Naming Conventions for the Cloud

    There are plenty of controversial topics in technology to write about. Today I want to combine two of them into one piece: the cloud and naming standards. I’ll leave tabs v spaces and language choices for another day.

    I like the cloud, and I especially like Azure. I’m not sure that it fits with most applications and organizations and at times I question the value for some parts of the platform, but overall, the ideas are great. I tend to work more in Azure because I’m an MS stack person, but I suspect AWS and the Google Cloud Platform are similar. Many of the cloud platforms, or even the various services from vendors like Rackspace offer lots of opportunity and an amazing set of platform services.

    However, as there are more and more options, tracking the various items and services that you are using becomes an issue. This isn’t a new problem, and I’ve faced the same issue in large Fortune companies. Inventory and management of any technology at scale is hard. This brings me to naming standards. Many of you have probably dealt with naming standards in development and perhaps argued about the choices that your team uses.

    There are also issues for infrastructure, which can be more complex and problematic in the cloud. Because we don’t have complete control over devices, we are limited to managing our objects through interfaces. At least in my data center I can fall back on labeling or connecting to a physical box to determine what services are running. Or even turning a system off to see who complains, something I’ve had to do in the past.

    In the cloud, the world gets confusing quickly because we have many more types of services. Not only items like VMs and databases, but we can have network interfaces, disks, storage accounts, load balancers, and more. In fact, the list in Azure has gotten extremely long. The addition of things like Azure Functions and Azure Logic Apps have me worried that we’ll start to lose control of our infrastructure. The one thing that I appreciate is Resource Groups, which allow me to put groups of items together.

    However, even with these tools, I sometimes find myself confused over what’s running. When I ran across John Paul Cook’s post on naming standards, I realized that I needed to get better organized with my resources. Having some sort of naming standard might help me quickly identify items and keep my portal organized. Even with the various icons, sometimes I get them confused because there are so many different possible icons and services. With a prefix and a resource group, maybe I’ll be better able to track which items I need to keep and which I don’t.

    As you grow the number of anything, the overhead for organization and management grows. It becomes more important to track what you have and use, especially when you’re being charged by the resource. I expect that many of us will be answering questions and reporting on not only usage and performance, but also cost for some part of our jobs as more applications move to the cloud.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5MB) podcast or subscribe to the feed at iTunes and Libsyn.

     

  • Listening and Taking Action

    One way most of us would like to work is to have others listen to our concerns, our requests, our requirements, and then take action to help us. One of the principles of DevOps is just this. We work together and optimize the entire system, increasing the flow of work, and not just trying to ensure our particular task or part is improved. I would hope that most of us would actually take time to listen, evaluate what we hear, and then move forward in a way that is a good decision for both parties. We certainly might debate about what action makes sense, but I would hope we could some to some consensus and decision.

    Microsoft is listening and responding as well. They aren’t building SQL Server based on everything we file on Connect or complain about, but certainly they are listening to some of our concerns and requests. There is a good post that look sat some of the community driven enhancements, which are being included into SQL Server 2017. These are different customer and community requests that were given some attention and added to SQL Server 2017.

    These don’t seem like big changes to me, but as I read through them, a few seem to go quite deep into the engine, and I’m sure there was quite a bit of testing to get these completed. You can test them in SQL Server 2017 today, helping to ensure they work correctly in the final product. Some of these will change the way you run backups or diagnose issues, perhaps even enough to consider an upgrade.

    I especially like that performance of smaller databases is addressed with backup improvements. I would still guess that most of the SQL Server databases out there are smaller than 100GB, maybe substantially smaller, and while we may consolidate and change hardware, we need these systems to perform well. The large, 100TB database changes are nice, and I know some customers need these improvements, but most of us don’t. Even though the percentage of people with 1TB systems grows regularly, it’s still a minority, so kudos to Microsoft for doing some work here.

    Not every highly rated Connect item is addressed. The string or binary data truncated message isn’t changed, and that’s been highly rated for years. However, the top JSON request made it into SQL Server 2016, and there are other items in the most voted on list that haven’t been addressed. I understand, though I don’t always like the way Microsoft looks at the product. I can relate their decisions to my own when building software, realizing that the customer doesn’t always have the best view of what makes sense for commercial viability. However, I’d also like to see the platform continue to evolve and make development and administration easier for all of us.

    I’ll keep voting on, and creating Connect requests as I see a need, and I’d encourage you to do the same. Think about what you are really asking for and decide if it makes sense for large numbers of people, but continue to participate and let Microsoft know what changes are needed. Your voice can make a difference, so please use it in a constructive and positive way.

    Steve Jones