Voice of the DBA

Category: Editorial

  • Badly Trained AI

    Most of us know that data is being used to make more and more decisions inside of all kinds of organizations from retail giants to banks to sports teams. We are constantly asked, or see reports, of data driven decisions. We often need to show some data that supports and explains the rationale for making some choice. As our populace becomes more data savvy, I expect this trend to continue.

    AI (Artificial Intelligence), and the related Machine Learning (ML), are becoming more and more widely used. From mobile phones to autos to trading systems, we regularly see new “AI capabilities” being added to products and services. No business or industry seems immune, and I’m sure many of you are seeing AI being incorporated or feeling pressure to start using some AI in your work. As you work with AI, or start to, you’ll quickly realize the importance of data in your efforts.

    This is true for the cleanliness of data, but perhaps even more important in the tagging of data sets. As Amazon learned, building an AI or ML system, is hard. They scrapped one system that was being used to rate resumes and help their recruiters sort through the volume of applications they received. Why? Because of bias.

    Apparently the system would downgrade women’s resumes for various reasons. To me, this is a perfect example of a principle I’ve had throughout my career: garbage in garbage out. In this case it’s not necessarily bad data that was the problem, but bad tagging of what was a good and bad resume, probably from the internal prejudices of a few people.

    There will be more dangers as we use ML and AI technologies in our work. It won’t be enough that we clean the raw data for training, but also that we clean and properly manage the tagging of what data sets represent the results we are looking for. Like in much of our software, it’s easy for us to only consider the happy path, to only tag those items we think are good results. That is useful, but we might also be unconsciously tagging other results as bad, which appears to have happened to Amazon.

    We can build systems that do a better, more rational job than most humans, but we need extraordinary care to ensure our training data lacks bias. Unfortunately, most people both think they’re not biased and are unwilling to spend extra resources to deeply examine the data. Two things that worry me about the future of our AI/ML systems that will inform us.

    Steve Jones

  • Republish: MY Data

    As I noted, I’ve been ill. This is being republished to give me another day to get well: MY Data.

  • The Giving Back Workload

    One of the amazing things about the #sqlfamily is that we often help each other in a very giving way. Certainly other technical communities have lots of sharing and helping, though often with more of an RTFM attitude. I don’t know how well many other industries share information with each other, but the nature of being connected with technology through blogs, free events, #sqlhelp and more certainly seems to facilitate lots of sharing.

    When SQL Saturday first started, Andy Warren and I worried that we would struggle to get speakers to donate time for a number of free events. The first year we had discussions about how to find speakers if we were to get 10 events scheduled in a year. That proved to be a non issue. It’s amazing to think that these days we have 6 or 7 events on a single date, and I’m looking forward to the time when there are actually 10 events on one Saturday.

    Our speakers donate a lot of their own time and money to give back to others. In 2018, I’m particularly impressed by Kevin Feasel, who I was lucky enough to see at a number of events and even share a bus ride on a double decker in Cambridge. I’ve also met a number of volunteers and attendees who have had similar schedules during a year or two, where they have lots of excitement. What often happens is that after a few years, they scale back, some of them even giving up on all of their efforts.

    It’s wonderful that people give back, but I do worry about sustainability, both for events and individuals. Andy Warren wrote recently about volunteer time and the load in life. I haven’t tracked my time, but I know that it sometimes is quite a load. While Redgate often covers my expenses, the time away from home to speak at events comes out of family time as I still need to work a normal week when I’m speaking on Saturday.

    I do think it’s important to volunteer and give back to others. Help those getting started, those less fortunate, or those that are inspired to move forward in life. There’s a time and place for all of us, and I do hope all of you think about where and how you can help others, either in this field or in other ways. If not now, then at some point in the future.

    Time is a valuable resource, and while I think Andy underestimates the amount spent on his endeavors, I think it’s good that after many years of helping others, he is trying to quantify the time spend and perhaps inspire some of you to think about where you might do the same. 50 hours a year is both a lot and a little. What are your plans for the coming year and could you spare 50 hours to help others? Leave a comment here, and let Andy know what you think of his plans.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Lack of Memory

    I was reading Brent’s look at “normal memory” for his SQL ConstantCare® clients. It’s a look at some stats from quite a few servers that customers have set up and he is monitoring. Since most of us only have a limited set of instances to examine, it’s nice to see what a wide variety of installs are using. Even though this doesn’t necessarily mean we should change anything in our environment, it does help me to understand some general trends, and perhaps think about how to recommend settings for new installations.

    When we build a server, we expect it to work a certain way. Over time, we are almost always adding data to the system, but often we don’t add more RAM. This would be like buying a vehicle and loading it up with supplies you need for work. If the amount of supplies kept growing, would you keep piling them on or buy/rent/borrow a bigger vehicle? Some would, some wouldn’t.  I’m always amazed by how far people will push a situation, especially when fairly small and inexpensive changes might make a big difference.

    Data size isn’t always a good indicator of how much memory you should allocate, but it can be. Certainly the more data we query in a workload, the more memory makes a difference. Bad code is more likely to surface issues, but memory is often cheaper than paying developers, or usually, finding and training developers to write better code. For a DBA, this might be one of the relatively few differences we can make in the short term that has a far reaching effect. Adding memory might cover up some poor coding and speed up the experience for clients in the short term. In the long term, things will likely tip over again.

    If you manage an instance, you can’t usually change code, and it can be hard to get developers to prioritize changing existing code. Most developers are pressured to move forward with new work, not refactor old work. One of the reasons I like moving clients to a database DevOps flow is that DBAs with query tuning skills can spend more time tuning some queries and giving code to developers. It’s much easier to get developers to fix bad code if you give them better code than ask them to find time to rewrite things.

    Getting the best performance out of your database server often a balancing act among various choices that each only solve a portion of the problem. Don’t be hesitant about asking for more memory over time, but also be careful that you don’t just depend on this one technique to reduce the number of customer complaints. Learn to write better code and teach others to do the same.

    Steve Jones

    The Voice of the DBA Podcast

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