GraphFDS-02

1. NoSQL

• 앞서 시리즈에서 '관계'가 FDS 에서 왜 중요한지 만일 중요하다면 어떤 부분을 도출할 수 있기에 중요한지에 대해 이야기했습니다. '나'의 관점 뿐만아니라 '나와 관련있는 사람'의 관점을 활용하여 이상 거래를 탐지할 수 있다는 점이 장점이였습니다.

• 여기에서 '관련' 이 있는 사람들을 데이터로 조회하고 분석할 때 물론 시장에서 많이 활용하고 있는 SQL 로도 물론 분석이 가능하나 여러가지 한계점이 존재하기에 NoSQL을 찾게 됩니다. 한계점 중 몇 가지를 이야기해보자면 다음과 같습니다.

• 데이터 스키마 정규화 - 너무 많이 정규화된 데이터 스키마 때문에 무슨 데이터가 어디에 있는지에 대해 확인하기가 상당히 까다롭습니다. 특정 데이터를 추적하기 위해 데이터 명세서를 파악하며 주요키 , 외래키를 파악하며 관계를 생성해야합니다. 물론 잘 명시되어있는 데이터 명세서라면 가능은 하겠으나 반대의 경우에는 관리가 미흡하기 때문에 스키마 추적에서 난항을 겪게 됩니다.

• 관계에 특화된 데이터 구조가 아님 - 테이블을 어떻게 효율적으로 관리할것인가 라는 목적을 기반으로 만들어진 도구이기에, '연결'을 기반으로 분석을 하고자 한 저희와는 다른 목적을 가지고 있습니다.

• 이처럼 '연결' 에 기반하여 관리 및 분석하기 위해선 SQL로는 한계가 있다 판단하여, nosql 가 적합하다 판단했습니다. 다른 데이터베이스 형태들도 물론 '연결' 에 관련하여 무언가를 확인 할 수 있고 매우 쉽지만, 더 나아가 '연결'에 기반 하여 인사이트를 도출하기 위한 상황이 발생한다면 '연결'을 기반으로 분석이 필요한 상황이 발생하기 마련합니다.

• 이를 위해선 '연결'을 위해 다른 무언가의 요소가 추가되기에 오히려 복잡한 코드를 유발하게되어 본래의 데이터베이스 기능 범주를 넘어선 답변을 요구한것이기에 쿼리 실행 속도가 느리고 상당한 자원을 소모하게 됩니다.

• '연결'을 위해 관리 및 분석 하기 위한 적합한 도구로써 GDB 가 자주 언급되곤 하는데요. 바로, 연결을 위한 쿼리들이 잘 작동하게끔 설계된 데이터베이스이기 때문입니다. 데이터 구조 측면에서 요소 간 연결 기반으로 쿼리를 수행할 수 있고, 요소 간 복잡한 관계들의 상호작용을 이해하기에 최적의 환경을 구성해놓았기 때문입니다.

• 그래프 데이터는 '연결'에 대한 인사이트를 도출 후 다시 관계형 데이터베이스의 행으로 인코딩 할 수 있기에 분석한 결과물에 대해 상당히 유연하다는 점 또한 추가적인 장점 중 하나라고 할 수 있습니다.

Summary

- FDS 목적인 '연결','관련'을 기반한 분석은 SQL 보다 NOSQL 이 적합함. 스키마 의존성 , 테이블 정규화 , 관계 특화 구조가 아님 등 한계점들이 존재함, 이를 NoSQL GDB 가 보완할 수 있음.

2. NoSQL 과 GDB 그리고 Neo4j

• 앞선 부분에서 nosql 에 대해 잠시 언급하였고, 연결에 기반하여 분석 및 관리하기 위해선 그래프 데이터 베이스가 효율적이다 라고 말했습니다. RDB의 종류가 여러개 있듯, GDB의 종류 또한 다양한데요. 그 중 저는 Neo4j 를 선택했습니다.

• GDB 다양한 종류가 있는데 왜 neo4j?

