개발자로 살아남기

[k8s] kopf 라이브러리 - 파이썬 오퍼레이터 라이브러리

hs_seo — Fri, 10 Apr 2026 00:02:35 +0900

Kopf(Kubernetes Operator Pythonic Framework)는 Python을 사용하여 Kubernetes Operator(오퍼레이터)를 매우 쉽고 빠르게 개발할 수 있도록 도와주는 프레임워크입니다.

일반적으로 쿠버네티스 오퍼레이터 개발에는 Go 언어와 kubebuilder가 표준처럼 쓰이지만, Kopf는 Python 특유의 간결함을 살려 복잡한 인프라 로직 없이 비즈니스 도메인 로직에만 집중할 수 있게 해줍니다.

1. 언제 사용하면 좋은가요?

Kopf는 다음과 같은 상황에서 최고의 효율을 발휘합니다.

Python 생태계 활용이 필요할 때: 이미 머신러닝(ML), 데이터 분석, 혹은 자동화 스크립트가 Python으로 작성되어 있어 이를 쿠버네티스 자원과 연동해야 할 때 매우 유용합니다.
빠른 프로토타이핑: 복잡한 Go 언어 설정이나 보일러플레이트 코드 없이, 단 몇 줄의 Python 데코레이터(@kopf.on.create 등)만으로 오퍼레이터를 만들 수 있습니다.
단순한 자동화 도구 개발: 특정 Custom Resource(CR)가 생성될 때 알림을 보내거나, 보조적인 리소스(ConfigMap, Secret 등)를 자동으로 생성하는 정도의 가벼운 오퍼레이터가 필요할 때 적합합니다.
Go 언어 숙련도가 낮을 때: 쿠버네티스 내부 구조는 깊이 몰라도 Python만 안다면 바로 개발에 뛰어들 수 있어 진입장벽이 낮습니다.

2. Kopf의 주요 장점 (이용하면 좋은 이유)

① 직관적인 Pythonic API

Kopf는 핸들러를 정의할 때 Python 데코레이터를 사용합니다. 이벤트 발생 시 실행될 함수를 직관적으로 연결할 수 있습니다.

import kopf

@kopf.on.create('my-custom-resource')
def create_fn(spec, **kwargs):
    print(f"리소스 생성됨! 스펙: {spec}")

② 복잡한 제어 루프(Reconciliation Loop)의 추상화

쿠버네티스 오퍼레이터의 핵심은 "현재 상태를 원하는 상태로 맞추는 것"입니다. Kopf는 리소스의 변화를 감시하고, 에러 시 재시도(Retry)하거나, 상태를 업데이트하는 복잡한 과정을 내부적으로 처리해 줍니다.

③ 풍부한 기능 지원

Timer & Daemon: 특정 주기마다 실행되는 작업(@kopf.timer)이나, 리소스가 존재하는 동안 계속 실행되는 백그라운드 작업(@kopf.daemon)을 쉽게 구현할 수 있습니다.
Events & Logging: Python의 기본 logging을 사용하면 자동으로 쿠버네티스 Event로 기록되어 kubectl describe로 확인할 수 있습니다.
Diff handling: 리소스의 어떤 부분이 변경되었는지 이전 값과 비교하는 기능을 기본 제공합니다.

3. 요약 및 비교

특징	Kopf (Python)	Kubebuilder / Operator SDK (Go)
난이도	매우 낮음 (초보자 권장)	보통 ~ 높음 (학습 곡선 있음)
개발 속도	매우 빠름	초기 설정에 시간이 걸림
성능	보통 (대규모 클러스터에선 부담일 수 있음)	매우 높음 (고성능, 저지연)
생태계	Python 라이브러리 활용 용이	쿠버네티스 표준 도구들과의 통합 우수

결론

"Go 언어에 익숙하지 않거나, Python의 강력한 라이브러리(Pandas, Boto3, Requests 등)를 활용해 쿠버네티스 리소스를 제어하는 관리 도구를 빠르게 만들고 싶을 때" Kopf를 사용하는 것이 가장 좋습니다. 반면, 수천 개의 노드를 관리하는 초고성능 엔터프라이즈급 오퍼레이터를 만든다면 Go 기반의 도구를 고려하는 것이 좋습니다.

[Tools] Event Catalog 란?

hs_seo — Thu, 9 Apr 2026 23:47:23 +0900

