6개월 전에 저는 데이터 관리 시스템의 대해 글을 썼습니다. 당시 우리는 SQL 문 자동 생성 문제로 어려움을 겪고 있었습니다. 며칠이 지나면서 우리는 여러분에게 참고할 수 있을 만큼 큰 진전을 이루었고, 그래서 다시 여기 있게 되었습니다. OLAP 엔진으로 ClickHouse를 Apache Doris로 교체한 이유에 우리는 Doris 기반 OLAP 서비스를 강화하기 위해 LLM(대형 언어 모델)을 채택했습니다. LLM + OLAP 우리의 동기는 SQL 작성의 가파른 학습 곡선에서 내부 직원을 구하는 것이었습니다. 따라서 우리는 LLM을 중간체로 사용했습니다. 자연어 질문을 SQL 문으로 변환하고 실행을 위해 SQL을 OLAP 엔진으로 보냅니다. 모든 AI 관련 경험과 마찬가지로 우리도 몇 가지 마찰을 겪었습니다. LLM은 "필드", "행", "열", "테이블"과 같은 데이터 전문 용어를 이해하지 못합니다. 대신 기본적으로 필드/행/열의 내용인 "기업 소득" 및 "DAU"와 같은 비즈니스 용어를 완벽하게 번역할 수 있습니다. 즉, 분석가가 질문을 입력할 때 필요한 측정항목을 참조하기 위해 정확한 단어를 사용하는 경우에만 제대로 작동할 수 있습니다. 우리가 사용하는 LLM은 추론이 느립니다. 응답하는 데 10초 이상 걸립니다. 토큰으로 수수료를 부과하다 보니 경제성이 문제가 된다. LLM은 대규모 공개 데이터 세트에 대해 교육을 받았지만 틈새 지식에 대한 정보가 부족합니다. 우리의 경우 LLM은 인디 노래에 매우 익숙하지 않기 때문에 해당 노래가 데이터베이스에 포함되어 있어도 LLM이 해당 노래를 제대로 식별할 수 없습니다. 때로는 입력 질문에 적절하고 최신의 법률, 정치, 금융 및 규제 정보가 필요한 경우가 있는데, 이는 교육 데이터 세트나 지식 기반에 포함하기 어렵습니다. 보다 다양한 작업을 수행하려면 LLM을 더 넓은 정보 기반에 연결해야 합니다. 우리는 이러한 문제들을 하나씩 해결해 나가고 있습니다. 1. 의미 계층 문제 1번에서는 LLM과 OLAP 엔진 사이에 의미 계층을 도입합니다. 이 레이어는 비즈니스 용어를 해당 데이터 필드로 변환합니다. 다양한 자연어 표현에서 데이터 필터링 조건을 식별하고 이를 관련된 메트릭과 연관시킨 다음 SQL 문을 생성할 수 있습니다. 그 외에도 의미 계층은 계산 논리를 최적화할 수 있습니다. 분석가가 복잡한 쿼리(예: 다중 테이블 조인)와 관련된 질문을 입력하면 의미 계층은 이를 여러 단일 테이블 쿼리로 분할하여 의미 왜곡을 줄일 수 있습니다. 2. LLM 구문 분석 규칙 LLM 사용 시 비용 효율성을 높이기 위해 메트릭 계산, 세부 기록 검색, 사용자 세분화 등 모든 시나리오의 계산 복잡성을 평가합니다. 그런 다음 규칙을 만들고 복잡한 작업에만 LLM 구문 분석 단계를 적용합니다. 즉, 간단한 계산 작업의 경우 구문 분석을 건너뜁니다. 예를 들어, 분석가가 "주요 음악 플랫폼의 수익을 알려주세요"라고 입력하면 LLM은 이 질문에 여러 측정항목이나 차원만 수반된다는 것을 식별하므로 더 이상 구문 분석하지 않고 SQL 생성 및 실행을 위해 바로 보냅니다. 이를 통해 쿼리 응답 시간을 크게 단축하고 API 비용을 줄일 수 있습니다. 3. 스키마 매퍼 및 외부 지식 기반 틈새 지식으로 LLM을 강화하기 위해 LLM의 업스트림에 스키마 매퍼를 추가했습니다. 스키마 매퍼는 입력 질문을 외부 지식 기반에 매핑한 다음 LLM이 구문 분석을 수행합니다. 우리는 스키마 매퍼를 지속적으로 테스트하고 최적화하고 있습니다. 우리는 외부 지식 베이스의 콘텐츠를 분류 및 평가하고 다양한 수준의 매핑(전체 텍스트 매핑 및 퍼지 매핑)을 수행하여 더 나은 의미 구문 분석을 가능하게 합니다. 4. 플러그인 우리는 LLM을 더 많은 정보 필드에 연결하기 위해 플러그인을 사용했으며 다양한 유형의 플러그인에 대해 다양한 통합 방법을 가지고 있습니다. : 이는 주로 텍스트 파일인 최신 규제 정책을 LLM에 "교육"해야 할 때 특히 유용합니다. 먼저, 시스템은 로컬 텍스트 파일을 벡터화하고, 의미론적 검색을 실행하여 로컬 파일에서 일치하거나 유사한 용어를 찾고, 관련 콘텐츠를 추출하여 LLM 구문 분석 창에 넣어 출력을 생성합니다. 로컬 파일 포함 : 마켓플레이스는 모든 종류의 분야에 맞게 설계된 타사 플러그인으로 가득합니다. 이를 통해 LLM은 광범위한 주제를 다룰 수 있습니다. 각 플러그인에는 고유한 프롬프트와 호출 기능이 있습니다. 입력 질문이 프롬프트에 도달하면 관련 플러그인이 호출됩니다. 타사 플러그인 위의 네 가지 최적화가 완료되면 SuperSonic 프레임워크가 탄생합니다. SuperSonic 프레임워크 이제 이 안내하겠습니다. 프레임워크를 분석가가 질문을 입력합니다. 스키마 매퍼는 질문을 외부 지식 기반에 매핑합니다. 외부 지식 베이스에 일치하는 필드가 있는 경우 LLM에서 질문을 구문 분석하지 않습니다. 대신, 메트릭 계산 공식이 OLAP 엔진을 트리거하여 쿼리를 시작합니다. 일치하는 필드가 없으면 질문이 LLM에 입력됩니다. LLM은 미리 정의된 규칙에 따라 질문의 복잡성 수준을 평가합니다. 간단한 쿼리인 경우 OLAP 엔진으로 직접 이동합니다. 복잡한 쿼리인 경우 의미론적으로 구문 분석되어 DSL 문으로 변환됩니다. 의미 계층에서 DSL 문은 쿼리 시나리오에 따라 분할됩니다. 예를 들어 다중 테이블 조인 쿼리인 경우 이 계층은 여러 단일 테이블 쿼리 SQL 문을 생성합니다. 질문에 외부 지식이 포함된 경우 LLM은 타사 플러그인을 호출합니다. 예: 특정 노래가 버라이어티 쇼에서 연주될 수 있는지 여부에 답하기 위해 시스템은 노래에 대한 세부정보를 위해 OLAP 데이터 웨어하우스를 검색하고 이를 상업적 사용 쿼리 타사 플러그인의 결과와 함께 표시합니다. OLAP 아키텍처 이 프레임워크의 OLAP 부분에 관해 여러 차례의 아키텍처 발전을 거친 후 현재 OLAP 파이프라인은 다음과 같습니다. 원시 데이터는 분석가가 사용자 정의한 태그와 지표로 정렬됩니다. 일관되지 않은 정의를 방지하기 위해 태그와 지표는 통합 관리됩니다. 그런 다음 다양한 쿼리에 대한 다양한 태그 세트와 메트릭 세트로 결합됩니다. 우리는 아키텍처 최적화 경험을 통해 두 가지 주요 내용을 알아냈습니다. 1. 링크 간소화 Apache Doris를 채택하기 전에는 ClickHouse를 사용하여 태그 및 메트릭 계산을 가속화하고 Elasticsearch를 사용하여 차원 데이터를 처리했습니다. 이는 두 개의 분석 엔진이며 두 엔진 모두에 쿼리 문을 적용해야 합니다. 유지 관리 수준이 높았습니다. 따라서 우리는 ClickHouse를 Apache Doris로 교체하고 기능을 활용하여 Elasticsearch 데이터를 Doris에 연결했습니다. 이러한 방식으로 Doris를 통합 쿼리 게이트웨이로 만듭니다. Elasticsearch Catalog 2. 플랫 테이블 분할 OLAP 아키텍처의 초기 버전에서는 데이터를 플랫 테이블에 입력했기 때문에 작업이 까다로웠습니다. 우선, 플랫 테이블은 업스트림의 모든 쓰기 대기 시간을 흡수했으며 이로 인해 데이터 실시간성에 상당한 손실이 발생했습니다. 또 다른 경우에는 플랫 테이블의 데이터 중 50%가 거의 업데이트되지 않는 차원 데이터였습니다. 새로운 플랫 테이블이 나올 때마다 많은 저장 공간을 소비하는 부피가 큰 차원 데이터가 발생했습니다. 따라서 플랫 테이블을 메트릭 테이블과 차원 테이블로 분할합니다. 서로 다른 속도로 업데이트되므로 이를 서로 다른 데이터 모델에 넣습니다. : Apache Doris의 Aggregate Key 모델에 측정항목 데이터를 정렬합니다. 즉, 새 데이터가 SUM, MAX, MIN 등을 통해 이전 데이터와 병합됩니다. 측정항목 테이블 : 이 테이블은 Apache Doris의 고유 키 모델에 있습니다. 즉, 새 데이터 레코드가 이전 데이터 레코드를 대체한다는 의미입니다. 이를 통해 쿼리 시나리오의 성능이 크게 향상될 수 있습니다. 차원 테이블 대부분의 쿼리에는 두 가지 유형의 테이블 모두에서 데이터가 필요하므로 이로 인해 쿼리에 문제가 발생합니까? 걱정하지 마세요. Doris의 롤업 기능을 사용하면 이 문제를 해결할 수 있습니다. 기본 테이블을 기반으로 자동으로 실행하는 롤업 뷰를 만드는 데 필요한 차원을 선택할 수 있습니다. 이를 통해 각 롤업 보기에 대한 태그를 정의할 필요가 없어지고 쿼리 속도가 크게 향상됩니다. GROUP BY 기타 트릭 Apache Doris에 대한 경험을 통해 우리는 몇 가지 다른 기능도 편리하다는 것을 알았으므로 여기에도 나열해 보겠습니다. 1. 구체화된 뷰 구체화된 뷰는 미리 계산된 데이터세트입니다. 특정 차원의 데이터에 자주 액세스해야 할 때 쿼리를 가속화하는 방법입니다. 이러한 시나리오에서는 원래 태그를 기반으로 파생된 태그와 측정항목을 정의합니다. 예를 들어 지표 1, 지표 2, 지표 3을 결합하여 파생 지표를 생성합니다( . 그런 다음 구체화된 뷰를 생성할 수 있습니다. Doris 출시 일정에 따르면 버전 2.1에서는 다중 테이블 구체화된 뷰를 지원할 예정이며, 이를 기대하고 있습니다. sum(m1+m2+m3) 2. Flink-Doris-커넥터 이는 데이터 수집 시 정확히 한 번만 보장하기 위한 것입니다. Flink-Doris-Connector는 체크포인트 메커니즘과 2단계 커밋을 구현하고 관계형 데이터베이스에서 Doris로 자동 데이터 동기화를 허용합니다. 3. 다짐 Flink의 집계 작업 수나 데이터 볼륨이 너무 커지면 데이터 압축에 엄청난 지연 시간이 발생할 수 있습니다. 우리는 수직 압축(Vertical Compaction)과 세그먼트 압축(Segment Compaction)으로 이 문제를 해결합니다. 수직 압축은 컬럼의 일부만 로딩을 지원하므로 플랫 테이블 압축 시 스토리지 소모를 줄일 수 있습니다. 세그먼트 압축은 데이터를 쓰는 동안 너무 많은 세그먼트가 생성되는 것을 방지하고 동시에 쓰는 동안 압축을 허용합니다. 무엇 향후 계획 비용을 절감하고 서비스 가용성을 높이기 위해 새로 출시된 Doris의 스토리지-컴퓨팅 분리 및 클러스터 간 복제를 테스트할 계획이며 SuperSonic 프레임워크 및 Apache Doris 프로젝트에 대한 모든 아이디어와 의견을 수용합니다.