1.효율적인 저장구조





 
• 관계를 기반으로 질의하다보면 관계를 역으로 검색하게 되는 경우가 발생합니다. 예를 들어 '나와 관련이 있는 사람과 관련이 없는 사람들' 과 같은 경우는 관련이 있는 사람을 조회했다가 관련이 없는 사람을 조회하기에 조회의 방향이 바뀌게 됩니다. 이럴때는 결국 조회 방향을 추가로 고려해야하기에, 조회를 위한 조회가 발생하게 됩니다. 이러한 상황에도 문제 없이 조회하기 위해 neo4j 에서는 데이터 저장 구조를 방향도 고려한 형태로 만들었고, 이에 추가로 인덱싱도 첨가할 수 있게끔 만들어 두었습니다.
• java 로 엔진이 구성되어있어 여타 c++ 로 엔진이 구성되어 있는 다른 그래프 데이터베이스들보다 속도 측면에서 효율적이지 않은 상황이 발생합니다. 그럼에도 불구하고 저는 native graph storage라는 장점이 그 속도 측면보다 더 메리트있게 보였기에 neo4j를 선택했습니다.
• property graph management 프로퍼티 그래프 관리의 편리성을 고려한 제품답게 최근에는 프로퍼티 타입을 지속적으로 업데이트하며, 대용량 데이터에도 효율적으로 작동할 수 있게 개발되고 있는중입니다. 프로퍼티 그래프를 핵심으로 지원하는 neo4j에서는 프로퍼티를 어떻게 효율적으로 담는지가 최우선일텐데요. 이를 고려한 제품 개발 로드맵 중 한 행보라고 볼 수 있기에 더욱 신뢰가 갑니다.

2.그래프 데이터베이스 완성도

• 제품 버전 출시 기준마다 다르겠으나 현재기준 community , enterprise 5.x 버전이기에, 안정성을 갖추고 있다 라고 생각했습니다. 소프트웨어 생명주기에 대해 각기 생각하시는분들이 다르겠으나,저는 웬만하면 4 버전이상이면 어느정도 안정성을 갖추었다 판단하기에 완성도가 높다 라고 판단하여 선정했습니다.

3.제품 확장성

• 처음부터 그래프로 저장되어있는 데이터들은 드뭅니다. 그러기에, migration 측면에서 tabular -> graph로 변환이 편리한 툴들이 많이 존재하며 이를 확장하여 활용할 수 있는 툴들이 존재한가? 라는 두 가지 의문이 들었습니다. 다시 말해, 마이 그레이션이 편리하고 대용량 데이터를 적재할 시 각기 다른 데이터베이스에 분산 저장하여 관리할 수 있는지에 대한 기술력이 있는지를 고려한 결과 앞 두 요소를 모두 갖추었다 판단하여 선정했습니다.
• Business Warehouse 전용 migration connector , hadoop 에서 자주 활용되고 컬럼기반 데이터 저장형태인 parquet data 데이터 형태를 지원한다. , in-memory data 형태인 arrow 데이터 형태를 지원한다. , spark connector 를 지원하여, pyspark를 활용한 분산처리 분석 및 저장관리가 가능하다.
• 또한, scale out 이 가능하여 데이터 베이스간 효율적인 저장 및 조회 관리가 가능한 composite 가 존재합니다. 타 데이터베이스에서 성격이 유사하나, 관리하는 값이 다르다고 하였을 때 불러오는 형태만 동일하게 맞춰준다면 가상으로 연결을 지어주어 유사한 데이터들간의 숨겨진 패턴을 발견하기에 용이합니다.
• 위 세 가지는 제 주관적인 기준이였고, 아래는 [책 견고한 데이터엔지니어링] 에서 언급한 고려사항을 참조하여 neo4j 제품이 주요 고려 사항에 부합한지 판단해보았습니다.
• 데이터베이스 기술을 이해하기 위한 주요 고려 사항
• 조회
• Q. 데이터베이스는 어떻게 데이터를 발견하고 검색을 수행할까? 인덱스는 조회 속도를 높이는 데 도움이 되지만, 모든 데이터베이스에 인덱스가 있는 건 아니다. 우선 데이터베이스가 인덱스를 사용하는지부터 확인하자. 만약 인덱스를 사용한다면 인덱스를 설계하고 유지 관리하는 가장 좋은 패턴은 무엇일까? 효율적인 추출을 위해 인덱스를 활용하는 방법을 이해하자. 또한 B-tree와 로그 구조 병합 트리(log-structured merge-tree,LSM)을 포함한 인덱스의 주요 유형에 대한 기본 지식도 있으면 도움이 된다
• A. 조회를 위한 index와 constraint 가 있다. index 와 constraint 의 종류가 도합 10가지이상이며, 데이터마다 달라질 특성을 고려하여 다양하고 필요한 요소들만 개발해놓았다. 추가로, full-text indexing 을 위해서 Apache Lucene를 연동하여, 미흡한 부분이라 할 수 있는 full-text indexing 성능에 대해 보완하였다.
• 쿼리 옵티마이저



