Hello everybody. I'm Olimpiu Pop, technologist and probably I can call myself a tech journalist as well. And I have in front of me Andrew Lamb, another technologist that knows at least two very complicated things on my side.

And those are databases or data systems, probably to be more correct, and the other one is C language.

Well, Andrew, I think it's better for you to introduce yourself, please.

>> Hello. Yeah, thank you. I'm very excited to be here.

I am a staff engineer currently at FlexData but my and my in that context I work a lot on databases, specifically the analytic database stack and I'm sure a lot of stuff we'll talk about later.

My background was basically as a low-level systems programmer, so that means like databases and compilers kind of stuff. I worked for many years at a company called Vertica where I worked at Oracle.

Vertica was one of the sort of first wave of commercializations of these sort of shared-nothing distributed database architectures.

And then I've worked in various other sort of engineering and data platform teams. And now I work on FlexData and the core engine that drives that, including the SQL engine, which is built on top of the big pile of open source, including Apache DataFusion, Apache Arrow, where I'm the PMC.

I'm on the PMC for both of those projects and I am down to the guts sort of on a day-to-day basis.

So I really love that stuff. >> Thank you. Thank you for loving it.

because then we don't have to love it and just play with it. On top of that, we had other conversations and one of them was together with Felix, which unfortunately cannot join us.

And what we spoke is that on other parts of the programming universe, we can take bits and pieces.

We have multiple frameworks, we have libraries that we can just place them together and have and have a final system. But until not long ago, that wasn't the case for data systems.

And that sort of was the conversation that we started as a trio, that Kafka played a role as one of the parts, at least for ingestion systems for data systems.

And then we had different engines like RocksDB or DB.

But when you rebuilt InfluxDB with its third version, you made a couple of changes.

One of them was using another programming language, and that's Rust, as we spoke about. And the other one, you coined the term FDAP.

Can you please elaborate about what's FDAP, or should we add the I as well or not just yet?

Yeah. Yeah. I, I for Iceberg probably. Yeah. So the FDAP stack, I want to say I wrote the blog post, but like really it was the CEO and CTO of Influx that came up with that, right?

So Paul Dix is the CTO of Influx, and he saw early on that perhaps partly because he wanted to go write yet another version of the database, right?

And the CEO was like, "How are we ever going to possibly afford that?

" Because it's a, it's a big expensive undertaking, which they knew firsthand because they'd just gone through it, right?

And now they want to sort of re-rework everything from the ground up.

Paul's vision at that point in the pitch was, we don't have to rebuild everything from the ground up because at this by this point, uh, people have done sort of built these analytic systems and done it enough that the common patterns are emerging.

And so at that point, he identified the technologies specifically Flight Arrow, Apache Arrow Flight, which is part of Arrow, DataFusion, and Parquet as technologies that you could build a whole new sort of time series database on top of that without having to reinvent everything, right?

And Paul was definitely on the earlier side of that trend, but the idea was rather than have to build a database from scratch, which by the way, I did it vertically, I saw it was like a five-year endeavor with like 20 engineers, right?

Like it's a it's a major investment, like good engineers too, like PhDs database things.

But since that pattern has now been implemented so many times, the thesis was we'd be able to we understood where the boundaries were and we can really focus people's efforts together to not have to reinvent the same thing over and over again.

>> Okay. So because you made a mistake and told me that you already have the experience of building everything from scratch, let's take a step backwards then and just maybe think about it.

What are the conceptual pieces that usually will come and we'll just say that these are the building blocks for a normal data system.

And then, yeah, go back and map them and see how it actually moves from, I don't know, ingestion via the memory model and then on the file system and then back again.

So, yeah, yeah, yeah, you know, and so I'm going to talk from the perspective of a database implementer, right?

Like someone who's building one of these components that you then build an actual data platform on top of, right? So I'm going to talk about how you would implement a database and depending on you as a user, when you're actually trying to assemble this into some either data platform or higher level application, there's often you would use pre-assembled, um, components, right?

So I'm going to talk about how you would implement stuff like InfluxDB, not how you application on top of, or likewise with Cascade, whatever.

And actually, some, you know, the line there is always a little blurry and I think it's getting more blurry as we go in the sense that it's easier to decide where exactly where you want to work on.

Maybe we'll talk about that later in the call.

But at a high level, like when you're going to build one of these high-performance analytic systems, sort of the best practice in the last probably 20 years came out of the research world is a very simple concept, which is you store it in columns.

