PySpark 대규모 텍스트·정규식 처리 — 수십억 로그를 파싱하기

수억 건의 웹 서버 로그가 쌓여 있고, 각 줄에서 IP, 상태 코드, 응답 시간을 뽑아내야 한다고 상상해 보세요. 정규식 몇 줄이면 될 것 같지만, 수십억 건 규모에서는 정규식 패턴 하나를 잘못 쓰면 잡 전체가 멈춥니다(catastrophic backtracking). 이 글은 그 함정을 피하면서 대규모 텍스트를 빠르고 안정적으로 처리하는 PySpark 패턴을 정리합니다.

이 글에서 배우는 것

• Python UDF 대신 JVM 내 내장 정규식 함수를 써야 하는 이유
• Apache 로그처럼 구조가 있는 텍스트를 그룹 패턴으로 파싱하는 방법
• Catastrophic backtracking 이 왜 잡을 멈추는지, 어떻게 피하는지
• NLP 전처리(토큰화·불용어 제거)를 MLlib 으로 처리하는 방법
• 깨진 인코딩·제어문자 처리와 성능 최적화 패턴

1. 첫 원칙 — 정규식도 UDF 말고 내장 함수로

텍스트 처리를 Python UDF 로 하면 느립니다(JVM↔Python 직렬화 + 행 단위). Spark 는 JVM 내에서 동작하는 정규식 내장 함수를 제공합니다. 이걸 쓰세요.

from pyspark.sql import functions as F
 
# ❌ Python UDF (느림)
import re
@F.udf("string")
def extract_ip(line):
    m = re.search(r"\d+\.\d+\.\d+\.\d+", line)
    return m.group() if m else None
 
# ✅ 내장 정규식 함수 (JVM 내 실행, 빠름)
df = df.withColumn("ip", F.regexp_extract("line", r"(\d+\.\d+\.\d+\.\d+)", 1))

(UDF 가 느린 근본 이유는 별도 글 "PySpark UDF가 느린 이유와 Pandas UDF" 참고.)

2. 로그 파싱 — 한 패턴으로 여러 필드

Apache 액세스 로그처럼 포맷이 일정한 텍스트는 캡처 그룹을 활용하면 한 번의 패턴으로 여러 필드를 동시에 뽑아낼 수 있습니다.

# Apache 액세스 로그 파싱
pattern = r'(\S+) \S+ \S+ \[([^\]]+)\] "(\S+) (\S+) [^"]*" (\d{3}) (\d+)'
 
parsed = df.select(
    F.regexp_extract("line", pattern, 1).alias("ip"),
    F.regexp_extract("line", pattern, 2).alias("ts"),
    F.regexp_extract("line", pattern, 3).alias("method"),
    F.regexp_extract("line", pattern, 4).alias("path"),
    F.regexp_extract("line", pattern, 5).cast("int").alias("status"),
    F.regexp_extract("line", pattern, 6).cast("long").alias("bytes"))

팁: 같은 패턴을 regexp_extract 로 6번 호출하면 매번 매칭합니다. 성능이 중요하면 한 번 매칭해 구조체로 받는 방식(또는 from_csv/고정 구분자 split)을 고려하세요. 구분자가 명확하면 정규식보다 split 이 훨씬 빠릅니다.

3. 가장 위험한 함정 — Catastrophic Backtracking

정규식 엔진이 매칭을 시도할 때 실패하면 이전 단계로 돌아가 다른 경우를 시도합니다. 특정 패턴에서 이 되돌아가기가 폭발적으로 늘어나 한 행 처리에 수분이 걸리기도 하는데, 이것이 catastrophic backtracking 입니다.

위험 패턴: 중첩된 수량자 (a+)+,  (.*)*,  (\d+)+$
악성 입력: "aaaaaaaaaaaaaaaaaaaaaaaa!" 같은 거의-매칭
→ 백트래킹이 폭발 → 한 행 처리에 수초~수분 → 잡 멈춤

# ❌ 위험: 중첩 수량자
r"(\w+\s*)+"
 
# ✅ 안전: 구체적 문자클래스, 앵커
r"^\w+(\s\w+)*$"

진단: Spark UI 에서 한 태스크만 끝없이 RUNNING 이고 CPU 가 100% 인데 데이터 스큐가 아니라면, 악성 입력 + 취약 정규식의 backtracking 을 의심하세요. 패턴을 단순화하거나 입력 길이를 제한하세요.

