2025.9월 학원 연주회

연주회를 했는데 기록은 남겨야 할 것 같아서..

• Smoke gets in your eyes는 숙제로 (…) 작곡한 내 솔로로 연주회 나갔는데…첨이다보니까 별로 맘에 안드는 듯 ㅋㅋ 끝나니까 연습하고 싶지가 않음
• 이건 수업중 선생님이 10분만에 쓱쓱 짜주신 솔로로 나감 ㅋㅋㅋ

박자가 많이 불안한 게 메트로놈을 더 들어야 할 것 같음. 그래도 학원에 안가고 fly me to the moon 쳤던 옛날보단 나아진 것 같긴 함. 돈내고 배웠으니 ㅡㅡㅋ 안나아지면 그것도 그것대로 슬픈 일이지만..

재즈를 치다보니까 난 대충 쿨재즈 - 쉬운 비밥 사이 신나는 (?) 연주가 취향에 맞는 것 같음. 초딩취향이라고 할 수도 있겠지만..노잼이면 연습이 안되니 어쩔 수 없는걸 ㅎㅎ

담번에는 Confirmation 해보자고 선생님한테 말하려고 각 잡는 중. 근데 그럴라면 스케일분석하고 연습해둬야 할텐데 넘 귀찮다..

앞에거 쳐서 넘 힘들어서 이건 좀 대충…ㅎ

• B파트 (인타임) 는 쓸데없이 힘이 많이 들어간 것 같음. 오히려 A’ 초반은 좀 더 세게 쳐도 괜찮을 것 같은데…

이것도 기본 코드 칠때 녹음해 놨으면 좋았을텐데 ㅎㅎ 귀차니즘이….😇

재즈는 칠때마다 연주가 조금씩 변함 ㅎㅎ 패턴이 늘기도 하고 기존걸 까먹기도 하고…

클래식보다 이 점이 재밌는듯

아니근데 오인페 빤짝거리는거 시선강탈이네…ㅋㅋㅋㅋㅋ

2025.4월 학원 연주회 ver

학원 연주회 때 쓰려고 선생님하고 짜깁기한 버전. 솔로파트엔 내 기여분 2% 정도 있음 ㅋㅋ

자꾸 빨라지려고 함…흑염룡마냥 계속 억제할라고 하는게 눈에 띔 ㅎㅎ

토욜에 연주회 하고, 밴드 공연도 하고….이제 사람들 앞에서 연주하는게 좀 덜 무서워지긴 했음 ㅋㅋ (안무섭다곤 안함 ㅡㅡㅋ)

곡도 대충 짜깁기할수 있게 됐고…연주경험도 좀 쌓였고…그래서 좋나? 잘 모르겠음 ㅋㅋ 적당히 나쁘지 않은 느낌

대충 학원 초기

역시 완전 기본연습이어도 좋아하는 곡 칠때가 잴 재밌는 듯 ㅎㅎ

• 기본 7코드 텐션 + 대충 2/3지점부터 왈츠풍으로 근음 / 37음 (아니면 73) 치기

선생님 말 들어보면 이곡으로 drop two 보이싱같은거도 연습할꺼같은데…기본부터 어려운것까지 하나씩 해볼 수 있으면 좋을듯 ㅎㅎ

좋긴 좋은데….시간이 진짜 넘 없네 ㅋㅋㅋ 밤에 연습끝나면 현기증남…

• 그러고보면 고민이 아주 없는 건 아니었네 ㅋㅋ 근데 이런고민도 상담이 되나 ㅡㅡ

• 생각보다 is-a 상속을 깔끔하게 쓰기 쉽지 않음 (리스코프 치환 지키면서)

이미 커뮤니티에선 다들 입아프게 떠드는 거긴 한데…프로덕션에서 다시 느낀 건 오랜만인 듯 ㅎㅎ 좋은 기회인 듯

• is-a에 맞게 상속을 사용하기보단 단순 코드 재사용 용으로 쓰는 경우가 대부분. 공통코드를 상위로 돌리고, 하부에선 super의 공통코드를 적절하게 호출하는 식

객체지항은 같은 코드라도 런타임에 설정값 기반으로 동작이 매번 달라질 수 있고 (다형성), 모든 경우의 수를 코드에 다 박아놓지 않고 설정값 기반으로 동작을 바꿔가며 대응가능한게 장점이긴 한데…

