Live data from Hacker News

Ask HN: How do I improve our data infrastructure?

news.ycombinator.com

51–60 of 110 posts

Re: Ask HN: How do I improve our data infrastructure?

#51
post #33

I don't know your ratio of HDF5 to Parquet files but remember for every GB of parquet you have it will equate to about 10 GB of space needed in CSV or PostgreSQL's internal format. So your data set is probably closer to 1 TB than 100 GB. Storing that data on S3 is probably 50% the price of storing it on EBS and you won't have the durability guarantees of S3 when you're using PostgreSQL on EBS volumes. If you're both…

None of that matters. It's a hundred gigs. You can store it in a textfile and read it in its entirety if you want. It fits in RAM. It is perfectly reasonable to store this in a database. If and when you change your mind about the data format you can just scrap it and start over.

It's 100GB compressed. Parquet does a very good job of compressing most data so that's where the estimate of 10x (so 1TB) uncompressed was mentioned as a rule of thumb.

Parquet also supports much better access mechanisms, like being able to deserialize a single column without having to read in entire rows.

But like you mentioned, 1TB of data in a traditional database isn't that bad.

Re: Ask HN: How do I improve our data infrastructure?

#52
post #28

Earlier quoted context omitted.

I’d contend this personally. You can employ disk, or row compression on PG if you want. Compressed disk will actually make your queries faster. You can use cstore for ORC based column storage with PG if you want. Presumably the cost of a few TB on EBS is the least of your worries. Finally, the time saving of full transactional support and constraints + sql to write etl in will drastically reduce the amount of work ne…

> sql to write etl in will drastically reduce the amount of work needed to write etl. :) My experience with writing an ETL in SQL is that it is almost never, quick, easy, correct or easy to test, and also almost always denormalized, or unconstrained (dimensonal keys which aren't 'real' foreign keys, just numbers so you can parallelize the data inserts and updates without constraint errors). So... your milage may vary…

Well SQL would present the ETL declaratively for one ... whether the output is denormalised or unconstrained has nothing to do with SQL.

Re: Ask HN: How do I improve our data infrastructure?

#54
post #33

Earlier quoted context omitted.

None of that matters. It's a hundred gigs. You can store it in a textfile and read it in its entirety if you want. It fits in RAM. It is perfectly reasonable to store this in a database. If and when you change your mind about the data format you can just scrap it and start over.

It's 100GB compressed. Parquet does a very good job of compressing most data so that's where the estimate of 10x (so 1TB) uncompressed was mentioned as a rule of thumb. Parquet also supports much better access mechanisms, like being able to deserialize a single column without having to read in entire rows. But like you mentioned, 1TB of data in a traditional database isn't that bad.

... also remembering that a traditional dB will typically not store data raw. Row compression is normal and disk compression is normal . The typical column store advantage is block compression, predicate pushdown and column order storage.

Re: Ask HN: How do I improve our data infrastructure?

#55
Hey Remilouf,

I know exactly how you feel. I was put in the same position and ended up spending 2 years trying to clean up the data and set up the warehouse and handle all the requests for exploring the data.

I had a background in AI and was fully blocked on doing anything I wanted.

4 Years later I build a company to make this easy for people.

I would do the following: 1) Setup a Redshift Instance 2) Use Fivetran to Dump all the data into that Redshift cluster. 3) Leverage my startup Narrator.ai to model and use that data.

Now your team can use your modeled data and you have a clean time-series data structure to do the DS algorithms you want.

Reach out and we can talk about this in details ahmed@narrator.ai.

Re: Ask HN: How do I improve our data infrastructure?

#56
post #33

Earlier quoted context omitted.

None of that matters. It's a hundred gigs. You can store it in a textfile and read it in its entirety if you want. It fits in RAM. It is perfectly reasonable to store this in a database. If and when you change your mind about the data format you can just scrap it and start over.