한 문장으로: 중첩 수량자는 수십억 건 중 단 한 행만으로도 잡 전체를 멈출 수 있습니다.

4. 토큰화·정규화 (NLP 전처리)

검색·임베딩·분류를 위한 텍스트 전처리는 MLlib 의 텍스트 트랜스포머나 내장 함수로 합니다.

from pyspark.ml.feature import RegexTokenizer, StopWordsRemover
 
# 정규화: 소문자 + 특수문자 제거
df = df.withColumn("clean",
    F.regexp_replace(F.lower("text"), r"[^\w\s가-힣]", " "))
 
# 토큰화 (정규식 기반)
tokenizer = RegexTokenizer(inputCol="clean", outputCol="tokens",
                           pattern=r"\s+", minTokenLength=2)
df = tokenizer.transform(df)
 
# 불용어 제거
remover = StopWordsRemover(inputCol="tokens", outputCol="filtered")
df = remover.transform(df)

(한국어 다국어 검색 전처리는 별도 글 "특허·법률·논문 검색을 위한 다국어 검색 엔진 설계"에서도 다룹니다.)

5. 인코딩·깨진 문자 처리

실제 현장 데이터를 다루다 보면 깨진 인코딩, 제어문자, 이모지가 예고 없이 섞여 있습니다.

# 제어문자·비인쇄 문자 제거
df = df.withColumn("clean",
    F.regexp_replace("text", r"[\x00-\x1F\x7F]", ""))
 
# 읽기 시 인코딩 지정 (깨짐 방지)
df = spark.read.option("encoding", "UTF-8").text("path")
 
# 깨진 행이 많으면 분리·격리 (별도 글 "중첩 반정형 데이터"의 quarantine 패턴)

6. 성능 패턴

텍스트 처리에서 속도를 높이는 핵심은 비싼 작업을 최대한 늦게, 최소한의 데이터에만 적용하는 것입니다.

# 관심 있는 로그만 먼저 필터 → 그 다음 비싼 파싱
errors = df.filter(F.col("line").rlike(r"\bERROR\b"))
parsed = errors.select(F.regexp_extract(...))

먼저 rlike 로 대상을 줄이고 비싼 추출은 줄어든 데이터에만 적용하는 것이 핵심입니다.

7. 정리

대규모 텍스트 처리의 핵심은 두 가지입니다. 첫째, JVM 내 내장 정규식 함수를 써서 UDF 직렬화 비용을 없애는 것. 둘째, catastrophic backtracking 을 일으키는 정규식을 피하는 것 — 수십억 건 중 단 몇 개의 악성 입력이 취약한 패턴을 만나면 잡 전체가 멈추기 때문입니다. 구분자가 명확하면 정규식보다 split 을, 비싼 파싱 전에는 rlike 필터로 데이터를 먼저 줄이는 습관이 텍스트 파이프라인을 빠르고 안정적으로 만듭니다.

마치며 — 핵심 요약

• UDF 는 쓰지 마세요. 정규식 처리도 내장 함수(regexp_extract, regexp_replace, rlike)로 처리하면 JVM 직렬화 비용 없이 훨씬 빠릅니다.
• 구분자가 명확하면 정규식보다 split 이 빠릅니다. 정규식이 꼭 필요한 곳에만 쓰세요.
• 중첩 수량자는 재앙입니다. (a+)+ 같은 패턴 하나가 수십억 건 파이프라인을 통째로 멈출 수 있습니다.
• rlike 로 먼저 걸러내세요. 비싼 추출 작업은 관심 대상이 된 적은 수의 행에만 적용합니다.
• NLP 전처리는 MLlib 트랜스포머(RegexTokenizer, StopWordsRemover)가 분산 환경에 최적화되어 있습니다.
• 인코딩 문제는 초반에 잡으세요. 읽기 시 인코딩 지정과 제어문자 제거를 파이프라인 첫 단계에 두면 이후 처리가 훨씬 안정적입니다.

텍스트는 지저분하고 정규식은 강력하지만 날카롭습니다. 올바른 도구와 올바른 패턴을 함께 쓰면, 수십억 건의 비정형 데이터도 충분히 다룰 수 있습니다.

이 글은 Spark 3.5 기준으로 작성되었습니다. 대규모 로그·텍스트 파싱 파이프라인 설계가 필요하시면 언제든 문의해 주세요.

— Data Dynamics 엔지니어링 팀