현대적인 마이크로서비스 아키텍처(MSA)나 이벤트 기반 아키텍처(EDA)를 구축하다 보면, 어떤 서비스가 어떤 이벤트를 발행하고 구독하는지 파악하기가 매우 힘들어집니다. 이때 필요한 것이 바로 EventCatalog입니다.

https://www.eventcatalog.dev/

EventCatalog - Know how your systems connect - EventCatalog

Turn your distributed architecture into a searchable, visual, AI-queryable source of truth. Self-hosted, open source.

www.eventcatalog.dev

1. EventCatalog란 무엇인가?

EventCatalog는 오픈소스 도구로, 프로젝트의 이벤트, 스키마, 그리고 서비스 간의 관계를 시각화하고 문서화해 주는 정적 사이트 생성기입니다.

쉽게 말해, "우리 시스템에 어떤 이벤트가 돌아다니는지"를 보여주는 전사적 이벤트 사전이라고 이해하시면 됩니다.

주요 특징

Markdown 기반: 개발자에게 친숙한 마도다운 파일로 이벤트 정보를 관리합니다.
시각화: 서비스 간의 흐름(Producer와 Consumer 관계)을 다이어그램으로 보여줍니다.
버전 관리: 이벤트 스키마의 변경 이력을 추적할 수 있습니다.
자동화: 스크립트를 통해 소스 코드나 스키마 레지스트리에서 정보를 자동으로 가져올 수 있습니다.

2. 왜 사용하는가? (해결하는 문제)

파편화된 정보 통합: 코드 여기저기에 흩어진 이벤트 정의를 한곳에서 볼 수 있습니다.
커뮤니케이션 비용 감소: 기획자나 새로 합류한 개발자가 "주문이 완료되면 어떤 데이터가 넘어가나요?"라고 물을 때 이 카탈로그 링크 하나로 답변이 가능합니다.
영향도 분석: 특정 이벤트를 수정했을 때 영향을 받는 서비스가 무엇인지 즉각 파악할 수 있습니다.

3. 어떻게 사용하는가? (기본 흐름)

사용법은 매우 직관적이며, 일반적인 문서화 도구와 유사합니다.

Step 1: 프로젝트 설치

Node.js 환경에서 아래 명령어로 프로젝트를 생성합니다.

npx @eventcatalog/create-eventcatalog@latest my-catalog

Step 2: 이벤트와 서비스 정의

프로젝트 폴더 내의 events 폴더와 services 폴더에 각각 Markdown 파일을 작성합니다.

이벤트 정의 예시 (events/OrderCreated/index.md):
--- name: OrderCreated version: 1.0.0 summary: 고객이 주문을 완료했을 때 발생하는 이벤트 producers: - Order Service consumers: - Inventory Service - Shipping Service --- ### 이벤트 페이로드 (Schema) 이곳에 JSON 스키마나 설명을 작성합니다.

Step 3: 시각화 확인

작성된 파일들을 기반으로 EventCatalog가 자동으로 관계도를 생성합니다.

npm run dev

위 명령어를 실행하면 웹 브라우저에서 서비스 간의 화살표 흐름도(Node Graph)를 확인할 수 있습니다.

4. 실무 활용 팁

자동 생성 도구 활용: AsyncAPI 파일이나 AWS EventBridge, SNS/SQS 설정을 기반으로 Markdown 파일을 자동으로 생성해 주는 플러그인을 사용하면 관리가 훨씬 편해집니다.
CI/CD 통합: 코드가 메인 브랜치에 머지될 때마다 EventCatalog를 빌드하고 정적 호스팅(GitHub Pages, Vercel 등)에 배포하여 항상 최신 상태를 유지하세요.

https://www.eventcatalog.dev/

EventCatalog - Know how your systems connect - EventCatalog

Turn your distributed architecture into a searchable, visual, AI-queryable source of truth. Self-hosted, open source.

www.eventcatalog.dev

[Airflow] Apache Airflow Helm Chart (1.18.0) PostgreSQL 이미지 오류 해결 방법

hs_seo — Tue, 6 Jan 2026 00:05:22 +0900

Apache Airflow Helm Chart 1.18.0 버전을 배포하거나 업데이트하는 과정에서 PostgreSQL 이미지를 불러오지 못하는 오류가 빈번하게 발생하고 있습니다.

1. 문제의 원인

