goLang Tour의 slice를 해보고 있었다.

slice라는 것은 python에서도 자연스러운 것이었으나, goLang에서 가장 크게 혼동되는 것은 cap이라는 개념이 있는 것 + 기존 slice에 append하는 경우에, cap이 모자라면 +1이 아니라 +2 해서 생성이 되는 것을 발견한다.

이거 생각 잘 하고. 그 특성을 이해 하고 써야겠는걸?

package main

import "fmt"

func main() {
	var s []int
	printSlice(s)

	// append wprks on nil slices
	s = append(s, 0)
	printSlice(s)
	// append를 하면 len==1이 되는 것은 당연해 보이는데, cap==2가 되는 이유는 무엇일까?

	// len을 강제로 2로 변경 해 보면 늘어나는 것을 볼 수 있다.
	// s = s[:2]
	// printSlice(s)

	// The slice grows as needed
	// 위에서는  nil에서 append하면 cap==2가 되었는데. cap==2인 상태에서 append하면 여전히 2이다.
	// 뭔가 규칙이 있나?
	s = append(s, 1)
	printSlice(s)

	// We can add more than one element at a time
	// cap이 apped결과보다 작을 경우에, cap+1이 되어 생성되는 것으로 보인다.
	s = append(s, 2, 3, 4)
	printSlice(s)

	// 강제로 len을 설정하면. 마지막은 0으로 되어 있는 것을 볼 수 있다. nil이 아니다.
	s = s[:cap(s)]
	printSlice(s)

}