Right? Like which basically means for this is mostly in the context of storing tabular data, right?

But it the same concepts apply to other forms.

So storing relational tables, you can either, like, you can either store all the row, uh, the values in each row next to each other, if you think about it, or you can store all the values in each column next to each other in memory.

And it turns out for analytic processing, for a lot of reasons, doing the column store is a much better choice, specifically because it can take advantage of modern hardware like vectorized execution, right, which does phenomenally well when you just have the same uh operations apply to a lot of different data items versus row-oriented, you kind of like, I would have to be continually changing what application.

So there there's basically a shift started probably 20, 30 years ago, starting in academia and moving into like really multi-layer technology databases.

And so these days, if you're going to go build a new database system, to your point, you would typically need to have some way to get the data from your client and you have to represent it in memory somehow.

And in particular, you have to be able to do operations on it quickly. The other thing you need to do is, of course, so that's what Apache Arrow is basically designed for.

And I wouldn't say Apache Arrow is really like earth-shattering in terms of its technical content, right?

Like those ideas have been around. There's really not that many ways to represent an array of 64-bit integers right in memory.

But what's important is that everyone agrees on how, you know, how it looks, how to pass the metadata around, how you like represent nulls, a null mask or ability mask doesn't really matter, but it matters a lot that everyone agrees on what the what the state mask means.

So having like a standardized what I think Arrow's real value was it standardized best practice across sort of column representations.

>> Okay. So let me let me just stop you here to just translate it for a 5-year-old and see if I got it correctly.

So no worries, no worries. That's why we we're here. So what you're saying is that in the last 20 to 30 years we had a transition from the normal way how we thought about databases to looking especially in terms of analytics to just look at them in terms of columnar data because that made sense also in terms of extractions but also in the way how we can store it and how the new hardware behaves lately as it uh it would be much much more efficient.

Right. So after that what you mentioned is that Apache Arrow takes care of that memory model nothing earth-shattering but it just takes care of a couple of it depends because we love to use it depends on multiple levels but from that point of view what it actually does it just comes sets a standard and then all the all the things that you normally want to think what would be the the sequence of data data types and probably the way how we store it, how we represent null or other other aspects are now standard and then we can build on top of this attraction and that will be easy to do.

So with each iteration, it will just improve and then everybody will use the same standard.

Yeah. Yeah. Yeah. Yeah. That's that's a very good summary.

Great. Thank you, Andrew. And I just wanted to, like, maybe I can like take a step back just a little higher to try to describe why the transition to column stores happened, right?

Like at a really high level, like philosophically, when computers and databases were first coming around in the '60s and '70s, there wasn't that much data in them, right?

Like, not a whole lot of the world had been digitized.

We we didn't weren't creating massive amounts of digital information at that point.

And so the speed of getting data in and getting data out was was typically happening at, you know, individual like was based on human actions, right?

Like you did something to your bank account, and so that fundamentally sort of, you know, like, that's as human scale both reading and writing.

Then what happened in the, you know, '90s, 2000s, is an increasing amount of both our lives and also all the computing infrastructure became digitized.

And so it generated huge, huge amounts of data, right? That that didn't just come from human scale systems, it came from machine scale systems.

So the volumes of data were much, much higher and we needed new techniques to keep up with the increasing data lines.

So that's around the time when columnar technology really took off because we needed better ways to basically handle the ever-increasing data lines.

And now, of course, there's some theories we talk about to move into AI, but that's that's maybe a different, uh, a different conversation.

So anyway, so Arrow is the in-memory representation for any database. You need a way to actually manipulate the data once you get in there, right?

To actually compute the calculations people ask for. And you kind of touched on it, but I wanted to highlight again.

Arrow really has two things that are going for it. One is that it's standard. So, so what that means is you can pass data without having to translate the format from things like data frames to a database to another database to, you know, like basically it lets you easily pass data between systems without paying the serialization cost of having to translate it back and forth to different formats, which is actually I think the original reason why Arrow was was founded.

But I think a hugely important other aspect that we talked about that I that that I think is really critical for system design is you now you when you're designing this no longer have to go through the trouble of like deciding exactly how you're going to represent timestamps and where the time zones come in and how you're going to convert it and what kind of date you have, like a bunch of this stuff is not impossible to solve, but I'll tell you from experience, it takes a huge amount of time and effort to actually work out all the details.