최근 Bitnami는 Docker Hub의 이미지 관리 방식을 변경하면서, 기존 bitnami/postgresql 레포지토리의 구버전 태그들을 대거 삭제하거나 bitnamilegacy로 이동시켰습니다. 이로 인해 Airflow Helm Chart 내부에서 기본값으로 설정된 PostgreSQL 이미지 태그를 찾지 못해 ImagePullBackOff 에러가 발생하게 됩니다.

2. 즉각적인 해결 방법: values.yaml 수정

이미 운영 중이거나 당장 PostgreSQL을 사용해야 한다면, values.yaml 파일에서 이미지 레포지토리를 bitnamilegacy로 명시적으로 변경해 주어야 합니다.

수정 전: (기본 설정 사용 시 에러 발생 가능)
수정 후 (values.yaml):

postgresql:
  image:
    registry: docker.io
    repository: bitnamilegacy/postgresql
    tag: 16.1.0-debian-11-r15

참고: 위 설정은 삭제된 이미지가 아닌, 레거시 보관소에 남아있는 이미지를 직접 지정하여 배포를 정상화하는 방법입니다.

3. 향후 권장 사항: DB 엔진 변경 고려

현재 Airflow 공식 커뮤니티와 차트 관리자들은 이러한 외부 종속성 문제를 해결하기 위해 기본 DB 설정을 SQLite로 변경하거나 다른 대안을 모색하고 있습니다.

장기적인 안정성을 고려한다면 다음과 같은 방향을 추천합니다.

MySQL 또는 외부 PostgreSQL 사용: * Bitnami Helm 차트에 의존하는 내장 PostgreSQL 대신, 직접 관리하는 외부 DB(RDS, Cloud SQL 등)로 연결 설정을 변경하는 것이 프로덕션 환경에서는 가장 안전합니다.
테스트 환경이라면 SQLite 활용:

간단한 테스트나 로컬 개발 용도라면 향후 공식 업데이트에 맞춰 SQLite로 전환하는 것도 방법입니다.

Helm Chart 버전 업데이트 모니터링:

차기 버전에서는 이 이미지 주소 이슈가 해결되어 배포될 예정이므로, 지속적으로 차트 업데이트를 확인하시기 바랍니다.

요약

갑작스러운 이미지 오류로 당황하셨겠지만, repository 경로를 bitnamilegacy/postgresql로 변경하는 것만으로도 당장의 문제는 해결할 수 있습니다. 하지만 Bitnami의 이미지 관리 정책이 계속 변하고 있는 만큼, 중장기적으로는 DB 인프라 운영 전략을 점검해 보시는 것을 권장합니다.

https://github.com/apache/airflow/issues/56498

Missing postgres docker images · Issue #56498 · apache/airflow

Official Helm Chart version 1.15.0 Apache Airflow version 2.9.3 Kubernetes Version 1.32.4 Helm Chart configuration No response Docker Image customizations No response What happened After restart I ...

github.com

[superset] Superset 최신 버전(5.0.0) 설치 중 오류 (Field.init() got an unexpected keyword argument 'minLength')

hs_seo — Wed, 30 Jul 2025 09:07:39 +0900

Ubuntu 22 에 Superset 최신 버전을 설치하는 중에 다음과 같은 오류가 발생하였습니다.

원인은 최신버전에 설치된 객체를 직렬화, 역직렬화할 때 사용하는 marshmarrow가 문제가 되어서 발생하였습니다. 이 컴포넌트를 4.x 버전이 아니라 3.x 버전으로 설치하면 오류가 해결됩니다.