• 위의 애매한 상속과 겹처지면 이게 장점이 아니라 단점으로 바뀌고, 문제 2개가 만나 서로 곱해지는 느낌..ㅎ
• is-a에 맞지 않는 상속을 계속하다 보니 상속 하이어라키가 쌓이면 피곤해짐
  • 원래는 (=is-a에 잘 맞는 상속을 했다면) 상위클래스를 다 뜯어보지 않아도 어느정도 내용짐작이 되어야 하는데 중구난방이다 보니, 특정 하위 클래스의 런타임 동작을 짐작하려면
    • 상위클래스(들)의 코드를 다 뜯어보고
    • 그 중 어느것이 실행되고 어떤건 (override 등 되어) 실행되지 않는지 다 파악해야 함. 포인터는 상위 인터페이스지만 실체화된 객체는 외부설정에 따라 다를 수 있으니까..
• 심지어 외부설정값을 자체개발한 설정값 서버 등의 솔루션을 사용하는 경우….더 어려워짐
  • 위의 런타임 동작 짐작에서…여기저기에 흩어져 있는 외부설정값을 모아서 동작 path를 따라가 보는 것 까지 추가됨 ㅜㅜ
  • 설정값은 그냥 헬름차트 + 환경변수 쓰면 안되나..ㅎ 근데 환경변수는 레벨설정이 안되서 금방 더러위지긴 함. 이름에 못쓰는 케릭터도 꽤되고
• 그리고 동작경로에 이런 (런타임에 행동이 변할 수 있는) 부분이 여러 개 복잡하게 얽혀 있으면….그림 그려놓고 경우의 수 따지면서 코드 봐야 됨 ㅋㅋ 횬다이 이후 오랜만에 코드보다 멘탈 탈출할 뻔…ㅎㅎ

그럼 이걸 해결하려면? 잘 모르겠음 ㅋㅋ 다들 말하듯 공통코드는 우선 is-a 보단 has-a 컴포지션으로 써보는 게 더 좋은 방향인 것 같긴 함

• 이런 문제들 때문에 런타임 동작이 짐작조차 가지 않아도 테스트를 읽어서 동작을 좀 알게 된 경우가 많은 듯. 결국 테스트를 잘 넣는 것도 (간접적이지만…) 어느정도 해법에 들어가는 듯
• 코드가 난해해질수록 테스트가 문서 역할을 더 많이 하게 되는 듯. “개발당시 나는 내가 만든 걸 이렇게 써 주길 원했어요” 가 적힌 문서 느낌으로…반대로 테스트도 그런 느낌으로 작성해야 하기도 하고
• 인터페이스 단위로 잘 분해되어 있기만 해도…거대한 시스템이라도 (책임 단위로) 독립적으로 떼어놓기 편해서 도움이 엄청 되는 듯

그래도…다행히 나쁘지 않은 곳에 온 듯 ㅎㅎ 특히 크키가 큰 메인 앱이 하나 있고 코드가 서로 의존적인 부분이 많은 게 좋은 듯 (파악은 어렵지만 ㅎㅎ). 코드때문에 대가리 깨져봐야 생각을 많이 하게 되니까…

• 이전에는 뭐랄까…레포 자체에 코드는 꽤 있지만 서로 영향을 주지 않고, 단발성으로 각자 실행되는 코드들이라 변경 시 의존성 때문에 문제될 게 엄청 많진 않았음. 그래서 테스트가 별로 필요가 없어서…넣자고 말하기 좀 그랬음 ㅋㅋ 오버엔지니어링은 공공의 적이니까..

그나저나 요즘 공부기록엔 노션을 쓰면서…여긴 뭔가 취미 블로그처럼 되어버림 ㅎㅎ 이 글도 노션에 대충 끼적인 걸 정리한거긴 함…
왜 여기에 남는시간을 쪼개서 기술관련 글을 쓸 의욕이 안생기는지 생각해봤는데..일단 노션이 넘 편하고, 둘째로 robots.txt를 막은 게 큰 듯.

나도 뭐 이젠 몇년전 반사회적 회피성 성격장애 (…) 보단 좀 사람같이 된 것 같은데, 슬슬 개발자로서 지금까지 도움을 받은 만큼 나눠야 하지 않나…생각인데 사이트가 비공개여서 읽는 사람이 없어 큰 의욕이 안 나는 듯. 뭐 공개한다고 읽는사람이 생기는 건 아니지만 ㅋㅋ
나름 관련 일을 하게 된 만큼 다음번 블로그는 robots를 허용하고 검색엔진에 노출해 볼 생각…인데 ㅋㅋ 과연

