Live data from Hacker News

Big data is dead (2023)

motherduck.com

341–350 of 475 posts

Re: Big data is dead (2023)

#341
post #266
post #209

Earlier quoted context omitted.

FWIW, it's a 2.5 second extra to say "Although you don't need big data, but if you insist, ..." and gimme the hadoop answer.

Sure, but as you said yourself: it's a trick question. How often does the employee have to answer trick questions without having any time to think in the actual job? As an interviewer, why not asking: "how would you do that in a setup that doesn't have much data and doesn't need to scale, and then how would you do it if it had a ton of data and a big need to scale?". There is no trick here, do you feel you lose infor…

Once had a coworker write a long proposal to rewrite some big old application from Python to Go. I threw in a single comment: why don't we use the existing code as a separate executable?

Turns out he was laid off and my suggestion was used.

(Okay, I'm being silly, the layoff was a coincidence)

Re: Big data is dead (2023)

#342
post #266
post #209

Earlier quoted context omitted.

FWIW, it's a 2.5 second extra to say "Although you don't need big data, but if you insist, ..." and gimme the hadoop answer.

Sure, but as you said yourself: it's a trick question. How often does the employee have to answer trick questions without having any time to think in the actual job? As an interviewer, why not asking: "how would you do that in a setup that doesn't have much data and doesn't need to scale, and then how would you do it if it had a ton of data and a big need to scale?". There is no trick here, do you feel you lose infor…

because the interview is supposed to ask same questions as real job, and in real job there are rarely big hints like you are describing.

On the other hand, "hey I have 6TiB data, please prepare to analyze it, feel free to ask any questions for clarification but I may not know the answers" is much more representative of a real-life task.

Re: Big data is dead (2023)

#343
post #328
post #320

Earlier quoted context omitted.

Trick questions (although not known as such at the time) are the basis of most of the work we do? XY problem is a thing for a reason, and I cannot count the number of times my teams and I have ratholed on something complex only to realize we were solving for the wrong problem, i.e. A trick question. As a sibling puts it though, it's a matter of level. Senior/staff and above? Yeah, that's mostly what you do. Lower tha…

> are the basis of most of the work we do? I don't know about you, but in my work, I always have more than 3 seconds to find a solution. I can slowly think about the problem, sleep on it, read about it, try stuff, think about it while running, etc. I usually do at least some of those for new problems. Then of course there is a bunch of stuff that is not challenging and for which I can start coding right away. In an i…

If the interviewer expects you to answer entire design question in 3 seconds, that interview is pretty broken. Those questions should take longish time (minutes to tens of minutes), and should let candidate showcase their thought process.

Re: Big data is dead (2023)

#344
post #8

This is not fully correct. Originally big data was defined by 3 dimensions: - Volume (mostly what the author talks about) [solved] - Velocity, how fast data is processed etc [solved, but expensive] - Variety [not solved] Big Data today is not: I don't have enough storage or compute. It is: I don't have enough cognitive capacity to integrate and make sense of it.

>Big Data today is not: I don't have enough storage or compute.

It is for me. Six times per year I go out to the field for two weeks to do data acquisition. In the field we do a dual-aircraft synthetic aperture radar collection over four bands and dual polarities.

That means two aircraft each with one radar system containing eight 20TiB 16-drive RAID-0 SSD storage devices.

We don't usually fill up the RAIDs so we generate about 176TiB of data per day and over the two weeks we do 7 flight, or 1.2PiB per deployment or 7.2PiB per year.

We can only fly every other day because it takes a day between flights to offload the data via fiber onto storage servers that are usually haphazardly crammed into the corner of a hangar next to the apron. It is then duplicated to a second server for safekeeping and at the end of the mission everything is shipped back to our HQ for storage and processing.

The data is valuable, but not "billions" valuable. It is used for resource extraction, mapping, environmental and geodetic research, and other applications (but that's not my department) so we have kept every single byte for since 2008. This is especially useful because as new algorithms are created (not my department) the old data can be reprocessed to the new standard.

Entire nations finally know how many islands they have, how large they are, how their elevations are changing, and how their coasts are being eradicated by sea level change because of our data and if you've ever used a mapping application and flown around a city with 3d buildings that don't look like shit because they were stitched together using AI and photogrammetry, you've used our data too.

We have to use hard drives because SSDs would be space and most certainly cost prohibitive.

We stream 800GiB-2TiB files each representing a complete stripe or circular orbit to GPU-equipped processing servers. Files are incompressible (the cosmic microwave background, the bulk of what we capture, tends to be a little random) and when I started I held on to the delusion that I could halve the infrastructure by writing to tape until I found out that tape capacities were calculated for the storage of gigabyte-sized text files of all zeros (or so it seems) that can be compressed down to nothing.

GPUs are too slow. CPUs are too slow. PCIe busses are too slow. RAM is too slow. My typing speed is too slow. Everything needs to be faster all of the time.

Everything is too slow, too hard, and too small. Hard drives are too small. Tuning the linux kernel and setting up fast and reliable networking to the processing clusters is too hard. Kernel and package updates that aren't even bug fixes but just changes in the way that something works internally that are transparent to all users except for us break things. Networks are too slow. Things exist in this fantasy world where RAM is scarce so out-of-the-box settings are configured to not hog memory for network operations. No. I've got a half a terabyte of RAM in this file server use ALL OF IT to make the network and filesystem go faster, please. Time to spend six hours reading the documentation for every portion of the network stack to increase the I/O to 2024-levels of sanity.

I probably know more about sysctl.conf than almost every other human being on earth.

Distributed persistent object storage systems for people who think they are doing big data but really aren't either completely fall apart under our workload or cost hundreds of millions of dollars-- which we don't have. When I tell all of the distributed filesystem salespeople that our objects are roughly a terabyte in size they stop replying to my emails. More than one vendor has referred me to their intelligence community customer service representative upon reading my requirements. I am not the NSA, buddy, and we don't have NSA money.

Every once in a while we get a new MBA or PMP who read a Bloomberg article about the cloud and asks about moving to AWS or Azure after they see the costs of our on-premises datacenter. When I show them the numbers, in terms of both money and time, they throw up in their mouths and change the subject.

To top it all off all of our vendors are jumping on the AI/cloud bandwagon and discontinuing product lines applicable to us.

And now I've got to compete for GPUs with hedge funds and AI startups trying to figure out how to use a LLM to harvest customer data and use it to show them ads.

I do not have enough storage or compute, and the storage and compute I do have is too slow.

DPUs/IPUs look interesting but fall on their face when an object is larger than a SQL database query or compressed streaming video chunk.

Re: Big data is dead (2023)

#345

Earlier quoted context omitted.

Hes hiring data scientists not building a service though. This might realistically be a one off analysis for those 6tb. At which point you are happy your data scientists has returned statistical information instead of spending another week making sure the pipeline works if someone puts a greek character in a field.

Even if I'm doing a one off, depending on the task it can be easier/faster/more reliable to load 6TiB into a big query table than waiting hours for some task to complete and fiddling with parallelism and memory management. It's a couple hundred bucks a month and $36 to query the entire dataset, after partitioning thats not terrible.

A 6T hard drive and Pandas will cost you a couple hundred bucks, one time purchase, and then last you for years (and several other data analysis jobs). It also doesn't require that you be connected to the Internet, doesn't require that you trust 3rd-party services, and is often faster (even in execution time) than spooling up BigQuery.

You can always save an intermediate data set partitioned and massaged into whatever format makes subsequent queries easy, but that's usually application-dependent, and so you want that control over how you actually store your intermediate results.

Re: Big data is dead (2023)

#346

Earlier quoted context omitted.

I can appreciate the vertical scaling solution, but to be honest, this is the wrong solution for almost all use cases - consumers of the data don't want awk, and even if they did, spooling over 6TB for every kinda of query without partitioning or column storage is gonna be slow on a single cpu - always. I've generally liked BigQuery for this type of stuff - the console interface is good enough for ad-hoc stuff, you c…

I agree with this. BigQuery or AWS s3/Athena. You shouldn't have to set up a cluster for data jobs these days. And it kind of points out the reason for going with a data scientist with the toolset he has in mind instead of optimizing for a commandline/embedded programmer. The tools will evolve in the direction of the data scientist, while the embedded approach is a dead end in lots of ways. You may have outsmarted so…

It is actually pretty easy to do the same type of processing you would do on a cluster with AWS Batch.

Re: Big data is dead (2023)

#347
post #32

When I was hiring data scientists for a previous job, my favorite tricky question was "what stack/architecture would you build" with the somewhat detailed requirements of "6 TiB of data" in sight. I was careful not to require overly complicated sums, I simply said it's MAX 6TiB I patiently listened to all the big query hadoop habla-blabla, even asked questions about the financials (hardware/software/license BOM) and…

That makes total sense if you're archiving the data, but what happens when you want to have 10,000 people have access to read/update the data concurrently. Then you start to need some fairly complex solutions.

Re: Big data is dead (2023)

#348
post #32

When I was hiring data scientists for a previous job, my favorite tricky question was "what stack/architecture would you build" with the somewhat detailed requirements of "6 TiB of data" in sight. I was careful not to require overly complicated sums, I simply said it's MAX 6TiB I patiently listened to all the big query hadoop habla-blabla, even asked questions about the financials (hardware/software/license BOM) and…

Storing 6TB is easy.

Processing and querying it is trickier.

Re: Big data is dead (2023)

#350
post #32

When I was hiring data scientists for a previous job, my favorite tricky question was "what stack/architecture would you build" with the somewhat detailed requirements of "6 TiB of data" in sight. I was careful not to require overly complicated sums, I simply said it's MAX 6TiB I patiently listened to all the big query hadoop habla-blabla, even asked questions about the financials (hardware/software/license BOM) and…

Would probably try https://github.com/pola-rs/polars and go from there lol
Post reply on HN