And so the fact that someone else has done that already just basically accelerates your development cycle a lot.

There's a whole bunch of infrastructural work you just don't have to do because you can just take advantage of what's already there.

And I think that that's pretty huge. >> Okay. So this would be the things that we'll have in the memory.

But usually we call them persistent because they stay somewhere where we can find them afterwards.

>> That's right. >> And that's probably right.

How do they interconnect? How do you make the connection between the two of them?

>> Yeah. So they're different technologies.

They're both columnar technology. I would say Parquet is designed for persisting data. In particular, it has a bunch of encodings and compression so that the data volume on disk that you have to transfer the network is significantly lower.

So in order to process things in memory, right, you have a representation that's convenient to process, but if you want to save that for long-term archival storage or share it with people or store on S3 or whatever, you end up with Parquet.

So it's a columnar file format and it's designed for storing large volumes of data efficiently on disk.

And I think it has two has a couple of benefits over the alternative, right? Like, well, one option is you could build your own whole file format, which you have ultimate freedom, but it's very expensive.

Another classic alternative was CSV files, right?

You just dump a bunch of CSV files. There's a couple of problems with CSV files or JSON files.

Similarly, they're not particularly well compressed. So, they're very space inefficient, both for like your storage cost, but also that the amount of time it takes to transfer.

If you want to read a CSV, it actually takes a lot of effort to extract the data out of the text form into the form that you want to process, right?

Because you have to like parse strings into numbers, which is a very, very expensive operation. And the final thing is it's actually they they don't have type information attached to them, right?

So, so you basically have to when you get a CSV file, you have to figure out is this column full of dates, or maybe it just kind of looks like dates, or maybe they're UUIDs or like so and every system sort of has to do that schema interpretation, schema inference itself.

And of course, they're a little incompatible and so there ends up being a bunch of pain when you when you have to get systems to go.

So, Parquet has its own type system. It's got a very efficient encoding and compression scheme in there.

And now it's a standard also sort of governed by Apache Software Foundation. So you have lots of vendors that support the the file format.

>> Sorry to be tricky, but CSV and JSON are not exactly earth chattering again.

So comparing them to Parquet, I I cannot say that I'm wow, but maybe we can underline one other thing that Parquet has that allows it to to be that that important in the new data data landscape.

What I think it's probably very important is the fact that a lot of other projects have already adopted it.

So that means that most probably you can use it also in terms of interconnectivity across the board in multiple data projects.

Did that make a difference for you while implementing it? What what would be a couple of benefits as you as a provider of databases have with that?

>> That's right. Yeah. So there's there's two primary benefits to to Parquet.

The first is that it's compatible, that you can write a Parquet file and read it with other tools.

It both helps if you want to transfer data, you know, like how do your customers migrate their data in bulk either into or out of your system.

It's very helpful for that, especially so if you don't have to rewrite it internally, you just give them the internal Parquet files was was the theory.

The other major benefit, which goes back to the original discussion, is the amount of effort that's gone into these open source Parquet readers and writers is actually quite high.

And so while if you had your own custom file format, which is what you would typically do actually in a database to your point, right?

Building Modern Databases with the FDAP Stack • Andrew Lamb & Olimpiu Pop • GOTO 2025

GOTO gathers the brightest minds in the software community to help developers tackle projects today, plan for tomorrow and create a better future.

Learn from thought leaders and innovators with top-rated videos released daily, and at our year-round conferences, masterclasses and meetups.

Get started: https://gotopia.tech

GOTO is produced by Trifork, a leading full-service supplier of high-quality, custom-built applications and end-to-end solutions.

GOTO YouTube Channel Code of Conduct: https://blog.gotocon.com/yt-coc


GOTO Conferences

FDAP 스택(Flight, DataFusion, Arrow, Parquet)은 데이터베이스를 처음부터 재구축할 필요 없이 새로운 데이터 시스템을 구축할 수 있게 하는 오픈 소스 기술 스택입니다.

컬럼 기반 데이터 스토리지(Parquet)와 인메모리 데이터 표현(Apache Arrow)은 특히 분석 처리와 벡터화된 실행을 위해 현대 데이터 시스템에서 효율성과 성능을 크게 향상시킵니다.

Apache Iceberg는 객체 저장소에 저장된 대량의 Parquet 파일을 여러 시스템이 표준화된 방식으로 읽고 쓸 수 있도록 하여 ETL 프로세스 없이 데이터 공유 및 상호 운용성을 가능하게 합니다.