이 블로그도 칠팔년쯤 된 듯 한데…할 만큼 한 느낌 ㅎㅎ
대충 취미 한두번 끄적이다가 닫게 될 듯.

https://www.youtube.com/watch?v=kPa7bsKwL-c

• md파일은 유튭 자동재생도 안됨..ㅎ

차세대 블로그 시스템은 얼어죽을 ㅋㅋ 두달동안 커밋 한줄도 못했네

모르겠고…ㅎ 롤챔이나 봐야지

• 코드연습이 더 중요하다고 20%만 쓰라 하셨지만 곡이 맘에 들어서 50%는 쓴듯 ㅎㅎ

과제

• 리듬이 들리지 않게 쳐야 한다는 선생님의 명언이 있었음 ㄷㄷ 잘 되진 않은듯 ㅋㅋ 특히 뒤로 갈수록…
• 멜로디 파악 및 멜로디라인만 강조하기
  • 이 때 한음만 강조하는건 어케하는건가 생각했는데 나빼고 다 열심히 연습하고 있었음 ㅋㅋ
  • 멜로디를 노래하듯이 라고도 하셨는데 이건 전혀 이해를 못함..ㅋㅋㅋㅋㅋㅋ
  • open studio
    • you need to be able to control your left hand, so that it’s just like mist in the air
    • let your right hand sing
    • 선생님이 말한 그대로임 ㅎㅎ 근데 사실 노래를 못하니까 “노래할때 이렇게는 안할 거잖아요” 하셔도 뭔소린진 잘 모르겠음 ㅋㅋ
• 페달 끊어주기….ㅋㅋ 이건 계속 문제네
• 한 반년만 계속 치면 나름 맘에 드는 연주가 나올 것 같은 느낌적인 느낌..ㅎㅎ 이곡은 반년뒤에 꼭 다시 찍어보고 싶음

학원은 진짜 잘 간것 같음 ㅎㅎ 잘친다 못친다를 떠나서 연주가 훨씬 즐거워짐 ~숙제가 넘 많긴 한데….~

음악 취향이란 게 주관적이지만…가끔은 남의 도움을 받는 것도 좋은 듯 ㅎㅎ

2차

대충 3개월쯤 지났는데..이젠 악보가 좀 익숙해져서 소음공해 탈출 시도정도는 해볼만 한듯 ㅋㅋ

밴드 서류면접 (?) 때도 이곡 냈었는데…좋게 봐주셔서 기분이 좋았음 ㅎㅎ

중간부터 좀 힘을 빼면 좋을 듯…페달링도. 페달링은 특히 이렇게 녹음해서 듣지 않으면 어떻게 들리는지 신경쓰기 어려운 듯..

• stub / mock 구분 (내가 지금 state / behavior 중 뭘 테스트하는지도 인지하기)
  • 이건 생각보다…잘 실천이 안됐음. 실천한다고 도움이 되나?
• hemchrest 사용 (AssertJ ㅜㅜ)
  • 굿
• given when then 구조 사용
  • 이건 테스트에 섹션을 구분해놓으니까 보기 좋은 듯
• 구현을 테스트하진 않는지 항상 생각하기. 되도록 인터페이스를 대상으로 결과만 테스트하기
  • 굿2
• Mock을 안 쓸 수 있으면 안쓰기!
  • 하고싶은데 잘안됨 ㅎ
  • 모킹이 많을수록 false positive test가 될 확률이 높다…진짜 공감가는 말인듯

https://blog.outsider.ne.kr/1275?fbclid=IwAR1Z9DPi-JJns_bSccrNZIo8zFo-0B8nAvIEHen3tu0_jaIUS34hY90FVJ0

• 공감가는 부분이 엄청 많은듯

https://www.martinfowler.com/testing/

맨날 까먹는 거

Test double

https://martinfowler.com/bliki/TestDouble.html

• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
• Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting.

given when then

https://martinfowler.com/bliki/GivenWhenThen.html

• The given part describes the state of the world before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
• The when section is that behavior that you’re specifying.
• Finally the then section describes the changes you expect due to the specified behavior.

JUnit은 테스트 한번 돌릴 때 마다 클래스를 새로 만든다 함 - 지금도 그런가?

Mocks Aren’t Stubs

mocks = behavior verification

• others = state verification (usually)

