[Databricks] Databricks 운영 정리 - 1편

 

안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제일 많이 집중하고 있습니다. 제가 어느덧 Databricks를 접한 지 10개월이 넘어가는 시점에서 회사에 와서 처음 시작해 보는 Databricks 플랫폼 환경에서 무엇을 하였는지에 대해서 회고 겸 정리 겸 글을 작성하였습니다. 

 

이 글은 타 회사와 환경과 비용적 측면에서 다를 수 있으므로 참고 차원에서 보시길 권해 드립니다. 제가 작성한 글이 무조건 정답은 아니며, 회사의 상황에 맞게 적용이 필요합니다. 그렇기에 꼭 본인의 회사에 적용을 하실때 환경과 상황에 맞게 각자의 판단에 맞게 적용을 부탁드립니다.  저의 글이 틀릴 수 있음을 감안해 주시기 바랍니다.

---

들어가며

앞서 말씀 드렷듯이 이 내용은 제가 적용하고 괜찮다(?) 싶은 생각이 드는 내용을 대략적으로만 정리하였습니다. 자세한 내용은 회사의 중요한 내용이 포함되어 있기도 하고 아직 정리가 끝나지 않아서 자세한 내용은 정리하지 못한 점 양해를 부탁드립니다. 그리고 비용이 생각보다 이것저것 많이 나와서 무엇이 맞다고 말씀을 못 드리겠습니다. 

 

저도 Databricks 초보이고 하나씩 배워가면서 하기 때문에 틀린 내용이 있다면 언제든지 말씀 부탁 드립니다. 또한 이 내용을 꼭 인터넷에 검색하여 충분히 검증하고 적용을 부탁 드립니다. (글 내용을 회사에 적용 후 문제에 대하여 책임지지 않습니다.)

 

우선 1편이라고 시작은 하였지만 2편이 나오지 않을 수 있습니다. 생각나는 것을 적다보니 순서도 중요도가 아니고 그냥 번호만 붙여두었기에 순서는 중요하지 않습니다. 그러니 해당 내용에서 필요한 부분만 정리하여 보시길 권해 드립니다. 

 

---

1. 비용 모니터링

비용

 

엔지니어는 언제나 비용에 관련해서 고민을 안할수 없습니다. 제가 여타 다른 글에서도 항상 강조하지만 돈은 엔지니어에게 떼려야 뗄 수 없는 존재입니다. 항상 모두 가능하다고 하지만 돈 앞에선 장사가 없습니다. 그렇기에 처음에 저는 비용을 모니터링하는 부분에 대해서 만들었습니다. 

 

Databricks에서는 비용에 관해서 보여주는 테이블이 존재 합니다. ( system.billing.usage )

Billable usage system table reference | Databricks Documentation

 

위의 테이블에 비용에 관련해서 저장하는 테이블이 존재하며, 여러가지 정보를 담고 있습니다. 해당 테이블에서는 굉장히 자세하게 어떠한 작업이나 사용자가 얼마의 비용을 사용하였는지 보여줍니다. 하지만 이 테이블은 DBU(DataBricks Unit)라는 단위로 row가 저장되어 있어서 실제로 이를 계산하기 위해서는 디멘젼 테이블이 필요합니다. 

 

Databricks에서 사용하는 비용 관련 디멘젼 테이블은 다음과 같이 존재합니다. ( system.billing.list_prices )

Pricing system table reference | Databricks Documentation

 

---

2. 테이블 옵션

 

Databricks의 옵션이라고 하기 보다는 저희가 지금 사용하는 Delta의 테이블 옵션이라고 하는 게 더 맞을지도 모르겠지만 Databricks 테이블에 적용할 수 있는 옵션은 엄청나게 다양합니다. 아래의 링크를 보면 옵션이 굉장히 다양한 것을 볼 수 있습니다. 

 

Delta 테이블 속성 참조 - Azure Databricks

 

이 옵션 역시 상황에 맞게 적절하게 옵션을 걸어주는게 맞을 거 같습니다. 몇 가지 중요하게 걸었던 옵션을 보면 제가 최근에 작성하였던 targetFileSize 옵션이 있습니다. 

 