func printSlice(s []int) {
	fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

1e9에 대한 설명

A Tour of Go를 살펴보다 보니. 변수에 1e9을 대입한다.

응?

처음에는 뭔가 저정돤 메모리주소의 sample인가 싶었지만.

구글링 해 보니, 숫자를 선언하는 형식인것을 알게된다.

Prefect 인증화면

Prefect를 살펴보기 위해서 Cloud에 sigin in 한 다음 따라하고 있었는데 말이다.

local cli에서 prefect module을 설치하고 cloud + login 파라메터로 실행을 하니, 진행중인 웹브라우저로 인증을 한다.

당연히 web을 통한 인터페이스만 제공되는 줄 알았는데, local 환경을 제공하는 것은 어떤의미일런지.

Prefect local deploy 화면

한참을 뒤지다가 local에서 server를 띄우고 deploy를 실행 해 본다.

이런 CLI에서 본격적으로 select하는 녀석은 오래간만이다.

dbt를 보다가 보니 이런 저런 내용이 나오는데, 누군가 star schema에 대한 언근이 있어 찾다가 MS의 Understand star schema라는 페이지를 찾았다.

좀더 구체적인 비교를 찾아 질의 해 본다.

1. 구조 (Structure)

Star Schema

• 중앙에 하나의 팩트 테이블이 있고, 이를 둘러싼 다수의 디멘션 테이블로 구성됩니다.
• 디멘션 테이블은 비정규화된(flat) 형태로 설계되며, 각 디멘션이 별도의 테이블로 저장됩니다.
• 단순한 구조를 가지며 별 모양을 띱니다.

Snowflake Schema

• 팩트 테이블은 동일하지만, 디멘션 테이블이 정규화된(normalized) 형태로 설계됩니다.
• 디멘션 테이블이 하위 디멘션으로 분할되어 복잡한 트리 구조를 형성합니다.
• 눈송이(snowflake) 모양을 닮은 구조입니다.

2. 정규화 수준 (Normalization)

Star Schema

• 디멘션 테이블이 비정규화(denormalized) 되어 있습니다.
• 하나의 디멘션 테이블에 모든 속성이 포함되며, 중복 데이터가 있을 수 있습니다.

Snowflake Schema

• 디멘션 테이블이 정규화(normalized) 되어 있습니다.
• 중복 데이터를 제거하고 디멘션 속성을 여러 테이블로 나눕니다.

3. 복잡도 (Complexity)

Star Schema

• 구조가 단순하여 이해 및 유지 관리가 용이합니다.
• 쿼리가 간단하고 빠르게 실행됩니다.
• 데이터 웨어하우스 설계 초보자나 소규모 프로젝트에 적합합니다.

Snowflake Schema

• 구조가 복잡하며, 이해 및 유지 관리가 어려울 수 있습니다.
• 정규화로 인해 테이블 간 조인(join)이 많아 쿼리 성능이 떨어질 수 - 있습니다.
• 대규모 데이터 웨어하우스나 복잡한 데이터 관계를 다룰 때 유리합니다.

4. 성능 (Performance)

Star Schema

• 조인이 적어 쿼리 성능이 일반적으로 더 우수합니다.
• 디스크 공간 사용량은 더 많을 수 있습니다(중복 데이터 때문).

Snowflake Schema

• 정규화로 인해 조인(join) 작업이 많아 쿼리 성능이 저하될 수 있습니다.
• 디스크 공간 사용은 더 적습니다(중복 데이터가 제거됨).

5. 사용 사례 (Use Cases)

Star Schema

• 단순한 데이터 분석과 빠른 응답 시간이 필요한 경우.
• BI 도구나 OLAP(Online Analytical Processing)에서 자주 사용됨.

Snowflake Schema

• 데이터 중복을 최소화하고 정규화를 통해 데이터 무결성을 유지하려는 경우.
• 복잡한 데이터 관계를 명확히 표현해야 하는 경우.

비교 요약

SSH로 연결 할 때 IP는 local host이다.

Oracle Cloud에서 메모리 부족 사태를 겪은 후 DEMO용 DBMS에 대해서 가급적이면 sqlite를 사용하려고 노력하고 있었다.

그런데, wiki.js라던지 FastAPI 공식 Template을 사용 해 보면서, 결국 DB는 postgresql로 넘어갔구나 하는 생각을 하고, 메모리를 얼마나 점유하는지 확인 해 보니, 그리 걱정 할 수준은 아니라고 판단해서 올려 놓기로 한다.

막상 container를 올려놓고 보니, 관리하는 것이 영 불편할것 같아, remote db에는 직접 접속하지 않겠다는 기존 생각을 고쳐먹고, ssh tunneling을 시도 해 보는데.

dagster의 교육과정을 살펴보고 있다가 task-centric과 asset-centric이라는 단어를 보게되었다.

예를 든 초컬릿 칩 쿠키를 만드는 과정에서 task중심은 [재료모으기, 재료섞기, 초컬릿칩 추가하기, 굽기]로 Task를 기술하고, 재료나 중간가공품(쿠키 도우와 같은)은 별도로 표시(주석정도?)하는 방식이고, asset은 [주재표, 부재료, 중간가공품]과 같이 재품의 각 상태를 주요하게 기술하고, 각 상태를 전이시키는 task는 주석 정도로 표시하는 방식이다.

이 얼마나 명확한 방법인가 싶어, 이제까지 이런 생각을 못했다니 싶다.

참고로 Data engineering에는 asset중심이 더 유리하다 한다.

• data lineage측면. (이걸 혈통이라고 번역하면 좀 이상하기는 한데. 적절하기도 하다.)에 대한 파악이 용이하다고 한다. 일리가 있다.
• asset의 재활용 측면.
• asset의 freshness측면. (이걸 선도라고 번역하면.) 데이터가 얼마나 신선한가? 의미있는 부분이다.
• debugging측면.

dagster를 보다가 보니까 dbt를 자연스럽게 보게 된다.

pamac를 실행했는데, 왜 Chrome을?

아침에 jq라는 녀석을 한 번 해 보려고 pamac에서 jq를 설치하려 했더니 Chrome을 갱신하고 있다.

Manjaro를 사용 한 지 거의 1년이 다 되어 가지만 아직도 apt에 비해 익숙하지 않은건 사실이고, apt에 비해 더 가벼운 느낌이라는 것도 사실이다.

왜 더 가벼운 느낌일까?

Manjaro를 처음 사용하기 시작하면서, pamac와 pacman에 대해 구분하지 않고 대충 구글링해서 나오는 것을 기계적으로 입력하던 버릇은 apt에서 기인 한 것이라 생각된다.

이 부분을 잘 살펴보면, 인식, 인지 그리고 내가 지금 하려고 하는 것을 향한 돌진에 그것이 걸림돌이 되지 않는다면 아무런 상관이 없는 Console에 뿌려지는 단어들이라는 생각이다.

Rust에서 문자를 파라미터로 넘기는 모습을 봐라

새해들어서 어떻게든 호기심을 유지하려고 한 해 동안 모아두었던 링크들을 정리하고, 하나씩 해 보고 있다.

Rust의 경우. 첫 번쩨 빌드하기 위한 소스의 구조를 toml에 기술해줘야 한다는 것은.. 뭔 그럴수 있다고 치자.

그 다음 파라미터를 좀 보면서 문자열을 넘기는 부분을 보다 아연실색한다.

그리고 좋다고 생각한다.

형식은 언제나 익숙해지기 마련이다. 생각을 잘 하면 매우 유용 할 것이고, 가변적인 상황을 전부 상정해서 어떻게 하려면.. 아마 방법이든 패턴이든 라이브러리든 있을 것으로 생각된다.

2024년 프로젝트 진행하느라 링크만 남겨뒀던 것들을 주워모아 본다.

지인

바닐라 프론트: 이병옥 대표가 드디어 릴리즈 했다.

ETL or Data Process

아래 4개가 도출되었음

airflow - 아직까지는 가장 범용적 a platform created by the community to programmatically author, schedule and monitor workflows

Prefect Cloud 버전을 테스트중. local은 찾아보고 있음.

Mage 홈페이지에 AI틱한 문구를 띄우고 있지만.

dagster - data pipeline oneline solution? “Data engineering doesn’t need to be a drag"라는데?

luigi - build complex pipelines of batch jobs 간단한 깃헙 페이지?

이번에 주석 처리 한 것

매번 시스템을 바꾸거나하면서 jekyll을 재설치해야 하는 경우. 거의 몇 달이거나 1년만에 하는 경우가 많다보니 잊는다.

이번에 노트북을 새로 밀면서 거의 1년만에 다시 올리려고 보니 이미지를 빌드하는 과정에서 오류를 내 뱉는다.

무얼까? podman으로 바꿔서 안 되는 것일까?

jekyll이미지를 다시찾아보다가 마땅찬으니 build script를 다시 읽어보고, 별 거 없으니, Gemfile을 유심히 본다.

음… 오류메시지를 다시 본다.

mini_racer

얼마간의 시간이 지났으니 이번에는 저 녀석이 나가떨어졌나보다. 하면서 주석처리하고 다시 빌드하니 먹는다.