1. With state verification we do this by asserts against the warehouse’s state
2. Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification. Only the order is checked using asserts, and if the method doesn’t change the state of the order there’s no asserts at all

목 - 미리 expects 를 설정해 놓고 behavior verification을 함

• 흠…
• stub - 다 실행한 담에 assert로 state 체크
• 난어째 목으로 상태체크만 맨날 한거같은데?ㅋㅋ

Mock objects always use behavior verification, a stub can go either way

https://frostbyte134.github.io/coding/2022/12/31/mocks-arenot-stubs.html

https://martinfowler.com/articles/mocksArentStubs.html

https://stackoverflow.com/questions/3459287/whats-the-difference-between-a-mock-stub

모킹이 안좋은 경우 / 의견

https://stackoverflow.com/questions/1595166/why-is-it-so-bad-to-mock-classes

Mocking is used for protocol testing - it tests how you’ll use an API, and how you’ll react when the API reacts accordingly.

• behavior testing과도 통하는게 있는 듯

Every class has an implicit interface, which is the set of public methods and constructors it defines. There is nothing wrong in seeing this as the “protocol” of the class. So, “protocol testing” does not imply that classes should not be mocked. Also, creating a mock does not mean that each and every mocked method must be explicitly specified in the test. Expectations can be either strict or non-strict, where the non-strict ones are freely allowed to occur any number of times in the code under test. In other words, a stub is just a type of mock where all expectations are non-strict by default.

어쨋거나 목은 행동 검사를 하면서 expect도 추가로 달고 복잡한게 꽤 많아지는 듯

mocking interface vs class

https://www.reddit.com/r/haskell/comments/qdexgu/cs_syd_why_mocking_is_a_bad_idea/

https://www.yegor256.com/2014/09/23/built-in-fake-objects.html

• mocking framework를 피해라?
• 근데 첫문단 문제는 주로 클래스 디자인이 잘못된거같은데 (특히 SRP위반). 하긴 협력관계가 복잡한경우…도 포함이 되는 듯
• Fake를 production code하고 같이 shipping해준다……?
  • 나도 추천팀에서 테스트목적 인메모리 디비 만들고 후회했던적 있던거같은데 ㅋㅋ
  • 결국 이 페이크 클레스에 대해서도 알아야 하는거아닌가? 복잡도를 뒤로 숨기는 느낌…?
  • 어쨋거나 목대상 객체가 복잡하면 expect세팅은 곱절로 복잡하니까…선형으로 끊자는 거 같은데..

test cancer

https://www.martinfowler.com/bliki/TestCancer.html

시작부터 노답문제라고 박고 들어감

typically there are as many lines of code of tests as there are of functional code ㅋㅋ

음…다들 테케 읽기 싫어하는건 비슷한가 봄 ㅋㅋ

making stubs

https://martinfowler.com/bliki/MakingStubs.html

테스트에서의 스텁 활용법

• abstract factory로 (흠…)
• prototype으로 (아니…굳이?)

실제 케이스를 본적이없어서 좀…실용성이 있나? 이렇게까지 해야하나 느낌

static substitution

https://martinfowler.com/bliki/StaticSubstitution.html

One of the big problems with statics (in most languages) is you can’t use polymorphism to substitute one implementation with another. This bits us a lot because we are great fans of testing - and to test well it’s important to be able to replace services with a Service Stub.

보통 config에 static을 많이 쓰는데

static config를 쓰는 객체 -> 만들때부터 static에 의존하기 때문에 테스팅이 어려움. 객체, 생성자 및 기타 메소드 다 static이 붙어야 함

• 클래스에 static obj (singleton)을 두고, 로직등엔 전부 static 때버리기 (hence substitution)

마지막엔 이런 함수 하나만 추가하고, 테스트시에 arg에 스텁 넘겨주기

    public static void loadInstance(AddressBook arg) {
        soleInstance = arg;
    }

is TDD dead?

https://www.martinfowler.com/articles/is-tdd-dead/

TDD는 self testing code에 도달하는 방법 중 하나일 뿐

켄트백조차 모든개발에 TDD를 쓰진 않는다고 함. 다만 TDD를 안쓴 곳에도 regression tests and short feedback loops는 사용

he (Kent) said he rarely uses them (TDD), he’s concerned that those that do often find refactoring difficult, while he finds testing makes refactoring easier.