[Databricks] targetFileSize 테이블 옵션

 

추가적으로 제가 주요하게 확인하고 걸어본 옵션을 몇가지 공유하면 다음과 같습니다. (옵션 설명은 위의 링크 참고)

delta.autoOptimize.optimizeWrite
delta.autoOptimize.autoCompact
delta.targetFileSize
delta.dataSkippingStatsColumns
delta.enableDeletionVectors

 

옵션이라는게 테이블마다 특성이 다르기 때문에 모두 다르게 적용해야 하는 경우도 있으니 꼭 테이블의 특성에 맞게 옵션을 적용해야 합니다. 예를 들면 DELETE가 많거나 INSERT가 많거나 SELECT만 주로 일어나거나 여러 가지 상황이 있기 때문에 옵션은 테이블의 사용성에 맞게 다를 것으로 보입니다. 

---

3. OPTIMIZE / VACCUM 

 

어쩌면 정리작업?

 

이 2개는 진짜 아무리 강조해도 부족할거 같습니다. Delta 테이블의 경우 ACID가 보장되므로 INSERT / UPDATE / DELETE의 작업을 하면서 계속해서 새로운 파일을 만들어 냅니다. 그리고 기존의 파일에 내용을 삭제하면 (DELETE) deletion vectors가 있어서 OPTIMIZE를 통해서 주기적으로 정리가 필요합니다. 

 

What are deletion vectors? | Databricks Documentation

 

OPTIMIZE와 VACCUM을 하지 않으면 변경 후의 오래된 파일이 계속해서 남아 있어서 저장소의 낭비를 불러옵니다. 그렇기 때문에 주기적으로 작업을 수행해야지 저장소 공간의 낭비와 성능을 향상할 수 있습니다. 관련하여 제가 예전에 작성 한 글을 참고하면 도움이 될 것 같습니다.

 

[Databricks] Optimize / VACUUM

 

추가적으로 OPTIMIZE를 하면서 Z-ORDER를 하는 경우도 있는데, 이 부분에 대해서는 현재 수행하고 있지 않습니다. 저희가 사용하는 데이터 패턴상 큰 이점이 없어서 (실제로 성능 향상 효과 크지 않음) Z-ORDER를 작업하는 공수가 더 큰 것으로 판단되어서 해당 작업을 하지 않고 있습니다.

 

---

4. Partition / liquid clustering

 

 

이 부분도 3번만큼 중요한 작업으로 알고 있습니다. Partition과 luquid clustering 을 통해서 실제 물리적인 읽는 비용을 감소시키고 성능을 올려서 그만큼 작업의 효율을 증대시키고 작업 시간을 효율화시키고 비용을 감소시키는 효과를 볼 수 있습니다. 

 

Partitions | Databricks Documentation

Use liquid clustering for Delta tables | Databricks Documentation

 

2가지를 섞어서 사용은 불가능 하지만 (둘중 하나만 선택 가능) 각자의 상황에 맞게 적용하여 사용이 필요합니다. (제가 알고 있기에 2개는 함께 적용이 불가능합니다.) 지금 제가 주로 사용하는 테이블의 경우 Partition을 적용하여 사용하고 있으며 둘 중에 무엇이 낫다고 말하기보다는 데이터를 쌓는 방식과 주로 사용되는 사용성을 확인해서 걸어야 할 것 같습니다. 또한 데이터의 성격 (카디날리티와 같은...)에 따라서 역시 무엇을 주력으로 사용할지 결정이 필요할 것 같습니다. 

 

관련해서는 곧 성능을 비교하는 내용을 작성 해보고자 합니다. 

 

---

마치며

어느덧 10개월정도 Databricks를 사용하다 보니 무엇을 해야 하는지 감을 잡아가는 것 같습니다. 아직 많이 부족하지만 어느 정도 구색(?)을 갖춘 데이터 환경을 구축하였고 많은 사용자가 해당 환경을 사용함에 있어서 뿌듯함을 느낍니다. 계속해서 사용자를 늘리면서 겪는 문제와 데이터의 크기와 다양성이 증가하면서 겪는 문제에 대해서 글을 추가적으로 작성하도록 하겠습니다.

 

감사합니다.