• Q.데이터베이스는 쿼리 옵티마이저를 사용하는가? 그 특징은 무엇인가?
• A.쿼리 옵티마이저를 사용한다. Cypher 쿼리는 특정 그래프 패턴을 일치시키기 위한 정보를 포함한 문자열로 시작합니다. 이 문자열은 쿼리 파서에 의해 처리되어 내부 표현인 추상 구문 트리 (AST)로 변환되고 확인 및 정리됩니다. 이 AST는 쿼리 옵티마이저, 또는 플래너로도 알려진 것에 의해 수신되며 쿼리의 실행 방법에 대한 계획을 작성합니다.
• 확장과 분산
• Q.수요에 따라 데이터베이스를 확장할 수 있는가? 어떤 확장 전략을 사용하는가? 수평 확장(데이터베이스 노드 증가)인가? 아니면 수직 확장(단일 머신에서 리소스 증가) 인가?
• A. 수평 확장(scale-out) 그리고 수직 확장(scale-up)이 모두 가능하다. 수평 확장을 위해서 composite 라는 모듈이 존재한다. 수직 확장을 위해 conf 를 수정할 수 있고, 이를 추천해주는 명령어 또한 존재하여 OS 성능을 효율적으로 활용할 수 있다.
• CRUD
• Q. 데이터베이스에서 데이트를 쿼리, 생성, 갱신 및 삭제하는 방법은 무엇인가? 데이터베이스 유형에 따라 CRUD 작업은 다르게 처리된다.
• A. 가능하다.
1. Create (생성):
• 노드(Node) 생성: CREATE (:Label {property_name: property_value})
• 관계(Relationship) 생성: CREATE (a)-[:RELATIONSHIP_TYPE]->(b)
2. Read (읽기):
• 노드 조회: MATCH (n:Label) RETURN n
• 관계 조회: MATCH (a)-[:RELATIONSHIP_TYPE]->(b) RETURN a, b
3. Update (갱신):
• 노드 속성 갱신: MATCH (n:Label {property_name: old_value}) SET n.property_name = new_value
• 관계 속성 갱신: MATCH (a)-[r:RELATIONSHIP_TYPE]->(b) SET r.property_name = new_value
4. Delete (삭제):
• 노드 삭제: MATCH (n:Label {property_name: property_value}) DELETE n
• 관계 삭제: MATCH (a)-[r:RELATIONSHIP_TYPE]->(b) DELETE r

Summary

- 시장의 여러 GDB 중 효율적인 저장구조 , 제품 완성도 , 제품 확장성 측면에서 neo4j 가 적합함.

- neo4j 제품이 데이터 엔지니어링 측면에서 부합한지에 대해 CRUD , 확장과 분산 , 쿼리 옵티마이저 , 조회 4가지 측면으로 고려한 결과 그 사항들이 모두 반영되었음을 확인.

- 책에 추가로 일관성 , 데이터 모델링 패턴이 존재하였으나 데이터 모델링 패턴은 앞서 시리즈1에서 언급했기에 생략하겠습니다. 일관성에 대해서는 추가 자료 조사가 필요하여 , 자료 조사 이후 보완토록 하겠습니다.

- 이외에도 neo4j 에 대한 설명할게 많으나, 본 포스팅의 목적은 FDS 와 Graph 이기에 여기에서 줄이고, 다른 섹션을 마련하여 작성토록 하겠습니다.

3. 데이터