design damage - 모든 것을 테스트하기 위해, 헥사고날처럼 (port & adapter) indirection, runtime polymorphism같은걸로 다 갈아끼울수 있는 구조로 가다보면 코드가 복잡해짐

• 내지는 TDD가 addictive하게 위의 방향으로 개발하게 유도

Kent said that ascribing test-induced damage to TDD was like driving a car to a bad place and blaming the car for it. The design David showed wasn’t due to TDD, the real issue is that these indirections are all good tricks under some circumstances and we need to understand whether they are worth the cost or not

I replied that “you don’t have enough tests (or good enough tests) if you can’t confidently change the code,” and “the sign of too much is whenever you change the code you think you expend more effort changing the tests than changing the code.”

• I said I like the “can I comment out a line of code” approach when I’m unsure of my ground, it’s a starting place but as I work more in an environment I can come up with better heuristics.

AssertJ

https://xxeol.tistory.com/12 완전 좋은듯 ㅎㅎ

우린 헴크레스트였네. 뭐 일단 쓰고 보자 ㅋㅋ https://expert0226.tistory.com/335

유닛테스트에 대한 생각

https://gregor77.github.io/2019/08/16/about-unit-test/?source=post_page—–e6b4394f9ed——————————–

입력값에 대한 결과 값을 검증하는 방식으로 짜는 것이 기본

• false positive test의 가장 큰 원인 - 구현을 테스트하는 것
• ex) 서버의 리턴 상태코드를 체크하지 않고 메시지를 체크
• 가능하면 입력의 결과 또는 인터페이스만 테스트해야 함

효율적인 JUnit 사용

https://yozm.wishket.com/magazine/detail/1748/

진짜 별내용 없었음..

self initializing fake

https://martinfowler.com/bliki/SelfInitializingFake.html

Unit test

https://www.martinfowler.com/bliki/UnitTest.html

Goto Fail, Heartbleed, and Unit Testing Culture

https://www.martinfowler.com/articles/testing-culture.html

와 개 김 ㄷㄷ 읽어볼 만한가..한국에선 별로 읽은사람이 없는듯. 하트블리드는 쬐끔 관심있긴 한데 ㅋㅋ

• 학원에서 코드는 배운 덕인지 곡을 외울 다른 방법이 생긴 것 같음. 아직 진행은 이해를 못하지만…

그나저나 이제 학원 숙제도 해야하고..밴드 곡도 연습해야 하고..지금처럼 혼자 곡을 고르고 녹음하는 건 못할듯 ㅎㅎ

애초에 왜 다시 치기 시작했는지….는 까먹었지만 ㅎㅎ 즐거웠으면 됐지

담에 또 할지는 모르겠지만 그땐 더 재밌게 잘 치고 있길 ㅎㅎ

• 분명히 어렸을때 들어봤을텐데 기억이 1도 안남 ㅋㅋ 그래도 칠 생각이 든걸 보면 어디 기억 구석속에 좀 남아있나..
• 아닌가? ㅎㅎ 김대윤님 편곡 차력쑈 덕분인가…

갬성모드로 유튭 떠돌아다니다가 오랜만에 호로비츠의 트로이메라이를 봤는데 넘 좋았음 ㅎㅎ 진짜…유튜브의 얼마 안되는 순기능인 듯 ㅋㅋㅋㅋ

• 어렸을 땐 별생각 없이 연주만 들었는데 (영상도 좀 달랐던듯) 지금 보니까 이 때의 호로비츠가 뭔가 멋있어 보이는 느낌
  • 전쟁으로 망명했다 노년에 고향으로 돌아와서 연주한 트로이메라이여서 더 그런 것도 있을 듯

https://linedevday.linecorp.com/2021/ko/sessions/64/

• https://speakerdeck.com/line_devday2021/adopting-apache-iceberg-on-line-data-platform

챌린지, 쿼리과제

• SQL 실행 시 쿼리엔진이 분산처리를 가능하게함 (plan만들어주고 리소스 관리스템이 리소스 할당)
• 쿼리 -> 실행플랜 변환
  • 데이터파일이 어딨는지, 어떻게 읽고 쓸지
  • 이런 데이터를 어케관리할지는 테이블 포멧으로 정의됨

한글 듣다가 영어로 바꿈 ㅋㅋ a row in table을 “한 줄”로 변역하네..

• 영어는 기계음이 좀 찢어지는 듯…

Table format

• Determines a way to organize data files, to present them as a table

Data discovery