FlexData의 스태프 엔지니어인 앤드루 램과 기술 저널리스트 올림피우 팝은 현대 데이터베이스, 특히 분석 데이터베이스 스택에 대한 심층적인 논의를 시작했습니다. 이들은 특히 C언어와 **데이터 시스템에 대한 앤드루의 깊은 지식**에 초점을 맞추며 대화를 시작했습니다.

앤드루의 경력은 로우 레벨 시스템 프로그래밍에 뿌리를 두고 있으며, Vertica와 Oracle 같은 회사에서 데이터베이스와 컴파일러를 다루며 오랜 시간을 보냈습니다. 그는 현재 FlexData에서 Apache DataFusion과 Apache Arrow를 포함한 **오픈 소스 기반의 핵심 엔진과 SQL 엔진을 개발하는 데 참여**하고 있습니다.

데이터 시스템 개발의 진화: FDAP 스택의 등장

과거에는 데이터 시스템을 처음부터 구축해야 했지만, 현대 프로그래밍 세계에서는 프레임워크와 라이브러리를 결합하여 시스템을 만들 수 있게 되었습니다. 이러한 변화는 **InfluxDB의 세 번째 버전 재구축** 과정에서 특히 두드러졌는데, Rust 언어와 함께 FDAP 스택이라는 새로운 개념이 도입되었습니다.

FDAP는 Flight, DataFusion, Arrow, Parquet의 약자이며, Influx의 CTO 폴 딕스가 고안했습니다. 이 스택의 핵심 비전은 **더 이상 모든 것을 처음부터 재구축할 필요 없이** 기존의 오픈 소스 구성 요소를 활용하여 새로운 시계열 데이터베이스를 만들 수 있다는 것입니다.

과거에는 데이터베이스 구축에 수십 명의 엔지니어가 수년이 걸리는 막대한 투자가 필요했지만, 이제는 **공통 패턴이 충분히 나타나 사람들의 노력을 집중할 수 있게 되었습니다.** 이는 재발명 대신 기존의 경계를 이해하고 활용하는 데 중점을 둡니다.

FDAP 구성 요소 이해: 컬럼형 스토리지와 Apache Arrow

고성능 분석 시스템을 구축하는 데 있어 지난 20년간 가장 효과적인 방법은 **컬럼형 스토리지**를 사용하는 것입니다. 이는 특히 테이블 형식 데이터를 저장할 때 각 열의 모든 값을 메모리에 함께 저장하여 분석 처리, 특히 벡터화된 실행에서 훨씬 더 효율적입니다.

Apache Arrow는 인메모리 데이터 표현을 위한 표준을 제공합니다. 이는 획기적인 기술이라기보다는 **컬럼형 표현 전반에 걸쳐 모범 사례를 표준화**하여, 데이터가 메모리에서 어떻게 표현되고, 메타데이터가 어떻게 전달되며, null 값이 어떻게 처리되는지에 대한 공통적인 합의를 가능하게 합니다.

Arrow는 데이터를 한 시스템에서 다른 시스템으로 전달할 때 형식 변환에 드는 직렬화 비용 없이 효율적으로 데이터를 전달할 수 있게 합니다. 이는 **다양한 시스템 간의 상호운용성을 크게 향상**시키며, 날짜/시간 및 기타 데이터 유형의 복잡한 표현 문제를 해결하여 개발 주기를 단축시킵니다.

Parquet은 디스크에 데이터를 영구적으로 저장하기 위해 설계된 컬럼 기반 파일 형식입니다. 특히 **높은 압축률과 효율적인 인코딩 기능**을 제공하여 디스크 공간 사용량과 네트워크 전송량을 크게 줄여줍니다.

Parquet은 CSV나 JSON 파일과 비교했을 때 여러 장점을 가집니다. CSV와 JSON은 압축률이 낮고, 텍스트 파싱에 많은 비용이 들며, **타입 정보가 연결되어 있지 않아 스키마 추론에 어려움**이 있습니다. 반면 Parquet은 자체 타입 시스템을 가지고 있어 이러한 문제를 해결합니다.

Parquet의 중요한 이점 중 하나는 **호환성**입니다. Parquet 파일을 다른 도구로 작성하고 읽을 수 있으므로 데이터 마이그레이션 및 시스템 간 데이터 전송에 매우 유용합니다. 또한, 많은 오픈 소스 프로젝트가 Parquet 리더 및 라이터 개발에 기여하여, 독점 파일 형식에 비해 개발 및 유지보수 비용을 절감합니다.