• 데이터 분석을 위해 여러 데이터들을 살펴보았습니다. 방대한 데이터 리스트 중 graph , FDS 라는 두 가지 큰 목적을 이루기 위해 몇 가지 기준을 마련해본결과 kaggle- Credit Card Transactions 가 적합하다 판단하였습니다.
• 그 기준은 다음과 같습니다.
• 1.실제 데이터와 유사하게끔 분포 관점으로 접근했는지.
• 논문-Synthesizing Credit Card Transactions에서 데이터를 어떻게 생성했는지 논문 형식으로 출판한 자료가 있기에, 이를 한 번 살펴보고 분포에 대한 유사성을 고려했다 라고 생각했습니다.
• 2.대용량 데이터인지.
• 실제에 비하면 비교할만큼 적은 데이터 용량이긴 하겠으나, 대략 엣지 3천만건 정도의 거래 데이터이기에 공개된 데이터들 중에서는 단연 으뜸이라 생각하여 선정했습니다.
• 3.금융 산업분야에 관련이 있는지.
• '카드','채널','거래내역' 과 같이 여러 데이터들을 조합할 수 있고 '유저'의 정보 그리고 'FICO' 신용도에 대한 정보도 추가로 담겨있어 그 데이터의 특성이 금융과 매우 관련있다 판단하여 선정했습니다.

4. 환경 구축 및 분석

• 본격적으로 데이터를 분석하기 위해선 환경을 구축해야합니다. 단순히 그래프 데이터베이스를 사용하는게 목적이라면, 로컬에 설치하여 활용하는게 맞겠으나 GNN 부터 MLops 까지 파이프라인을 구상하는게 이 시리즈의 최종 목적이기에 도커파일을 구성하여 환경을 구축했습니다.
• dockerfile

# load the foundation image
FROM neo4j:latest

# Set environment variables
ENV NEO4J_AUTH=none \
    NEO4J_PLUGINS='["graph-data-science", "apoc", "apoc-extended"]' \
    NEO4J_dbms_connector_bolt_listen__address=0.0.0.0 \
    NEO4J_dbms_security_procedures_allowlist='gds.*, apoc.*, apoc-extended.*' \
    NEO4J_dbms_security_procedures_unrestricted='gds.*, apoc.*, apoc-extended.*'

# Expose necessary ports
EXPOSE 7474 7687 8491 8888

# Install Python and other dependencies
RUN apt-get update && \
    apt-get install -y python3 python3-pip vim git && \
    apt-get clean && \
    pip3 install -q graphdatascience jupyter neomodel py2neo pyarrow pandas matplotlib ray[default] https://github.com/neo4j-field/checker/releases/download/0.4.0/checker-0.4.0.tar.gz neo4j_arrow@https://github.com/neo4j-field/neo4j_arrow/archive/refs/tags/0.6.1.tar.gz

# Make the workdir of analysis
RUN mkdir /var/lib/neo4j/graphwoody

# Mount volumes
VOLUME /var/lib/neo4j/graphwoody /data /logs /plugins /var/lib/neo4j/import /conf

# Set the working directory
WORKDIR /var/lib/neo4j

# Set up entrypoint
CMD ["neo4j"]

• 위와 같이 도커파일을 작성한 후 docker build -t graphwoody:0.02 .를 입력하게 되면 다음과 같은 도커 이미지가 만들어지게 됩니다.
• 도커 파일을 사용하기 위한 규칙은 다음에서 확인할 수 있으니, 변경이 필요하신 분들은 다음 링크를 확인하시길 바랍니다. dockerfile_argument



• 도커 이미지가 생성되었으면, 도커를 실행시켜야 하는데요. 도커와 로컬 공간을 공유하기 위해 몇 가지 명령어를 추가로 입력해줍니다.

docker run -itd \
  -v /Users/jeong-itae/neo4j/data:/data \
  -v /Users/jeong-itae/neo4j/logs:/logs \
  -v /Users/jeong-itae/neo4j/plugins:/plugins \
  -v /Users/jeong-itae/neo4j/import:/var/lib/neo4j/import \
  -v /Users/jeong-itae/neo4j/conf:/conf \
  -p 7474:7474 \
  -p 7687:7687 \
  -p 8491:8491 \
  -p 8888:8888 \
  --ipc=host \
  --name graphwoody \
  --restart unless-stopped \
  graphwoody:0.02