• answerswhat data files are in a table
• hides the complexity of finding relevant files

Data abstraction

• answers how to read/write data
• Hide the complexity of data format and data structures

hive data format - De facto standard

• data files are defined in directory (/table/ymd=2023-10-01)
• hive metastore (= a server)
  • partition, schema
  • saves metadata in RDBMS

troubles in metastore

• select - QPS 5000
• cpu usage = 50~60\% when high
• over 90% in certain times
• some hive table which has 11M+ rows
• deleted the partitions (which was not intended)

Hive metastore

• 1 partiton = 1 row
• trouble can be caused by heavy scans - OOM (GC)
• “table metadata lookup performance is bound to the capacity of central Hive metastore and Metastore DB instances”

Iceberg

• open source table format (like Hive, which is also a table format)
• table format: way to abstract what data comprises the table, in sql quety execution
  • track and manage the status of table
  • create snapshot when data is read and committed

snapshot: status (of the files) of the table, in certain point of time

table meta - manifest list - manifest file

• manifest list: meta about manifests, including partition stats
• manifest files: list data files

difference wrt hive

• state of the tables are tracked using file
• not DB -> scalable
• stat support - hive (per partition) / iceberg (per file)

finding files for a query

1. current snapshot and manifest list file is refered
2. filter manifest files, using partition value ranges sotred in the manifest list files
3. read each manifest to get data files

Summary

• Hive table format is coupled with central metastore db (poses scability issues)
• “we are considering adopting it widely in Line Data Platform”

part 2

overview of existing log pipelines

kafka - flink - RAW table

• append only, sequence file format (= raw data format)
• exatly once delivery

orc = faster

watcher - detect update of raw data (per partition)

• Tez converts sequencefile format table to ORC using INSERT OVERWRITE

all tables are external, for the loose coupling with the data and table

problems of existing pipelines

end to end high latency: 1~2 hours to write log to the table

1. small file problem - to avoid it, used BucketingSink
   • enabled writing to a single seq file over multiple checkpoints (to append to a single sequence file)
2. 2hour latency = Flusing RAW table seqfile every hour, to create hourly partitioned HDFS file (= 1 hour). Takes 50mins for the conversion (+1 hour)

proposed solution

1. directly write ORC (streamingFileSink + OrcWriter)
   • write per every few mins (from 1 hour seq file to orc)
2. but small file compaction (delete and replace) was problem (not easy to implement)
   • it can delete the files just b4 user’s job read them
   • to many partitions and various sending patterns
   • not easy to implement compaction (delete and replace) on hive (+ high scan cost)

robustness problem of the solution

• flink watcher, HDFS, hive metastore, Hiveserver2, Yarn

heavy scan

• heavy partition scan, wrt hive metastore
• heavy hdfs dir scan, against namenode

schema EVOL (ORC)

• used orc.force.positional.evolution=true, for backward compat
• 이옵션 좀 알아봐야할듯

cannot delete/insert/move fields

• supports only adding files of table/struct
• table의 컬럼이 아니라 필드라고 하는 듯
• often user request to drop / modify

new pipeline

kafka -> flink (flush orc file per 5 mins) writes iceberg files directly -> iceberg table

flinck + iceberg app

as-is

• convert protofuf/json to avro using org.apache.avro.protobuf lib
• converg avro to rowdata using Iceberg FlinkAvroReader

multi-write, single-commit

• IcebergStreamWriter writes files (many writers during the flow)
• IcebergFilesCommiter commits snapshots (1 commiter during the flow)

FlinkSink of Iceberg = wrapper of the writer/commiter. Didnt used for perf issues

• 질문?

splitter?

Furture works

• verify the stablility / scalabity of iceberg table, and start to think iceberg table
• replace hive table to iceberg table
• use iceberg features such as incremental read/update, time travel

• 학원..내가 갈 수 있을까….ㅎㅎ 잘 모르겠음. 모르겠는 일 투성이네…
• 하긴 언젠 뭘 알았다고..ㅋㅋ

곡은..첨에 길게 누르는 e플랫메이저7이 좀 맘에 듬 ㅎㅎ

• 보이싱에 신경을 쓴 편곡은 대충 이런 느낌이 나는 듯..
• 재즈는 긴장과 이완의 연속이라고 하던데..난 아직 텐션음이 어딘지, 레솔루션이 어딘지도 잘 구분 못하긴 함. 그냥 콩나물 써져 있는대로 누를 뿐….