FDAP 구성 요소 이해: DataFusion 및 Flight

FDAP 스택의 DataFusion은 **쿼리 엔진**을 담당합니다. DataFusion은 Parquet 파일이나 Arrow 레코드 배치와 같은 다양한 데이터 소스를 기반으로 완전한 최적화 기능과 함께 SQL 쿼리를 계획하고 실행할 수 있습니다. 이는 사람들이 SQL을 위한 빠르고 벡터화된 실행 엔진을 구현하는 방법을 이미 알고 있다는 또 다른 예시입니다.

Flight는 **네트워크 프로토콜**로, 네트워크를 통해 대량의 컬럼형 데이터를 효율적으로 전송하기 위해 설계되었습니다. 이는 분산 데이터베이스 아키텍처에서 데이터를 빠르게 전송하는 데 핵심적인 역할을 하며, InfluxDB 3와 같은 분산 시스템이 다른 프로토콜을 재구현할 필요 없이 기존 구성 요소를 재활용할 수 있게 합니다.

Influx는 이러한 오픈 소스 구성 요소를 사용할 뿐만 아니라 적극적으로 기여하고 있습니다. 이는 **커뮤니티를 강화하여 독자적으로 감당하기 어려운 기술에 접근**하고, 공동 작업을 통해 기술 발전을 가속화하는 이점을 제공합니다.

ACID 속성, CAP 정리 및 시계열 데이터베이스의 특성

데이터베이스 세계에서 ACID 속성(원자성, 일관성, 고립성, 지속성)은 관계형 데이터베이스의 중요성을 강조합니다. 그러나 분산 시스템의 CAP 정리(일관성, 가용성, 분할 허용성)는 세 가지 중 두 가지를 선택해야 한다고 명시하며, **다양한 사용 사례에 따라 다른 절충안이 필요**함을 시사합니다.

시계열 데이터베이스는 특정 사용 사례에 최적화된 데이터베이스 유형 중 하나로, 전통적인 데이터베이스와는 몇 가지 주요 차이점이 있습니다. 가장 큰 차이점은 **데이터를 입력하기 전에 스키마를 미리 정의할 필요가 없다**는 점입니다. 이는 유연성을 높여 시계열 데이터에 더 적합합니다.

또한, 시계열 데이터는 시간이 지남에 따라 가치가 감소하는 경향이 있습니다. 따라서 시계열 데이터베이스는 **데이터 수명 주기 관리에 중점을 두어**, 데이터를 효율적으로 구성하고 쿼리할 뿐만 아니라, 오래된 데이터를 빠르게 시스템에서 제거하여 비용을 절감하는 기능을 제공합니다.

미래의 데이터 관리: Apache Iceberg

Apache Iceberg는 객체 저장소에 저장된 Parquet 파일과 같은 데이터를 여러 시스템이 효율적으로 읽고 쓸 수 있도록 표준화하려는 시도입니다. 이는 **데이터를 S3와 같은 저렴하고 내구성이 뛰어난 객체 저장소에 영구적으로 저장**하는 아키텍처 패턴이 주를 이루면서 더욱 중요해졌습니다.

Iceberg의 비전은 데이터를 중앙 집중식으로 관리하고 개방형 파일 형식으로 저장하여, **데이터 파이프라인과 ETL 프로세스 없이도 다양한 특화된 데이터 처리 도구가 동일한 데이터에 액세스**할 수 있도록 하는 것입니다. 이는 데이터 시스템 간의 상호 운용성을 크게 개선할 잠재력을 가지고 있습니다.

FDAP 스택을 구성하는 요소는 무엇이며, 각 요소가 현대 데이터베이스 아키텍처에서 어떤 역할을 하는지 설명해 주십시오.

데이터 저장 방식이 로우 중심에서 컬럼형으로 전환된 주요 이유와 이로 인한 이점은 무엇입니까?

Apache Arrow와 Parquet이 각각 메모리 내 데이터 처리와 영구 저장이라는 측면에서 데이터 시스템에 어떤 가치를 제공하는지 비교해 주십시오.

시계열 데이터베이스가 기존 관계형 데이터베이스와 구별되는 주요 특징과 장점은 무엇입니까?

