impyla 는 Impala 전용 프로토콜이 아니라 HiveServer2(HS2) Thrift 인터페이스 로 통신한다. HS2 프로토콜은 오래 안정적으로 유지돼 왔기 때문에, impyla 버전과 Impala 서버 버전을 일대일로 맞출 필요가 없다. HS2 를 노출하는 Impala 라면 대체로 붙는다.
따라서 "impyla 0.22.0 은 Impala 몇 버전까지 되는가" 라는 질문은 대개 잘못된 방향이다. 실제로 깨지는 것은 서버 버전이 아니라 인증 방식 과 파이썬 쪽 의존 라이브러리 다.
auth_mechanism |
쓰는 경우 |
|---|---|
NOSASL |
인증 없이 열린 HS2 |
PLAIN |
LDAP 아이디 · 비밀번호 |
GSSAPI |
Kerberos |
서버가 기대하는 것과 다르면 연결 단계에서 실패한다. 오류 메시지가 프로토콜 오류처럼 보여 혼동하기 쉽다.
from impala.dbapi import connect
conn = connect(
host="impala.example.com",
port=21050,
auth_mechanism="GSSAPI",
kerberos_service_name="impala",
use_ssl=True,
)
HTTP 엔드포인트(보통 28000)로 붙는 경우는 전송 방식이 다르므로 use_http_transport=True 와 http_path 를 함께 준다. 로드밸런서를 거치는 구성에서 자주 쓴다.
impyla 는 다음에 기댄다.
| 패키지 | 역할 |
|---|---|
thrift |
Thrift 프로토콜 구현 |
thrift_sasl |
SASL 전송 계층 |
bitarray |
결과 처리 |
pure-sasl 또는 kerberos·gssapi |
Kerberos 인증 |
문제의 대부분이 여기서 난다. thrift 와 thrift_sasl 의 조합이 어긋나면 임포트 시점이나 첫 연결에서 알 수 없는 예외가 난다. 다른 패키지(예: 다른 Thrift 기반 클라이언트) 가 thrift 를 다른 버전으로 끌어오면 그 순간 깨진다.
pip install "impyla==0.22.0"
pip check
pip list | grep -Ei 'impyla|thrift|sasl|bitarray'
pip check 는 설치된 패키지 사이의 의존성 충돌을 알려 준다. 문제가 생겼을 때 가장 먼저 돌려 본다.
thrift_sasl 과 SASL 관련 패키지는 C 확장을 빌드한다. 폐쇄망이나 최소 설치 이미지에서는 빌드 도구와 헤더가 없어 설치 자체가 실패한다.
dnf -y install gcc gcc-c++ python3-devel cyrus-sasl-devel krb5-devel
가능하면 wheel 을 미리 받아 두고 오프라인 설치한다.
라이브러리 조합을 한 번 맞췄으면 그대로 박아 둔다. 새 환경에서 다시 맞추느라 시간을 쓰지 않으려면 이것이 가장 확실하다.
impyla==0.22.0
thrift==0.16.0
thrift-sasl==0.4.3
bitarray==2.9.2
버전 번호 자체보다 중요한 것은 "동작을 확인한 조합을 기록해 둔다" 는 점이다. 위 값은 예시이고, 환경에서 실제로 통과한 조합으로 대체한다.
가상환경을 만들어 다른 프로젝트와 섞이지 않게 한다.
python3 -m venv ~/.venv/impala
source ~/.venv/impala/bin/activate
pip install -r requirements.txt
from impala.dbapi import connect
with connect(host="impala.example.com", port=21050, auth_mechanism="GSSAPI") as conn:
cur = conn.cursor()
cur.execute("SELECT version()")
print(cur.fetchall())
Kerberos 를 쓴다면 티켓이 먼저 있어야 한다.
kinit -kt /path/to/user.keytab user@EXAMPLE.COM
klist
fetchall 로 큰 결과를 한 번에 받으면 클라이언트 메모리가 터지고 느리다. 배치 단위로 가져온다.