# 수정 버전 설치
pip3 install marshmallow==3.26.1

  File "/opt/superset/lib/python3.10/site-packages/superset/initialization/__init__.py", line 130, in init_views
    from superset.cachekeys.api import CacheRestApi
  File "/opt/superset/lib/python3.10/site-packages/superset/cachekeys/api.py", line 27, in <module>
    from superset.cachekeys.schemas import CacheInvalidationRequestSchema
  File "/opt/superset/lib/python3.10/site-packages/superset/cachekeys/schemas.py", line 20, in <module>
    from superset.charts.schemas import (
  File "/opt/superset/lib/python3.10/site-packages/superset/charts/schemas.py", line 427, in <module>
    class ChartDataAggregateOptionsSchema(ChartDataPostProcessingOperationOptionsSchema):
  File "/opt/superset/lib/python3.10/site-packages/superset/charts/schemas.py", line 433, in ChartDataAggregateOptionsSchema
    fields.List(
  File "/opt/superset/lib/python3.10/site-packages/marshmallow/fields.py", line 709, in __init__
    super().__init__(**kwargs)
TypeError: Field.__init__() got an unexpected keyword argument 'minLength'

https://github.com/apache/superset/issues/33162

Make Superset compatible with `marshmallow>=4.0.0` · Issue #33162 · apache/superset

Bug description On a fresh install of superset, since marshmallow 4.0.0 released https://pypi.org/project/marshmallow/, superset fails to init due to an error validating parameters It is possible t...

github.com

[k8s] ingress contains invalid paths: path /xxx(/I$)(.*) cannot be used with pathType Prefix 오류 수정

hs_seo — Sun, 22 Jun 2025 20:41:02 +0900

K8s 인그레스를 등록할 때 다음과 같은 오류가 발생하였습니다.

one or more objects failed to apply, reason: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: ingress contains invalid paths: path /server-scheduler(/1$)(*) cannot be used with pathType Prefix,admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: ingress contains invalid paths: path /reader(/I$)(.*) cannot be used with pathType Prefix

k8s 의 버전이 업그레이드 되면서 체크가 변경된 것으로 보이며, annotaion 의 use-regex를 추가 하고, pathType을 Prefix에서 ImplementationSpecific 으로변경합니다.

ingress:
    ingressClass: nginx
    annotations:
        nginx.ingress.kubernetes.io/use-regex: "true"
    hosts:
        - host: abc.com
          paths:
              - path: /server-scheduler(/|$)(.*)
                pathType: ImplementationSpecific
    tls:
        - host: abc.com

[github action] 코멘트를 이용하여 작업을 실행하는 방법

hs_seo — Mon, 26 May 2025 23:24:18 +0900

github aciton 에 맞는 yaml 파일을 .github/workflows 아래에 생성합니다.

그리고 pr 을 생성하고, comment 에 /build 를 입력하면 실행됩니다.

name: Build on Comment

on:
  issue_comment:
    types: [created]

jobs:
  build_image:
    # 코멘트가 '/build'이고, PR에 작성된 코멘트인 경우에만 실행
    if: github.event.issue.pull_request && contains(github.event.comment.body, '/build')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub (Optional)
        # Docker Hub에 이미지를 푸시하려면 주석을 해제하고 사용자 이름과 토큰을 설정하세요.
        # Docker Hub 이외의 레지스트리를 사용하는 경우 해당 레지스트리에 맞게 수정하세요.
        # uses: docker/login-action@v3
        # with:
        #   username: ${{ secrets.DOCKERHUB_USERNAME }}
        #   password: ${{ secrets.DOCKERHUB_TOKEN }}
        run: echo "Docker login step skipped for now. Uncomment and configure if needed."

      - name: Build Docker image
        # 'DOCKERHUB_USERNAME/IMAGE_NAME:TAG' 부분을 실제 이미지 이름과 태그로 변경하세요.
        # Dockerfile의 위치가 루트 디렉토리가 아니라면 context와 file 옵션을 수정하세요.
        run: |
          docker build -t my-image:latest .
          echo "Docker image built: my-image:latest"

      # - name: Push Docker image (Optional)
      #   # 이미지를 푸시하려면 주Kk석을 해제하고 이미지 이름을 수정하세요.
      #   # run: docker push my-image:latest
      #   run: echo "Docker push step skipped for now. Uncomment if needed."

      - name: Add reaction to comment
        uses: peter-evans/create-or-update-comment@v4
        with:
          comment-id: ${{ github.event.comment.id }}
          reaction-type: '+1' # 빌드 시작을 알리는 반응 (예:  )

      - name: Comment on build completion (Optional)
        # 빌드 완료 후 코멘트를 남기려면 주석을 해제하세요.
        # uses: peter-evans/create-or-update-comment@v4
        # with:
        #   issue-number: ${{ github.event.issue.number }}
        #   body: |
        #     Image build triggered by @${{ github.event.comment.user.login }} has completed.
        #     Image: my-image:latest
        run: echo "Build completion comment step skipped for now. Uncomment if needed."

[iceberg] 2025년 아이스버그의 한계 요약 (Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025)

hs_seo — Sun, 25 May 2025 21:30:33 +0900

https://quesma.com/blog-detail/apache-iceberg-practical-limitations-2025

Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025 | Apache Iceberg Practical Limitations in 2025

At Quesma we help customers to innovate faster by re-shaping the way applications are built and connected to their DBs. Quesma database gateway enables development teams to modernise and evolve application architecture.

quesma.com

chatgpt 요약

Quesma의 블로그 글 "Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025"에서는 Apache Iceberg의 실용적인 한계점들을 다루고 있습니다. 주요 내용을 요약하면 다음과 같습니다:(quesma.com)

1. 소규모 데이터 환경에서의 비효율성

Apache Iceberg는 Netflix에서 페타바이트 규모의 대규모 데이터를 처리하기 위해 설계되었습니다. 그러나 현재 많은 조직들은 100GB 미만의 데이터 웨어하우스를 운영하고 있으며, 핵심 데이터셋은 수 기가바이트에 불과한 경우가 많습니다. 이러한 소규모 환경에서는 Iceberg의 복잡한 메타데이터 구조와 간접 계층이 오히려 비효율을 초래할 수 있습니다.(위키백과)

2. 쓰기 작업 시 메타데이터 오버헤드

Iceberg에서 단일 행을 업데이트할 때도 새로운 Parquet 파일, 매니페스트 파일, 매니페스트 리스트 파일, 테이블 메타데이터 JSON 등 네 개의 블롭 저장소 쓰기 작업이 필요합니다. 이러한 작업은 각각 수백 밀리초가 소요되어, PostgreSQL과 같은 전통적인 데이터베이스에서는 수 밀리초 내에 완료되는 작업이 Iceberg에서는 수 초가 걸릴 수 있습니다.(quesma.com)

3. 정기적인 컴팩션 필요

쓰기 작업이 누적되면 "파일 폭발(file explosion)" 현상이 발생하여 쿼리 성능이 저하됩니다. 이를 방지하기 위해서는 데이터 및 메타데이터 파일을 정기적으로 컴팩션해야 합니다. 그러나 현재 Iceberg 구현체는 자동 컴팩션 기능이 부족하여, 사용자가 직접 Spark나 Athena를 통해 OPTIMIZE 작업을 수행해야 하며, 이는 추가적인 비용과 복잡성을 초래합니다.(quesma.com)

4. 생태계의 단편화

Iceberg는 언어에 구애받지 않는 사양을 지향하지만, 실제로는 대부분의 프로덕션 코드가 Java 기반으로 실행됩니다. Python(PyIceberg), Rust, Go 등의 포트는 아직 Java 구현체에 비해 여러 릴리스를 뒤처져 있으며, 컴팩션 서비스와 같은 부가 도구도 부족한 상황입니다.

5. 향후 개선 사항

Iceberg의 공동 창립자인 Ryan Blue는 단일 파일 커밋(single-file commit)을 Iceberg Spec V4의 목표로 언급했지만, 2025년 5월 현재 이는 아직 개념적인 단계에 머물러 있습니다.(quesma.com)

이 블로그 글은 Apache Iceberg의 강력한 기능에도 불구하고, 소규모 데이터 환경에서는 오히려 복잡성과 비효율을 초래할 수 있음을 강조합니다. 따라서 조직의 데이터 규모와 요구 사항에 따라 Iceberg의 도입을 신중히 고려해야 하며, 특히 소규모 데이터셋을 다루는 경우에는 기존의 간단한 형식을 유지하는 것이 더 효율적일 수 있습니다.(Medium)

전체 글은 아래 링크에서 확인하실 수 있습니다:

Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025

Don’t Let Apache Iceberg Sink Your Analytics: Practical Limitations in 2025 | Apache Iceberg Practical Limitations in 2025

quesma.com

Gemini 요약

제공해주신 웹페이지는 2025년 아파치 아이스버그(Apache Iceberg)의 실제적인 한계점들에 대해 설명하고 있습니다. 주요 내용은 다음과 같습니다:
빅데이터 우선 설계, 스몰데이터 사용성 개선 필요: 아이스버그는 본래 페타바이트 규모의 느리게 변화하는 데이터셋을 위해 설계되었기 때문에, 더 작은 규모의 데이터셋을 다루는 조직에게는 불편함이 있을 수 있습니다.
쓰기 증폭 후 메타데이터 오버헤드: 아이스버그에서 업데이트는 여러 번의 쓰기 작업을 포함하며, 이는 포스트그레스(Postgres)와 같은 시스템에 비해 느릴 수 있습니다. 이 문제는 업데이트가 많을수록 악화되어 성능 유지를 위해 압축(compaction) 작업이 필요합니다.
압축 및 유지보수 비용: 데이터 및 메타데이터 파일의 정기적인 압축은 성능을 회복하는 데 필수적이지만, 복잡성, 지연, 비용을 추가합니다.
단편화되고 불완전한 생태계: 아이스버그 명세는 특정 언어에 구애받지 않지만, 대부분의 프로덕션 코드는 여전히 자바 스택에 의존하고 있습니다. 다른 언어로의 새로운 포팅은 JVM 참조 구현에 비해 뒤쳐져 있습니다. 또한 일부 쿼리 엔진은 쓰기 지원이 부족하거나 아이스버그 사용 시 성능 격차가 발생할 수 있습니다.
비정형 데이터, 넓은 테이블: 아이스버그는 잘 정의된 스키마에 가장 적합하며, 비정형 데이터와 넓은 테이블(컬럼이 매우 많은 테이블)에는 한계가 있습니다.
거버넌스 및 보안은 대부분 범위 밖: 아이스버그는 데이터 거버넌스나 보안 정책을 직접 처리하지 않으므로, 상위 계층에서 구현해야 합니다.
제한된 쓰기 동시성: 아이스버그의 동시성 모델은 분당 커밋 수를 제한하므로 OLTP(온라인 트랜잭션 처리) 스타일의 워크로드에는 적합하지 않습니다.
제한된 실시간 기능: 아이스버그는 즉각적인 가시성보다 원자적 배치 트랜잭션을 우선시하므로 실시간 또는 거의 실시간 데이터가 필요한 사용 사례에는 덜 적합합니다.
데이터 반출 비용: 클라우드에서 데이터를 옮기는 데 드는 높은 비용은 특정 공급업체에 머무르게 하는 유인이 될 수 있으며, 이는 아이스버그의 이식성이라는 장점을 제한할 수 있습니다.

[ubuntu] crontab 정보가 설정된 파일을 이용한 크론잡 실행

hs_seo — Sun, 25 May 2025 21:18:58 +0900

서버 초기화시 crontab -e 명령을 이용하지 않고, 정보가 설정된 파일을 이용하여 크론잡을 실행할 수 있습니다.

/etc/cron.d/ 아래에 파일을 생성합니다.
이 파일은 crontab -e 로 작성하는 내용과 동일하게 생성하면 되는데, 꼭 실행하는 사용자를 입력해야 합니다.
다음과 같이 실행하고자 하는 사용자 root 를 꼭 입력해야 합니다. 다른 유저로 실행하려면 해당 유저의 이름을 입력하면 됩니다.

# /etc/cron.d/metastore
* * * * * root /usr/local/bin/metastore-script.sh >> /var/log/metastore.log 2>&1

버전에 따라 다를 수 있지만, 파일이 생성되면 크론잡이 주기적으로 파일을 갱신해서 실행합니다. 만약 실행되지 않는다면 크론을 재시작하면 됩니다.

[hbase] phoenix 연계 및 실행 방법

hs_seo — Sat, 17 May 2025 19:06:44 +0900

Apache Phoenix는 HBase 위에서 SQL 쿼리를 사용할 수 있게 해주는 오픈소스 프로젝트입니다.

HBase라는 NoSQL 데이터베이스 위에 RDBMS 스타일의 SQL 인터페이스를 제공하는 레이어입니다.

원래 HBase는 Key-Value 기반의 비정형 테이블이어서 SQL 같은 쿼리 언어가 없는데, Phoenix는 HBase의 데이터를 JDBC를 통해 SQL로 조회하거나 수정할 수 있게 해주는 도구입니다.

설치

HBase 2.6에 Phoenix 5.2.1 을 설치 하는 방법은 ${HBASE_HOME}/lib 아래에 Phoenix 라이브러리를 추가 하면 됩니다. ${PHOENIX_HOME}/phoenix-server-hbase-2.6-5.2.1.jar 의 라이브러리를 ${HBASE_HOME}/lib 아래로 추가합니다.

실행

라이브러리를 추가 하고 나면 HBase 를 재시작해야 합니다. HMaster와 RegionServer 를 재시작하여 실행합니다.

${PHOENIX_HOME}/bin/sqlline.py localhost:2181 와 같이 실행하여 피닉스가 실행되는 것을 확인할 수 있습니다. 피닉스가 실행되면 메타 정보가 자동으로 추가 되고, SELECT 1 명령을 이용해서 동작을 확인할 수 있습니다.

sqlline.py $(hostname -f):2181

CREATE TABLE example_phoenix (
    id INTEGER PRIMARY KEY,
    name VARCHAR,
    age INTEGER
);

UPSERT INTO example_phoenix (id, name, age) VALUES (1, 'Alice', 30);

SELECT * FROM example_phoenix;

오류 상황

2025-05-16 13:32:35,228 INFO  [task-truncated-0] client.RpcRetryingCallerImpl: Call exception, tries=12, retries=46, started=68455 ms ago, cancelled=false, msg=no meta location available, details=row 'SYSTEM.CATALOG' on table 'hbase:meta' at null, see https://s.apache.org/timeout
2025-05-16 13:32:39,621 ERROR [RpcServer.priority.RWQ.Fifo.read.handler=10,queue=4,port=16020] coprocessor.MetaDataEndpointImpl: createTable failed
org.apache.hadoop.hbase.client.RetriesExhaustedException: Cannot get the location for replica0 of region for \x00\x00EXAMPLE_PHOENIX in SYSTEM.CHILD_LINK

피닉스를 실행하면서 이런 오류가 발생하면서 sqlline.py 가 행이 걸리는 오류가 있었습니다. 오류상으로는 통신이 되지 않는 상황 같았지만 리전서버를 재시작하면 다시 동작하였습니다. 라이브러리 추가후 재시작하고, 동작이 이상하면 다시 한번 재시작하면 동작할 수 있습니다.

[java] 객체 생성의 form, of, builder 비교

hs_seo — Sun, 20 Apr 2025 22:44:48 +0900

데이터 객체를 생성할 때 사용하는 from, of, builder 패턴을 비교해 보겠습니다.

of: 엔티티의 필수 데이터를 이용하여 객체를 생성할 때 사용
- 객체 생성에 필요한 필수 인자가 명확하고, 불변 객체를 만들거나 간단한 유효성 검사를 수행하고 싶을 때 유용합니다.

public static User of(String username, String email) { // 필수 필드
    return new User(null, username, email);
}

public static Color of(int red, int green, int blue) {
    return new Color(red, green, blue);
}

from: 다른 객체로부터 객체를 생성할 때 주로 사용
- 다른 객체나 데이터 구조로부터 엔티티 객체를 생성하거나 매핑하는 로직을 명확하게 분리하고 싶을 때 사용합니다.

public static User from(UserDto userDto) {
    return new User(null, userDto.getUsername(), userDto.getEmail());
}

public static Order from(ResultSet rs) throws SQLException {
    return new Order(rs.getLong("id"), rs.getString("orderNumber"), ...);
}

builder: 속성이 많은 객체를 단계별로 생성할 때 사용
- 생성해야 할 객체의 속성이 많거나 선택적인 속성이 많아 생성자의 파라미터가 늘어나는 것을 방지하고, 객체 생성 과정을 더 명확하고 유연하게 관리하고 싶을 때 사용합니다.

public class Computer {
    private String cpu;
    private String ram;
    private String storage;
    private String graphicsCard; // 선택적

    private Computer(Builder builder) {
        this.cpu = builder.cpu;
        this.ram = builder.ram;
        this.storage = builder.storage;
        this.graphicsCard = builder.graphicsCard;
    }

    public static class Builder {
        private String cpu;
        private String ram;
        private String storage;
        private String graphicsCard;

        public Builder(String cpu, String ram, String storage) { // 필수 필드
            this.cpu = cpu;
            this.ram = ram;
            this.storage = storage;
        }

        public Builder graphicsCard(String graphicsCard) { // 선택적 필드
            this.graphicsCard = graphicsCard;
            return this;
        }

        public Computer build() {
            return new Computer(this);
        }
    }

    // Getter 생략

    public static void main(String[] args) {
        Computer myComputer = new Computer.Builder("Intel i7", "16GB", "512GB SSD")
                .graphicsCard("NVIDIA RTX 3060")
                .build();

        Computer basicComputer = new Computer.Builder("Intel i5", "8GB", "256GB HDD")
                .build();
    }
}