Apache Iceberg가 미래의 데이터 관리 및 공유 방식에 어떤 변화를 가져올 것으로 예상하며, ETL 파이프라인과 어떤 관계를 가집니까?

안녕하세요, 여러분. 저는 올림피우 팝이고요, 기술자이자 아마도 스스로를 기술 저널리스트라고도 부를 수 있을 것 같습니다. 그리고 제 앞에는 앤드루 램이 있습니다. 또 다른 기술 전문가인데, 적어도 제가 모르는 두 가지 매우 복잡한 것들을 알고 있죠.

그것들은 데이터베이스 또는 데이터 시스템이고요, 좀 더 정확하게 말하자면, 다른 하나는 C언어입니다.

앤드루, 당신 소개를 하는 게 더 좋을 것 같아요. 부탁합니다.

네, 안녕하세요. 감사합니다. 이렇게 함께하게 되어 매우 기쁩니다.

저는 현재 FlexData의 스태프 엔지니어입니다. 그런 맥락에서 데이터베이스, 특히 분석 데이터베이스 스택에 대한 작업을 많이 하고 있으며, 이에 대해서는 나중에 많은 이야기를 나누게 될 것입니다.

제 배경은 기본적으로 로우 레벨 시스템 프로그래머였습니다. 즉, 데이터베이스나 컴파일러 같은 것들이죠. 저는 Vertica라는 회사에서 오랫동안 일했고, Oracle에서도 일했습니다.

Vertica는 일종의 공유되지 않는 분산 데이터베이스 아키텍처의 첫 번째 상용화 물결 중 하나였습니다.

그리고 나서 저는 다양한 다른 엔지니어링 및 데이터 플랫폼 팀에서 일했습니다. 그리고 지금은 FlexData와 그 핵심 엔진, 그리고 SQL 엔진을 포함하여 Apache DataFusion, Apache Arrow를 포함한 대규모 오픈 소스 기반으로 구축된 엔진을 개발하고 있습니다. 저는 PMC입니다.

저는 이 두 프로젝트의 PMC를 맡고 있으며, 매일매일 핵심적인 부분까지 직접 다루고 있습니다.

저는 정말 그런 것들을 좋아합니다. 감사합니다. 좋아해 주셔서 감사합니다.

왜냐하면 저희는 그걸 좋아할 필요 없이 그냥 가지고 놀면 되니까요. 게다가, 우리는 다른 대화들도 나눴는데, 그중 하나는 불행히도 함께하지 못한 펠릭스와 함께였습니다.

그리고 우리가 이야기했던 것은 프로그래밍 세계의 다른 부분에서는 비트와 조각들을 가져올 수 있다는 것입니다.

여러 프레임워크가 있고, 라이브러리들을 함께 배치해서 최종 시스템을 만들 수 있습니다. 하지만 얼마 전까지만 해도 데이터 시스템에서는 그렇지 못했습니다.

그리고 그것이 우리가 3인조로 시작했던 대화였습니다. Kafka는 데이터 시스템의 수집 시스템을 위한 부분 중 하나로서 역할을 했습니다.

그리고 RocksDB나 DB와 같은 다양한 엔진이 있었습니다.

하지만 InfluxDB를 세 번째 버전으로 재구축했을 때, 몇 가지 변경 사항을 적용했습니다.

그중 하나는 다른 프로그래밍 언어인 Rust를 사용하고 있었는데, 우리가 이야기했듯이요. 그리고 다른 하나는 FDAP라는 용어를 만드셨죠.

FDAP가 무엇인지 자세히 설명해 주시겠어요? 아니면 아직 I를 추가하지 말아야 할까요?

네, I는 아마 Iceberg를 의미할 거예요. FDAP 스택에 대해 말하고 싶은데, 제가 블로그 게시물을 작성했다고 말하고 싶지만, 사실 Influx의 CEO와 CTO가 생각해 낸 거죠?

폴 딕스는 Influx의 CTO인데, 부분적으로는 그가 또 다른 버전의 데이터베이스를 작성하고 싶어 했기 때문에 일찍이 그걸 알아차렸을 거예요, 그렇죠?

그러자 CEO는 "우리가 그걸 감당할 수 있을까?"라고 말했죠.

왜냐하면 그들은 이미 직접 겪어봤기 때문에 그게 얼마나 크고 비용이 많이 드는 일인지 잘 알고 있었기 때문이죠, 그렇죠?