It's 100GB compressed. Parquet does a very good job of compressing most data so that's where the estimate of 10x (so 1TB) uncompressed was mentioned as a rule of thumb. Parquet also supports much better access mechanisms, like being able to deserialize a single column without having to read in entire rows. But like you mentioned, 1TB of data in a traditional database isn't that bad.

you can run sql DB over compressed filesystem, and some DBs allow you to compress tables too

> like being able to deserialize a single column without having to read in entire rows.

and it reads filesystem's whole page anyway

Re: Ask HN: How do I improve our data infrastructure?

#58

It sounds like you already have an idea of what you want to do, but I think you should pause and think more deeply about what you have, vs. what you want. What I would want in your situation is: - All the data in one place. - An easy way to explore the data. - A single source of truth for transformed data. - Metadata to explain the data model (ie. documentation). What you're proposing does some of those things, but i…

[deleted]

Re: Ask HN: How do I improve our data infrastructure?

#59
> I was just hired

[...]

> I was thinking about building a pipeline

[...]

> How do I go about raising awareness?

Don't.

You don't get it yet.

Everything there is there for a reason.

Some of it may be technical reasons, some of it may be delivery reasons, some of it may be people reasons, team reasons, political reasons, etc.

You just landed a sweet perm job in a field you love. Don't ruin it by becoming that cliched new hire that sees all their problems and knows how to make it all better. You may be right. Technically. They may even encourage you.

But you could also be wrong technically. You could step on toes politically and end up sidelined. You could end up biting off more than you can chew and end up becoming responsible for the bigger mess later.

May advice is to stop, take a deep breath, look around, appreciate what you've already achieved by getting there, get to know your colleagues, get to know the company, get to really understand the system so when the next new hire comes in you can explain the reason behind everything (maybe getting to know the detailed history of the system and why it formed the way it did?), and make sure you know absolutely everything you can before changing everything you can.

Yeah, maybe you'll feel some parts of your job suck for a while (I wish this was easier, it's stupid that I have to do all this work to get form A to B when I can see a better way), but if you give yourself more time to learn, you're really doing yourself a favor in the long run.

And you're a perm now, in a big corp, doing data science. Relax, you got it made, right?

So chill out and take a deep breath and enjoy your new workplace and everything about it (not just the stack in front of you), and if you still want to make changes somewhere down the line, start small, bit off a tiny little piece you can chew, and succeed with that small improvement before moving forward with anything more.

Also think of it differently, if you do end up being the one responsible for reinventing the whole stack, then milk that project for everything you can. It's a big corp play so you have to do that in a big corp way. There'll be meetings, committees, decisions, stakeholders, teams formed, responsibilities. You could even parlay this project into some greater responsibility and title for yourself, maybe even use it to boost your career. SO think of it not like you are trying to understand a technical problem, but you are trying to understand a piece of (and through it, the enitrety of), your whole new organization, with all that entails: the people, the team relationships, how decisions get made, etc. So enjoy playing that game, because you are happy to be in a big corp, so the sort of benefits that can bring you is what you want, right?

It's not a startup. And if you feel technically unsatisfied, use the time to learn some new languages or skills, or kick some side projects down the road for your own benefit.

Re: Ask HN: How do I improve our data infrastructure?

#60
Standardize and simplify the raw data. I'm a big fan of external tables to schematize the text files since it makes the raw data available via SQL query without any complex code or pipeline. The database just points to a directory of text files and makes it look like a table. Then I create binary models using regular internal tables if it makes sense...to power a Python analytic for instance where I need a subset of the raw data and I need the performance of the binary engine. This gives you an easy path to use different tools without changing your data lake strategy...the way you store the raw data.

Check out Alation and DataIku for democratizing the data and offering self-service pipelines for data science. Most MPP databases have support for external tables and postgres may even support them as well.

Things can get complex, just make sure that each single point in the pipeline is simple and easy to understand.

Post reply on HN