• 도커 실행시 선언하는 옵션 그리고 커맨드
• data 는 neo4j의 데이터를 보관하기 위해 어떤 index constraint 그리고 노드 엣지 등이 어떻게 얼마나 적재되어있는지가 담겨있는 공간입니다.
• logs 는 neo4j 데이터베이스에서 발생하는 로그들이 기록되는 공간입니다. 쿼리 실행시 트랜잭션이 어떤식으로 실행되고 있는지, 내부 엔진이 어떻게 작동하고 있고 무엇때문에 에러가 발생하는지 등의 정보들을 담고 있기에 매우 중요합니다.
• plugins 는 neo4j에서 활용할 모듈들이 담겨있는 공간입니다. 몇몇 모듈들이 많이 있으나, 저희는 분석을 위한 모듈인 gds , apoc 을 dockerfile 에 작성하여 넣어놓았기에 두 모듈들이 담겨있어 활용이 가능하게 되어집니다. python anaconda 의 lib 와 유사한 공간이라고 보셔도됩니다.
• import는 neo4j 데이터베이스에서 데이터를 입출력 할때 활용하는 공간입니다. 이 공간을 통해 파일을 인지하여 데이터 베이스에 적재하거나 혹은 분석한 결과물들이 출력되는 공간입니다.
• conf는 neo4j 데이터베이스 요소들을 설정하는 파일이 들어있는 공간입니다.
• 7474 , 7687 포트 포워딩은 neo4j 와 로컬을 통신하기 위해 선언했습니다. 이외의 포트들은 지금 활용치 않고 추후에 활용하오니 이후 포스팅에서 설명하겠습니다.
• ipc는 os와 자원을 공유하기 위한 옵션입니다.
• 이외에도, neo4j docker 를 위한 옵션들은 다음 링크에서 확인할 수 있습니다. neo4j_docker_argument
• neo4j 엔진conf
• 도커파일을 실행하여 구동이 시작된 컨테이너로 접속하게 된다면, 도커파일에서 작성한 workdir 인 /var/lib/neo4j 로 접속하게 됩니다.
• ipc 옵션을 통해 host 의 자원을 공유하고 있기에, 이를 최대한 활용하기 위해 앞서 잠시 언급한 neo4j memory recommendation 명령어를 입력합니다.
• neo4j-adim server memory-recommendation을 입력하게 되면 아래의 그림과 같은 출력이 발생합니다. 그 중 빨간색으로 입력한 부분이 neo4j에서 추천해주는 conf 설정 이라고 할 수 있습니다.
• 간단히 그 설정 요소들이 하는 기능을 말씀드리자면, heap 은 데이터베이스에서 활용하는 요소들 / 활용하지 않는 요소들을 판별하는 garbage collector 와 연관되어 있는 요소입니다. pagecache는 쿼리 실행시 그 쿼리 부하를 체크하고 허용치를 설정해주는 요소입니다.
• 간단하게 말하기 위해 요소에 대한 비약이 있을수 있으니, 자세한 내용은 memory-configuration-neo4j를 참조하시는걸 추천드립니다.



• 저희는 이 중 빨간색 부분을 참고하여 conf 파일을 재설정해줄겁니다.
• /var/lib/neo4j/conf에 들어가보면 neo4j.conf 라는 파일이 존재합니다. 이를 vim 으로 들어가 살펴보면 다음과 같은 요소들이 존재하는데요.