그리고 이제 그들은 모든 것을 처음부터 다시 만들고 싶어 하는 거죠.

그 시점에서 폴의 비전은, 처음부터 모든 것을 다시 만들 필요가 없다는 것이었어요. 왜냐하면 이 시점까지 사람들은 이러한 분석 시스템을 구축하고 공통 패턴이 나타날 정도로 충분히 해왔기 때문이죠.

그래서 그 시점에서 그는 구체적으로 Flight Arrow, Apache Arrow Flight(Arrow의 일부), DataFusion, Parquet을 모든 것을 재발명할 필요 없이 새로운 종류의 시계열 데이터베이스를 구축할 수 있는 기술로 식별했습니다.

그리고 폴은 확실히 그 추세의 초기 단계에 있었지만, 아이디어는 데이터베이스를 처음부터 구축할 필요가 없다는 것이었습니다. 그런데 제가 수직적으로 해봤는데, 20명의 엔지니어가 5년 동안 노력해야 하는 일이었어요, 그렇죠?

그건 엄청난 투자예요. 박사 학위를 가진 데이터베이스 전문가 같은 좋은 엔지니어가 필요하죠.

하지만 그 패턴이 이제 여러 번 구현되었기 때문에, 우리는 경계가 어디에 있는지 이해하고 사람들이 같은 것을 반복해서 재발명하지 않도록 노력에 집중할 수 있다는 것이 논제였습니다.

좋아요. 실수를 해서 처음부터 모든 것을 구축한 경험이 있다고 말씀하셨으니, 한 단계 뒤로 물러서서 그냥 생각해 봅시다.

일반적인 데이터 시스템의 구성 요소라고 할 수 있는 개념적 요소는 무엇이 있을까요?

그다음 다시 돌아가서 매핑하고 실제로 어떻게 움직이는지 확인해 보세요. 예를 들어 메모리 모델을 통한 수집, 파일 시스템, 다시 돌아오는 과정 등을요.

네, 아시다시피 데이터베이스 구현자의 관점에서 이야기할 겁니다.

실제 데이터 플랫폼을 구축하는 데 사용되는 구성 요소 중 하나를 구축하는 사람처럼요. 데이터베이스를 구현하는 방법에 대해 이야기할 것이고, 사용자인 여러분이 이것을 데이터 플랫폼이나 더 높은 수준의 애플리케이션으로 조립하려고 할 때 사전 조립된 구성 요소를 사용하는 경우가 많을 겁니다.

따라서 InfluxDB와 같은 것을 구현하는 방법에 대해 이야기할 것입니다. 그 위에 애플리케이션을 구축하는 방법이 아니라요. Cascade도 마찬가지고요.

사실 그 경계선은 항상 약간 모호하고, 어디에서 작업하고 싶은지 결정하기가 더 쉬워짐에 따라 점점 더 모호해지고 있다고 생각합니다.

이건 나중에 다시 이야기할 수 있을 것 같네요.

하지만 높은 수준에서 이러한 고성능 분석 시스템을 구축할 때 지난 20년 동안 연구 분야에서 나온 가장 좋은 방법은 매우 간단한 개념인데, 바로 열에 저장하는 것입니다.

대부분 테이블 형식 데이터를 저장하는 맥락에서 그렇습니다.

하지만 동일한 개념이 다른 형태에도 적용됩니다.

관계형 테이블을 저장할 때 각 행의 모든 값을 서로 옆에 저장하거나, 각 열의 모든 값을 메모리에서 서로 옆에 저장할 수 있습니다.

분석 처리의 경우 여러 가지 이유로 컬럼 스토어가 훨씬 더 나은 선택이라는 것이 밝혀졌습니다. 특히 벡터화된 실행과 같은 최신 하드웨어를 활용할 수 있기 때문입니다. 벡터화된 실행은 동일한 작업이 많은 다른 데이터 항목에 적용될 때 매우 잘 작동합니다. 반면 행 중심적인 방식은 계속해서 애플리케이션을 변경해야 합니다.

따라서 20~30년 전에 학계에서 시작하여 다층 기술 데이터베이스로 이동하는 변화가 있었습니다.

그래서 요즘에는 새로운 데이터베이스 시스템을 구축하려면 클라이언트에서 데이터를 가져와서 메모리에 어떤 식으로든 표현해야 합니다.

특히 데이터를 빠르게 처리할 수 있어야 합니다. 물론 또 해야 할 일은, 아파치 애로우가 기본적으로 이러한 용도로 설계되었다는 것입니다.

