안녕하세요 권철민 강사님 astro dev start 에서 에러가 되어 찾아보니 dev init 명령어 이후 생성된 Dockerfile 파일에 최신 버전으로 자동 다운 되는거 같습니다 Astro CLI Version: 1.34.0 FROM astrocrpublic.azurecr.io/runtime:3.2-4 == 파이썬 3.13환경 으로 되는거 같고 그에 따라, requirement.txt 라이브러리 버전과 일치 하지 않아 실행이 되지 않는거 같습니다 혹시 깃허브 airflow_part_01 Public/ requirements.txt 파일 라이브러리 버전 높여서 업로드 부탁 드릴 수 있을까요?
동시성 이슈에 발생할 수 있는 상황에서, A 변수에 대해 읽기 작업만 수행하는 코드(가시성 문제가 있을 수 있는 코드)에서는 volatile을 고려해볼 수 있고, A 변수에 대해 읽기 + 쓰기 작업도 있는 경우에는 synchronized와 atomic을 고려해볼 수 있겠네요. 제가 이해한 게 맞을까요?
토스 개발자와 함께하는 Data Workflow Management 기반의 대용량 데이터 처리 설계 패턴
안녕하세요, 좋은 강의 감사드립니다. 강의 내용 중 DAG Top-Level에서 캐싱을 사용해 DB 설정 조회 시 스케줄러 DAG 파싱 리소스를 절약할 수 있다는 부분에 대해 질문이 생겨 글을 남깁니다. 제가 알기로는 Airflow 스케줄러( DagFileProcessorManager )가 주기적으로 DAG를 파싱할 때, 각 DAG 파일마다 새로운 자식 프로세스(PID)를 포크(Fork)하여 처리를 위임하고 파싱이 끝나면 해당 프로세스를 종료하는 것으로 알고 있습니다. 그렇다면 파이썬 메모리에 상주하는 @lru_cache 의 경우, 프로세스가 종료되면 캐시도 함께 사라지게 되어 다음 파싱 주기 때는 캐시 히트가 발생하지 않고 매번 DB에 새로 쿼리를 날리게 되지 않나 생각이 듭니다. 제가 Airflow 스케줄러의 파싱 프로세스 메커니즘을 잘못 이해하고 있는 부분이 있는지 궁금합니다. 만약 제 생각이 맞다면, 현업에서 이처럼 외부 DB 설정을 기반으로 DAG나 Task를 동적으로 생성할 때 스케줄러 부하를 줄이기 위해 주로 어떤 방식 캐싱 또는 시스템을 활용하시는지 조언을 구하고 싶습니다. 감사합니다! # lru-cache # 데이터베이스에서 설정 가져오기 (간단히 표현) def get_configs_from_db(): return [ {"name": "customer_sync", "schedule": "0 1 * * *"}, {"name": "sales_sync", "schedule": "0 2 * * *"} ]
설명중에 @Version 필드를 낙관적 락에서 이용할 수 있어가지고~ 라고 하셧는데 실제 돌려보니 비관적락 2에도 DB 업데이트가 되었습니다. AI 에게 물어보니 @Version 어노테이션이 붙은 필드는 JPA 사용시 @Lock 어노테이션 사용여부 상관없이 업데이트가 된다고 합니다. 혹 다른 qna 에도 같은 내용이 있는지 확인은 모두 안해 보았습니다. ======================== 응, 같은 엔터티 row에 실제 UPDATE 가 나가면 @Version 필드는 증가한다고 보면 돼. 락 방식이 낙관적이든 비관적이든 핵심은 이거야. @Version private Long version; 이 필드가 있는 엔터티가 dirty checking으로 변경 감지 되고, flush/commit 때 UPDATE 대상이 되면 JPA/Hibernate가 version 값을 같이 갱신해. ========================
안녕하세요. 우선 좋은 강의 제작해주신 토비님께 항상 감사하고 있어요. 이제 배운지 1년된 왕초보입니당.. 혼자 배워보면서 개인 프로젝트를 만들고 있는데 JPA를 사용하고 있어요. 제가 궁금한 것이... N+1 관련한 문제입니다. 아 일단 프로젝트 주제는 복식부기 가계부에요. @Entity ... public class Journal extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "ledger_id", nullable = false, updatable = false) @OnDelete(action = OnDeleteAction.CASCADE) private Ledger ledger; ... @OneToMany(mappedBy = "journal", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true) private List<EntryLine> entries = new ArrayList<>(2); ... public EntryLine getEntryLine(EntrySide side) { switch (side) { case CREDIT : this.entries.stream().filter(line -> line.isCredit()).findFirst() .orElseThrow(...); case DEBIT : this.entries.stream().filter(line -> line.isDebit()).findFirst() .orElseThrow(...); default : throw new ... } } ... // Service에서 저장되기 전에 호출 public void validateSavable() { ... validateJournalSave(); } private void validateJournalSave() { AccountType debit = getEntryLine(EntrySide.DEBIT).getAccountType(); AccountType credit = getEntryLine(EntrySide.CREDIT).getAccountType(); if(!this.transactionType.isValidPlacement(debit, credit)) { throw new ... } } } Journal Class에서 EntryLine List에 접근하고 있어요. 그리고 EntryLine Class는 이렇게 생겼어요. @Entity ... public class EntryLine extends BaseEntity { @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "journal_id", nullable = false, updatable = false) private Journal journal; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "account_id", nullable = false) private Account account; ... // private package 접근제어자 사용 // Account는 Category를 참조중이에요. AccountType getAccountType() { return this.account.getCategory().getAccountType(); } } 거래가 저장되기 전에 Journal : validateJournalSave() 에서 this.transactionType에 따라 차변과 대변에 올바르게 위치하고 있는지 검사한 후 저장하고 있는데 이것을 생성과 수정할 때 두 곳에서 사용하고 있어요. Ledger에 5개 Category가 있고, Account는 그 Category를 참조하고 Category에서만 AccountType이 있어요. Journal이 각 EntryLine의 AccountType을 얻기 위해 Journal -> EntryLine -> Account -> Category -> getAccountType() 이렇게 흘러가네요. 이렇게 접근해도 설계상 괜찮은걸까요? Journal을 저장할때는 @Query 사용해서 Fetch Join으로 필요한 Account를 가져오고 있는 상황이에요. Journal이라는 엔티티가 비즈니스 로직 수행을 위해서 다른 엔티티의 필드까지 깊게 참조?? 가져오도록 설계하는게 옳은건지 모르겠어요.
강사님 안녕하세요 아래부터 자세한 설명 없이 코드를 쳤는데 하둡 셋업할때 필수로 입력 해야 하는건가요? export PDSH_RCMD_TYPE=ssh ssh-keygen -t rsa -P "" cat ~/.ssh/id_rsa.pub>>~/.ssh/authorized_keys
volatile 관련해서 자료를 보다 보니, 일부 자료에서는 “CPU 캐시를 우회하는 것이 아니라 happens-before 관계와 메모리 배리어를 통해 가시성과 재정렬 제한을 보장한다”고 설명하더라고요. 골드 답변의 내용과 정반대되는 내용이라 혼란스러워서 어떻게 이해하면 좋을지 질문드립니다.
