Voice of the DBA

Author: way0utwest

  • Writing Parquet Files – #SQLNewBlogger

    Recently I’ve been looking at archiving some data at SQL Saturday, possibly querying it, and perhaps building a data warehouse of sorts. The modern view of data warehousing seems to be built on using a Lakehouse architecture where data moves through different phases, but much of the data is stored in text files, often parquet files.

    As a start to this I decided to try and move data to parquet. This post looks at writing parquet files.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    Writing Parquet Files

    In a previous post I looked at reading in JSON data, which is how some of my data is archived. I also talked about importing modules. There is a module, called pyarrow, that allows me to work with various parts of Apache Arrow.

    One of the submodules in pyarrow is the parquet module, which lets me read and write parquet files. So, let’s get those modules.

    import pyarrow as pa
import pyarrow.parquet as pq

    I am giving these show names so I can refer to them in code. Now, let’s skip the code from the previous article and assume I’ve got a dataframe with my sessions in it. How do I get a parquet file?

    Fortunately, I don’t need to know anything about the physical structure, as I can use the write_table() function from the parquet module to do that. I’ll also use the pyarrow.Table.from_pandas() function to get data from the dataframe into this module. This code does that (with some setup for a filename).

        outputFilename = f + '.parquet'
    outputFile = join(outPath, outputFilename)
    pqtable = pa.Table.from_pandas(df)
# Write Arrow Table to Parquet file
    pq.write_table(pqtable, outputFile)

    Note: I don’t know the technical differences between how pandas dataframes and the pyarrow tables work. I found a few notes online and it looks like pyarrow tables can handle more complex data structures.

    Once this code is added to the code from the previous article (it’s already indented), this will write .parquet files to the bronze folder underneath the location from where it is run. In essence, this takes data from the raw folder and writes it to bronze in a new format.

    Summary

    This post shows how to write parquet files out from JSON data. Take the previous article and this one and you can move data from JSON to parquet.

    This code isn’t perfect. In fact, it needs work. I am only moving session data, so only a portion of the JSON data. This code should be enhanced, or the file names changed to reflect that, but for now, this is a quick example of producing parquet data.

    SQL New Blogger

    This post took about 10 minutes to write once I had the code working. In fact, adding these functions to the code from the last article only took a few minutes. I had to debug a few things to get the files into the correct folder, but it took longer to get these words down than get code working.

    Not a lot longer, but longer.

    You can do this. If you want to work in modern technologies, learn them. Learn how to work with parquet, which is being used a lot in data warehousing, and then write about it. Prove you can get things done and your current employer, or your next one, might give you a project to actually do this work.

  • Kubernetes is Cool, But …

    Kubernetes is cool, and I think it’s really useful in helping us scale and manage multiple systems easily in a fault-tolerant way. Actually, I don’t think Kubernetes per se is important itself; more it seems that the idea of some orchestration engine to manage containers and systems is what really matters. As a side note, there are other orchestrators such as Mesos, OpenShift, and Nomad.

    However, do we need to know Kubernetes to use it for databases? This is a data platform newsletter, and most of us work with databases in some way. I do see more databases moving to the cloud, and a few moving to containers. I was thinking about this when I saw a Simple Talk article on Kubernetes for Complete Beginners. It’s a basic article that looks at what the platform consists of, how it works, and how to set up a mini Kubernetes platform on your system. It’s well written and interesting, but …

    Do we need to know anything about it? Are we running databases in containers, or will we? I think it’s possible that we might run any of our databases in containers. They are like lightweight VMs and there isn’t a reason why we wouldn’t run a database in a container. With external storage, of course, which gives you a cluster-like environment where your storage moves to a new node if the first one fails. That’s a good use case. Deploying consistent environments quickly is a good use case. Using Kubernetes to manage the containers is great, but …

    I don’t think we need to know much about Kubernetes. I don’t think most of us should run it and should outsource any container orchestration to the cloud if we decide to implement database containers. These orchestration engines are quite complex today, and there is a lot of expertise needed to manage them. I don’t know that expertise is worth trying to find, train, and retain for most organizations. We should just outsource the container management to someone else.

    We might need to know how we change the configuration of some resources, but that’s minor knowledge, and really, I suspect that outsourced K8S (shorthand for Kubernetes) will have GUI tools that let you easily pick and choose the CPUs, memory, etc. and then an export of the JSON or YAML or whatever is needed for the config. Most of us likely need the skills to export, save (in a VCS) the files, and then submit them to the cluster.

    A few years ago I went through a bunch of courses and reading material on Kubernetes. I set up some small clusters, I experimented with pods, I even was excited to think about managing containers for various services. What I discovered is that Kubernetes is complex, hard, and something I want someone else to run. Once I set up a cluster in Azure I thought I’d never want to do this on-premises again.

    Much like email. I have run email servers, but …

    I’d like to never run one again, which is how I feel about Kubernetes.

    I think containers have proven more complex and harder to work with than many people thought. I know there are plenty of people using them, but it’s a minority. I see many more organizations still building monoliths, or microservices that run as processes, or client-server apps. Not that many people are excited and using containers. That may change, and if you go to the cloud, containers give you portability that many other solutions don’t, so I’d recommend them there. However, they are still a bit immature, and hard to manage. I think it will be a while before we see lots of databases on containers.

    Even if we do, I’m not sure we need to learn Kubernetes as database people.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • A New Word: Flichtish

    flichtish – adj. nervously aware how much of your self-image is based on untested assumptions about yourself – only ever guessing how you’d react to a violent thread, a sudden windfall, a huge responsibility, or being told to do something you knew was wrong..

    I used to think I had all the answers and knew how I’d react to situations or what type of person I was.

    I was a teenager. I think this view is fairly common among teenagers, but also in older people. I see too many people with confidence in how they’d react to an unknown.

    And I see too often they don’t actually react that way. The more self-aware people recognize that their self-image was untested and wrong. The less self-aware people think the situation was an anomaly.

    I know that until I walk a mile in my shoes in some situation, I’m very un-tested. I have a guess as to what my self-image is, but I doubt it is 100% true. As Mike Tyson says, everyone has a plan until they get punched in the mouth. Flichtish is a recognition of that saying.

    From the Dictionary of Obscure Sorrows

  • The Ireland and UK DevOps Roadshow

    We’re taking the roadshow across the water. Hope the plane makes it.

    AUS02544

    The Redgate DevOps Roadshow comes to Ireland and the Northern UK in June. We’ll be in these cities on these dates:

    • June 11 – Dublin (Grant)
    • June 13 – Glasgow (Grant)
    • June 14 – Manchester (Steve)

    We’ll also have one of Redgate’s amazing Solution Engineers, Huxley Kendall. He’ll be there to answer in-depth questions on the products and solutions that Redgate offers.

    This is a great chance to get exposure to the solutions Redgate offers for building and managing your database code, as well as ask questions about the challenges you face and how we might tackle them.

    Register today and join us for a great day in one of these cities.