• 노란색 박스 요소들은 dockerfile에서 선언한 요소들입니다. conf 에 반영이 되어있는걸보니, 잘 선언되었음을 확인할 수 있습니다. 그리고 빨간색 박스 요소들은 저희가 앞서 확인한 추천 셋팅을 입력한 결과물입니다.
• 이외에도 neo4j conf 에 대한 옵션을 확인하고 싶으신 분들은 neo4j_conf 를 확인하시길 바랍니다.
• constraint
• 데이터 적재 전 노드 엣지의 무결성을 유지하고 품질을 보장하기 위해 규칙 또는 조건을 설정해야합니다. 이를 위해 neo4j 에서는 Constraint 가 존재하는데요. 그 요소들은 가지 각색이며, 그 목적과 효과는 모두 다릅니다. 저희는 그 중 unique constraint 를 활용합니다.
• '카드','유저','상점' 데이터 살펴본 결과 각 데이터마다 고유성을 반영한 key를 발견했기에 그렇습니다. 자세한 내용은 neo4j-constraint에서 확인할 수 있기에, 목적 과 상황 그리고 데이터 타입에 따라 선정하는걸 추천드립니다.
• py2neo
• py2neo 모듈 선언
• python 을 활용해 neo4j 와 통신할 수 있는 모듈입니다. neo4j 에서 py2neo 를 더 이상 maintained 하지 않는다는 최근 이야기 때문에 neomodel 를 추천하고 있는 추세이긴하나, 아직까지는 두 모듈간의 기능과 성능차이가 그렇게 크지않다 판단하여 py2neo를 활용하겠습니다.

from py2neo import Graph, Node, Relationship

HOST = "bolt://localhost:7687"
graph = Graph(HOST, auth=None)

• py2neo 모듈에서 활용할 Graph, Node, Relationship function을 불러옵니다.
• bolt 7687을 통해 python 과 연결할 수 있는 HOST를 변수로 선언해주고, Graph function에 할당하여 graph 로 선언해줍니다.
• 적재
• 적재 방식은 노드 , 엣지 방식이 각각 다릅니다. 먼저 노드 적재방식부터 보자면 다음 코드와 같습니다.
• 노드 적재코드

#1
def create_Cardnode(row):
    node = Node("Card", \
                cardId = row['combinedC'], \
                cardBrand = row['Card Brand'], \
                cardType = row['Card Type'], \
               )
    graph.create(node)

#2 
graph.run("CREATE CONSTRAINT Card_cardId_unique IF NOT EXISTS FOR (x:Card) REQUIRE x.cardId IS UNIQUE")

#3
tmpcard[['combinedC','Card Brand','Card Type']].apply(create_Cardnode, axis=1)

• #1 에서는 cardnode 의 label 과 프로퍼티를 설정해주는 부분입니다.
• #2 에서는 적재 전 constarint 를 선언해주는 부분입니다. Label 과 고유성을 띈 property 를 지정하여 작성합니다.
• #3 에서는 적재할 데이터들이 담긴 pandas.dataframe을 apply 기능을 활용해 node 적재 함수지정하는 부분입니다.
• 엣지 적재코드

#1
def create_cmedge(row):
    src = graph.nodes.match('Card', cardId=row['combinedC']).first()
    dst = graph.nodes.match('Merchant', merchantId=row['Pmer']).first()

    if src and dst:
        relationship = Relationship(src,\
                                    row['relname'],\
                                    dst,
                                    fraud=row['Is Fraud?'],\
                                    amount=row['Amount'],\
                                    date=row['Date'],\
                                    time=row['Time'])
        graph.create(relationship)
#2
tmptx.apply(create_cmedge,axis=1)

• #1 에서는 node 들간 고유 label을 활용해 시작, 끝 노드를 지정해줍니다. 그리고 만일 그 label이 일치한다면 관계를 형성하고, 그 관계들 프로퍼티를 입력해줍니다
• #2 에서는 edge 관계를 담고있는 데이터 프레임형태에 apply 를 통해 함수를 적용해주는 부분입니다.
• 시각화결과
• 적재된 결과를 확인하기 위해 localhost:7474/browser 로 접속합니다.
• 그래프 스키마를 확인하기 위해 call db.schema.visualization 를 입력하면 적재된 데이터를 확인할 수 있습니다.



 

Summary

- neo4j 이미지를 활용해 분석을 위한 도커파일 설명 , 컨테이너 구축 , 적재 그리고 시각화 까지 알아보았습니다. - 내부 데이터 엔진을 효율적으로 활용하기 위해 conf 파일을 튜닝하는 부분을 neo4j 명령어를 통해 추천을 받고 적용해보았습니다. - 데이터 적재 편의성을 위해 python 을 통해 neo4j와 통신이 가능한 모듈인 py2neo을 활용해 적재해보았습니다.