아파치 애로우가 기술적인 내용 면에서 획기적이라고는 할 수 없죠?

이러한 아이디어는 이미 존재했습니다. 메모리에 64비트 정수 배열을 표현하는 방법은 그리 많지 않습니다.

하지만 중요한 것은 모든 사람이 그 모양, 메타데이터 전달 방법, null 표현 방법(null 마스크 또는 가용성 마스크)에 대해 동의하는 것입니다. 어떤 마스크를 사용할지는 중요하지 않지만, 모든 사람이 상태 마스크의 의미에 대해 동의하는 것이 중요합니다.

애로우의 진정한 가치는 컬럼 표현 전반에 걸쳐 모범 사례를 표준화했다는 점입니다.

>> 좋습니다. 잠시 멈춰서 5살 아이에게 설명하듯이 제대로 이해했는지 확인해 보겠습니다.

걱정 마세요. 그래서 저희가 여기 있는 겁니다. 말씀하신 내용은 지난 20~30년 동안 데이터베이스에 대한 일반적인 사고방식에서 특히 분석 측면에서 컬럼형 데이터로 보는 방식으로 전환했다는 것입니다. 이는 추출 측면에서도, 새로운 하드웨어 동작 방식 측면에서도 훨씬 더 효율적이기 때문입니다.

맞습니다. 그 후 아파치 애로우는 메모리 모델을 관리합니다. 획기적인 것은 아니지만 여러 수준에 따라 다르기 때문에 몇 가지 사항을 관리합니다. 하지만 실제로 하는 일은 표준을 설정하고, 일반적으로 생각하는 데이터 유형의 시퀀스, 데이터를 저장하는 방법, null 또는 기타 측면을 표현하는 방법이 표준화되어 이 추상화를 기반으로 쉽게 구축할 수 있다는 것입니다.

따라서 각 반복마다 개선되고 모든 사람이 동일한 표준을 사용하게 될 것입니다.

네, 네, 네. 아주 좋은 요약입니다.

좋습니다. 앤드류 감사합니다. 컬럼 스토어로 전환이 일어난 이유를 설명하기 위해 한 단계 물러서서 더 높은 수준에서 설명하고 싶었습니다.

컴퓨터와 데이터베이스가 처음 등장했던 60년대와 70년대에는 데이터가 많지 않았습니다.

세상이 디지털화되지 않았기 때문입니다.

그 당시에는 엄청난 양의 디지털 정보를 만들지 않았습니다.

데이터를 가져오고 내보내는 속도는 일반적으로 사람의 행동에 기반했습니다.

은행 계좌에 어떤 작업을 하면 기본적으로 읽고 쓰는 것이 인간적인 규모였습니다.

90년대와 2000년대에는 우리 삶과 모든 컴퓨팅 인프라가 점점 더 디지털화되었습니다.

그래서 엄청난 양의 데이터가 생성되었습니다. 인간 규모 시스템뿐만 아니라 머신 규모 시스템에서도 발생했습니다.

따라서 데이터 양이 훨씬 더 많았고 증가하는 데이터 라인에 맞춰 새로운 기술이 필요했습니다.

컬럼 기술이 본격적으로 발전하기 시작한 시기는 데이터 라인을 처리할 수 있는 더 나은 방법이 필요했기 때문입니다.

물론 AI로 이동하는 이론도 있지만, 그건 다른 이야기일 수 있습니다.

어쨌든 Arrow는 모든 데이터베이스의 인 메모리 표현입니다. 데이터를 가져온 후 실제로 조작할 방법이 필요합니다.

사람들이 요청하는 계산을 실제로 계산하려면요. 이미 말씀하셨지만 다시 한번 강조하고 싶었습니다.

Arrow는 두 가지 장점이 있습니다. 하나는 표준이라는 것입니다. 즉, 데이터 프레임에서 데이터베이스, 다른 데이터베이스 등으로 형식을 변환하지 않고 데이터를 전달할 수 있습니다. 기본적으로 형식을 앞뒤로 변환하는 직렬화 비용을 지불하지 않고 시스템 간에 데이터를 쉽게 전달할 수 있습니다. 이것이 Arrow가 설립된 원래 이유라고 생각합니다.

Building Modern Databases with the FDAP Stack • Andrew Lamb & Olimpiu Pop • GOTO 2025

스크립트