필기

우선 이 시험이 있게 된 사실을 2019년부터 알았습니다. 2020년 초에 제1회 시행 계획이 나왔고, 7-8월에 빅데이터분석기사 관련 참고서로 처음 나온 시대x시 책으로 공부하다가 퀄리티가 너무 안 좋아서 11월에 수x비 책으로 갈아탔습니다. 하루에 1-2시간씩 한 달 간 수x비 책으로 공부했고, 12월 19일에 있을 제1회 빅데이터 분석기사를 대비했습니다.

그러나 왠걸, 코로나 유행으로 1회가 취소되고, 내년 4월에 제2회 시험으로 연기됐습니다. 하는 수 없이 2021년 4월을 기다렸고, 그 사이 ADsP(데이터분석준전문가) 시험 공부를 했는데 지금 생각해보면 이 시험 준비로 빅데이터분석기사 준비도 되었던 것 같습니다. (결과는 떨어졌지만요.)

어쨌든 2021년 4월 17일 필기 시험을 봤습니다. 첫 시험이라 참고서에 없었던 문제도 많았지만, 한편으로는 참고서의 도움으로 풀 수 있었던 문제도 있었습니다. (업데준 모평전, 샘탐수모검, 기준분시평 등을 달달 외웠습니다 ㅋㅋ) 만약 3회 시험도 2회 시험처럼 출제된다고 한다면, 빅데이터이나 머신러닝 외에도 통계학 쪽도 공부하면 좋을 것 같습니다.

실기

필기 시험 결과, 무사히 합격했고, 실기를 준비해야 했습니다. 그러나 실기의 경우에는 참고서도 없어서 어떻게 준비해야 될 지 막막했습니다. 그러나 단답형 예상문제, 작업형 연습문제를 정리해주신 고마운 분이 계셔서 준비를 잘했던 것 같습니다. 단답형 문제의 경우, 빅분기 대비 어플로 공부했고, 전체 문제 파일을 앱 개발자 분께 받아서 정리한 뒤, 달달 외웠습니다. 작업형의 경우에는 캐글의 타이타닉 데이터, 작업형 예시 문제 위주로 연습했습니다. 실제 시험 환경에서는 코드 자동 완성 기능이 없으므로, PyCharm에서 코드 자동 완성 기능을 끄고 연습했습니다.

그렇게 준비하고 6월 19일 시험을 봤더니, 전체적으로 시험이 쉬워서 맥이 풀렸습니다. 단답형은 거의 다 맞을 정도로 풀 수 있었고, 작업형 제1유형은 코드 작성에 버벅이기도 하고, 함수 이름이 생각이 안 나서 help나 dir를 돌리기도 했지만, 어찌어찌 풀 수 있었습니다. 제2유형은 전처리 과정에서 버벅이긴 했지만 해결하니까 나머지는 쉬웠습니다.

소감

그렇게 빅분기 실기 100점으로 마무리했습니다. 최초의 빅데이터 분석기사 자격증 취득자라는 점에 뿌듯하지만, 한편으로는 출제진에 대해 여러 번 실망했습니다. 제 1회 시험 취소 통보를 2-3일 전에 했다는 점, 필기 시험 출제에 여유가 있었음에도 오류가 있었다는 점, 실기 시험 2유형의 채점 기준이 이상하다는 점 등 이게 기사 시험이 맞는 지 의문이 갈 정도였습니다. 이 점은 출제진이 바뀌지 않는 한, 제3회 시험도 말이 많을 것 같네요.

빅데이터분석기사 시험을 보신 분들, 다들 힘든 상황에도 고생 많으셨습니다. 그리고 앞으로 보실 분들에게 이 글이 도움이 되었으면 좋겠습니다.

작업형 제2유형에서 만점이 나올 거라곤 생각 못했다.

출제진의 채점 기준이 심히 궁금하다...

필기에서 많이 데여서, 실기는 여러 방면으로 준비를 했다.

준비

단답형 : DataManim 님의 빅데이터 대비 앱으로 공부. 전체 문제 파일도 받아서 정리한 뒤, 달달 외웠다.

작업형 : 캐글의 타이타닉 데이터, 작업형 예시 문제 위주로 연습했다. 이때, 실제 시험 환경에서는 코드 자동 완성 기능이 없으므로, PyCharm에서 코드 자동 완성 기능을 끄고 연습했다.

그 외 : 오픈카톡방에 들어가 예상 문제와 성능 개선 방안을 공유해가며 준비했다.

시험

전체적으로 쉬웠다. 단답형 : 필기에서 공부했던 것들을 다시 복습해서 그런지, 거의 다 맞을 정도로 풀 수 있었다.

작업형 1유형 : 이상치의 총합, 결측값 제거 전후의 표준편차 차이 등, 데이터를 가공하는 문제 위주로 나왔다. 가끔 코드 작성에 이상이 있어서 버벅이기도 하고, 함수 이름이 생각이 안나 help나 dir를 돌리기도 했지만, 이를 잘 해결할 수 있다면 역시 큰 문제 없이 풀 수 있었다.

작업형 2유형 : 캐글과 같이 실제 데이터셋을 가공하고 분석하여 예측값을 만드는 문제이다. 데이터 분석 전, 전처리 과정에서 2-30분 정도 버벅이긴 했지만, 이를 해결하니 나머지는 쉬웠다. roc-auc 값음 0.669 정도 나왔고, 부분 점수 산출이 어떻게 될 지에 따라 합격 여부가 갈릴 듯 하다.

소감

전공자의 경우, 필기만 잘 통과한다면 실기는 어렵지 않게 풀 수 있을 것 같다. 다만 실무에서는 코드 자동 완성 기능과 검색을 생활화된 반면, 시험에서는 그게 막혔다는 점에서, 시험 환경이 실무 환경과 동떨어져 있는 점은 아쉽다. 검색을 허용하는 대신, 문제를 더 어렵게 내도 좋지 않을까 싶다.

Gu San | Yang Yue

https://github.com/MountainNine/bitcoin_fraud_detection

Introduction

Blockchain is an intelligent P2P network that uses a decentralized database to identify, disseminate, and record information, also known as the Internet of Value. As such blockchain-based cryptocurrencies become known, their demand is increasing even more. However, as the demand, the number of frauds using cryptocurrency is increasing. In this paper, we will look at previous Bitcoin fraud cases and fraud detection tools. Then, we will look at the distribution of user data based on the transaction data. To the end, we analyze the data.

Previous Incidents

1. Value overflow event(August 2010) Essentially, when running the code, if the output is too large to overflow in the summation, then the code that checks Bitcoin transactions will be invalid. The hacker used this to create the block and added two transactions of 92 billion BTC. This is an early example of a cryptocurrency "hard fork", and this is one of the few cases where hackers directly attacked blockchain technology.

2. Bitfinex (August 2016) This is the second largest exchange hacking after the MtGox hot wallet was stolen. Ironically, the upgrade designed to improve security has loopholes and was exploited by hackers. Bitfinex uses the software provided by BitGo to establish a multi-signature system to authorize transactions. It is unclear how hackers can easily bypass the need for multiple keys, but the most commonly accepted assumption is that the system on the Bitfinex server is improperly installed. The hacker stole 120,000 BTC, which was worth 72 million U.S. dollars at the time.

3. Coinrail and Bithumb (June 2018) In June 2018, the hot wallets of two South Korean exchanges were attacked. Among them, Coinrail lost 5,300 BTC (worth 40 million U.S. dollars), and Bithumb lost 31 million U.S. dollars.

Existing Tools

1. PARSIQ PARSIQ is the first blockchain automation platform that allows users to set up "smart triggers" using ParsiQL, its advanced blockchain streaming language. Smart trigger can interact with events on the blockchain. PARSIQ also uses a tool called Mempool, which is a digital asset early warning system. If a major event occurs, such as a large number of digital assets entering the exchange, users will be the first to see it in Mempool.

2. Coral Coral is using blockchain to provide predictive analysis scores to help protect consumers of cryptocurrencies. Coral continuously builds a database of malicious or suspicious phishing scams and related addresses. Coral is integrated into most wallets and user trading interfaces, which means it can warn ICO investors before providing encrypted files to reckless ICO websites.

Dataset

1. Reading Transaction Dataset File The transaction dataset file’s size is 26.8 GB, so it is hard to read the file. First, we split the file with file split program. Obviously, split files were broken, but we found that they have the same json format for each line. So we split the file for 100 lines with Windows command, and created 46 split files.

2. Transaction Construction 1) Merkleroot Merkel root The root of the Merkel tree is the root node of the tree, which is the result of multiple hash calculations of all node pairs in the tree. The block header must include the valid Merkel root calculated from all transaction hashes in the block.

Merkel tree To generate a complete Merkle tree, you need to recursively hash the pair of hash nodes, and insert the newly generated hash node into the Merkle tree until there is only one hash node, which is the root of the Merkle tree. In Bitcoin, leaf nodes come from transactions in a single block.

2) Nonce Headings The changing number at the end of the sentence is called a nonce (random number).

Nonce is used to change the output of the encryption function. There is also a Nonce value in the block header, which records the number of hash recalculations. The Nonce value of the 100,000th block is 274148111, that is, after 274 million calculations, a valid Hash is obtained, and the block can be added to the blockchain.

Random number The random number is a 32-bit (4 byte) field in the Bitcoin block. After the value is set, the hash value of the block can be calculated. The hash value starts with multiple 0s. The values of other fields in the block are unchanged because they have certain meanings.

Excess random number As the difficulty increases, miners usually fail to find a block after cycling the random value 400 million times. Because the coinbase script can store 2 to 100 bytes of data, miners began to use this storage space as an excess nonce space, allowing them to use a larger range of block header hash values to find valid blocks.

3) Previousblockhash Hash of the previous block.

4) Hash content The Hash of each block is calculated for the "block header" (Head) algorithm SHA256 is the Hash algorithm of the blockchain condition Only Hash that meets the conditions will be accepted by the blockchain. This condition is particularly harsh, so that most hashes do not meet the requirements and must be recalculated. length The hash length of the blockchain is 256 bits Corollary 1: The Hash of each block is different, and the block can be identified by Hash. Corollary 2: If the content of a block changes, its Hash will definitely change.

5) Nextblockhash Hash of the next block.

6) Vin(input) Vout(output) In every vin, there is a txid field For every vout, there are 1 field value, field n, and field scriptPubKey.

Value is the amount of money transferred to the other party, and n is the number in the output (that is, the field vout in the corresponding vin when the UTXO is spent next time).

scriptPubKey is the public key of the other party. There are two fields in scriptSig, asm and hex, asm is assembly (assembly, or the meaning of assembly), and hex is its hexadecimal expression.

Script Engine Simply looking at the scriptPubKey is incomprehensible. We need to splice the scriptPubKey with the next scriptSig of the transaction that will cost it. scriptPubKey represents the public key information of the payee; the vin in the next transaction that will spend this UTXO must have the previous information of the private key corresponding to the public key, that is, scriptSig. The two parts are spliced together, with scriptSig in front and scriptPubKey in back (note: scriptPubKey is the current transaction, scriptSig is the next transaction, which will cost this UTXO). Among them, the contents of the two parts of signature and pub key are similar to the asm part in vin above. Because the string is too long, it is omitted here and replaced by. The above string of things is a script, a simple DSL language (about what is DSL, Baidu's own). This string of scripts is thrown into the Script Engine for execution, and the execution result is TRUE/FALSE, indicating whether the person is eligible to spend the money, or whether the transaction is valid.

Processing

1. Transaction Count

Every line has nTx, which saves the number of transactions, and medianTime, which the transaction occured. We saved every nTx value and medianTime. At the result, we knew total transaction count of January 2019 is 9,222,178 counts. Following code express how to save transaction count per day.

def save_transaction():
    median_list = []
    nTx = []

    for i in range(1, 47):
        file_name = "D:\\download\coin\coin{}.json".format(i)
        with open(file_name, 'r') as file_data:
            line = file_data.readline()
            while line:
                data = json.loads(line)
                median_list.append(data['mediantime'])
                nTx.append(data['nTx'])
                line = file_data.readline()

            file_data.close()
            print("coin{} Clear".format(i))

    df_transaction = pd.DataFrame({'medianTime': median_list, 'nTx': nTx})
    df_transaction.to_csv('./transaction.csv', sep=',', na_rep='NaN')

def show_transaction():
    data = pd.read_csv("transaction.csv")
    data['medianTime'] = pd.to_datetime(data['medianTime'], unit='s')
    df = data.groupby(by=data['medianTime'].dt.date).sum()
    y = df.get('nTx')
    plt.bar(df.index, y)
    plt.show()

2. Address Count

In tx(transaction) array of each line, there are addresses that receive Bitcoin, and values of Bitcoin. We extracted those addresses and values, and transaction counts per address in each tx array, and saved to csv file for next processing. Total unique wallet address count of January 2019 is 10,541,781 counts. Following code express to save unique wallet address.

def get_address():
    sum_nTx = 0
    address = set()

    for i in range(1, 47):
        file_name = "D:\\download\coin\coin{}.json".format(i)
        with open(file_name, 'r') as file_data:
            line = file_data.readline()
            while line:
                data = json.loads(line)
                for tx in data['tx']:
                    for vout in tx['vout']:
                        if vout['scriptPubKey']['type'] not in ('nulldata', 'nonstandard'):
                            address.update(vout['scriptPubKey']['addresses'])
                line = file_data.readline()

            file_data.close()
            print("coin{} Clear.".format(i))

    text_file = open('address.txt', 'w')
    for a in address:
        text_file.write(a + "\n")
    text_file.close()

3. Abusing Address There are abusing addresses because of ransomware, fraud, etc. We crawled those abusing users, and compared with previous address data. About 500 addresses are abusing address. Following code represents how we crawled those users, and following graph represents the distribution of abusing address and not abusing address with transaction count and sum of value per address.

def get_abuse_address():
    import pandas as pd
    from bs4 import BeautifulSoup
    import requests
    import time
    import numpy as np

    abuse_addresses = set()

    for i in range(1, 2248):
        page = requests.get("https://www.bitcoinabuse.com/reports?page={}".format(i))
        soup = BeautifulSoup(page.content, "html.parser")
        for s in soup.select("div.col-xl-4 a"):
            abuse_addresses.append(s.contents[0])
        print("{} passed.".format(i))
        time.sleep(1)

    df = pd.DataFrame(abuse_addresses)
    df_address = pd.read_csv('users_new.csv', index_col=False)
    common_address = pd.merge(df, df_address, how='inner', left_on=0, right_on='address')
    df_address['is_fraud'] = np.where(df_address['address'].isin(common_address['address']), 1, 0)
    df_address.to_csv('users_new_2.csv', index=None)

Clustering

We clustered above graph with Gaussian Mixture Model. Gaussian mixture model is a probabilistic model that assumes all the data points are generated from a mixture of a finite number of Gaussian distributions with unknown parameters. Following code and graph is the clustered graph with Gaussian mixture model(n=9).

def gaussian_mixture():
    from sklearn.mixture import GaussianMixture
    import matplotlib.pyplot as plt
    import pandas as pd
    import numpy as np
    import time

    df = pd.read_csv('users_new_3.csv', index_col=False)
    list_gm = pd.DataFrame(map(list, zip(df['count'], df['sum'])))

    gm = GaussianMixture(n_components=9, random_state=0).fit_predict(list_gm)

    plt.scatter(list_gm[0], list_gm[1], s=9, c=gm)
    plt.xscale('log')
    plt.yscale('log')
    plt.show()

purple and yellow clusters tend to have a high proportion of abusing address. It seems the higher transaction count or the higher the value, the higher the probability of fraud.

Conclusion

In this paper, we have investigated the incident about Bitcoin fraud and existing fraud detection tools, Bitcoin transaction of January 2019, and abusing address. Then we have analyzed the distribution of address data with Gaussian Mixture Model Clustering. We tried to cluster with DBSCAN(Density-based spatial clustering of applications with noise), but it had a memory shortage problem, and the clustering result didn’t appear. We will find the outlier based on density on next study.

망했다고 생각했는데, 다행히도 합격했다.

근데 실기는 참고서 같은 것도 없어서 그런지 더 막막하다...

시험에 대해서 복기하고, 내 미련함과 시험에 대해 한탄하는 마음으로 글을 써본다.

시험 소감

시험을 보고 나온 소감은, 확실하게 불합격이라는 느낌이었다.

문제가 어려웠다기 보다는, 내가 준비한 책에서 나오지 않은 문제들이 6할 정도는 됐던 것 같다.

책을 여러 권 보면서 준비했어야 했는데, 그러지 못한 내 불찰이다.

한편으로는 이게 정말 '빅데이터' 분석기사가 맞는지도 의문이다.

기억나는 문제와 다른 사람들이 올린 문제들을 토대로 정리해보자면,

1. 하둡, 빅데이터 관련 소프트웨어 이름을 달달 외웠지만 하나도 안 나왔다.
2. 2과목은 거의 찍다시피 했다. 다른 과목도 그렇지만, 2과목에서 통수를 세게 맞은 기분...
3. 계산 문제가 많이 나왔다.(합성곱 계산, t분포 신뢰도 계산 등)
4. 4과목에서는 혼동 행렬에서 문제가 3-4문제나 나왔던 거로 기억한다.
5. 이건 나중에 안 사실인데, '복수정답일 시 모두 체크하시오.'라는 문장이 유의사항에 있었다고 한다. 1페이지 같이 그냥 넘어갈 부분이 아니라, 문제 부분에 기재했어야 되지 않나?
6. 빅데이터 분석기사인데 3V나 5V 같은 기초개념도 묻지 않은 것도 의외였다.

첫 시험이라 혼란이 있을 거라는 건 예상했지만, 막상 당하고 보니 허탈한 기분밖에 안 든다. 지금은 결과를 기다릴 수밖에......

학창 시절, 맛있는 식사에 행복해하고, 맛없는 식사에 불행을 느낄 때가 많았다. 그러면서 언제나 맛있는 식사가 나오길 바란 적도 많았다.

그렇다면, 전국 초중고 중에서 언제나 내가 가장 맛있어할 식사가 나올 학교는 어디일까? 이를 R을 이용해 분석했다.

데이터셋

나이스 교육정보 개방 포털 에서 전국 모든 학교의 기본 정보 및 급식 정보를 조회할 수 있다. 학교 기본 정보는 csv로, 급식 정보는 학교마다 조회해야 되는 번거로움이 있어, 코드 상에서 API 호출을 통해 가져오도록 했다.

코드 설명

library(httr)
library(jsonlite)
library(dplyr)
Sys.setlocale("LC_CTYPE", ".1251")

API를 호출해서 JSON 형태의 데이터를 가져와야 하기 때문에 httr과 jsonlite 라이브러리를 로드했다.
또한 한글 데이터가 있으므로, 로케일 정보를 .949에서 .1251로 바꿔주었다.

school_info <- read.csv("./school_info.csv", encoding = "UTF-8")
school_info$score <- 0

기존에 다운로드 받은 학교 기본 정보 csv 파일을 불러와서 dataframe으로 저장해준다. 이때, 인코딩 옵션은 UTF-8로 한다.
그 다음, 학교마다 급식에 대한 평균 점수를 저장하기 위해, score 컬럼을 추가한다.

list_pattern <- c("국수|스파게티|[가-힣]*면$|소바|모밀|우동|치킨|[가-힣]*버거|머핀|카스테라|케이크|케익|케잌|파스타|핫도그|도넛|토스트|피자|와플|쿠키",
                   "[가-힣]*(수제비|불고기|가스|까스|스테이크|튀김|구이)$|떡국|[가-힣]*(스프|수프|빵|볶음|볶이)|돼지|닭|쥬스|주스|바나나|딸기|귤|수박|참외|멜론|포도|사과|갈비",
                    "카레$|커리$|(하이|카레|오므|커리|자장|짜장)라이스|비빔밥|볶음밥|만두|필라프|짬뽕|탕수육|훈제",
                  "덮밥|토마토$|[가-힣]*(찜|잡채|샐러드|전|탕|찌개|죽|떡|말이)$|샌드위치|방울토마토|우유|주물럭|두부|커틀릿|커틀렛",
                  "[가-힣]*(밥|김치|깍두기|겉절이)$","[가-힣]*국$|육개장|나물", "[가-힣]*조림$","[가-힣]*(냉채|생채|무침)$")
list_score <- c(3,2,2,1,0,-1,-2,-3)

맛있거나 맛없는 음식재료, 또는 요리를 7점 척도로 나열하고, 정확한 검색을 하기 위해 정규식으로 바꿔주었다.

for (sch_code in school_info[, 3]) {
  df_dish <- NULL
  i <- 1
  while (1) {
    req_url <- paste0("https://open.neis.go.kr/hub/mealServiceDietInfo?KEY=cee31841befb40f8ab6af2c8a856686d&Type=json&ATPT_OFCDC_SC_CODE=B10&SD_SCHUL_CODE=",
                      sch_code, "&pSize=1000&MMEAL_SC_CODE=2&pIndex=", i)
    response <- RETRY("GET", url = req_url, timeout(30), times = 5)
    response <- fromJSON(content(response, as="text"))

학교마다 다른 URL을 호출해야 하므로, 학교 기본 정보의 3번째 열에 있는 학교 코드를 for문을 통해 호출한다.
그리고 각 학교에 저장된 급식의 수가 다르므로, while(1)로 무한반복을 걸었는데,어떻게 탈출하는지는 뒤에 후술하겠다.
요청할 URL은 위와 같다. 여기서는 서울에 있는 학교의 중식만 호출하겠다.
학교 코드와 페이지 수를 변수로 지정했고, 반복문이 돌아갈 때마다 두 변수들이 바뀔 것이다.
마지막으로, 응답 과정에서 timeout error를 방지하기 위해, httr의 RETRY를 통해서 timeout 시간과 반복 횟수를 늘려주었다.

    if ("mealServiceDietInfo" %in% names(response)) {
      df_response <- as.data.frame(response$mealServiceDietInfo$row[2])
      list_dish <- df_response$DDISH_NM
      list_dish_split <- strsplit(list_dish, split = "<br/>")
      list_dish_only_name <- sapply(list_dish_split, function(x) gsub("[0-9]+.", "", x))
      list_dish_final <- lapply(list_dish_only_name, 'length<-', max(lengths(list_dish_only_name)))
      if (is.null(df_dish)) {
        df_dish <- as.data.frame(list_dish_final)
        df_dish <- data.frame(t(df_dish))
        rownames(df_dish) <- seq_len(nrow(df_dish))

      } else {
        temp_dish <- as.data.frame(list_dish_final)
        temp_dish <- data.frame(t(temp_dish))
        rownames(temp_dish) <- seq_len(nrow(temp_dish))
        df_dish <- bind_rows(df_dish, temp_dish)
      }

      i <- i + 1
    } else {
      break
    }
  }

다음은 json에서 가져온 데이터를 가공하는 코드이다. 성공한 json request의 경우, mealServiceDietInfo라는 컬럼명이 포함된다.
만약 데이터가 하나도 없을 경우에는 이 컬럼이 포함되지 않으므로, break를 걸어서 무한루프에서 벗어나게 해준다.
또한 기본적인 급식 데이터의 경우, 다음과 같이 나온다.

영양닭죽(녹두)13.<br/>김말이떡볶이(부식)1.5.6.13.<br/>만두튀김21.5.6.10.12.13.<br/>배추김치9.13.<br/>바나나<br/>급식우유2.

이 데이터에서 br이라 써진 문자열을 구분자로 하여 문자열을 리스트로 변환시켜준다. 그 다음, 정규식을 이용해 요리명 뒤의 숫자와 온점을 없애주고, 이를 df_dish에 저장시킨다. 이때, 기존의 df_dish에 데이터가 있을 경우, temp_dish로 저장시켜 bind_rows 함수로 병합시킨다.

  if (!is.null(df_dish)) {
    rm(list_dish, list_dish_only_name, list_dish_split, list_dish_final)


    df_score <- data.frame(list_pattern, list_score)
    df_dish <- as.data.frame(lapply(df_dish,function(x) gsub('\\([가-힣a-zA-Z0-9\\-\\/ ]*\\)|[\\*\\.\\/\\+\\-\\&\\@][가-힣]*|\\([가-힣]*|\\-[가-힣]*$', "", x)))
    df_dish$score <- 0

    for (j in seq_len(nrow(df_dish))) {
      list_temp <- sapply(df_score$list_pattern, grepl, df_dish[j,], ignore.case = TRUE)
      position <- apply(list_temp, 1, function(a) head(c(which(a), 0), n = 1))
      df_dish[j, "score"] <- sum(df_score[position, "list_score"])
    }

    school_info[school_info[3] == sch_code, "score"] <- mean(df_dish$score)
    rm(list_temp, position)
  }

  print(paste(school_info[school_info$X.U.D45C..U.C900..U.D559..U.AD50..U.CF54..U.B4DC. == sch_code, 4], "complete."))
}

저장된 급식 식단의 개수가 0이 아니라면 요리명에 섞인 불순물(특수문자, 하이픈 등)을 다시 걸러준 다음, score 컬럼을 추가한다.
다시 식단 개수만큼 반복문을 돌려서, df_score에 있는 정규식 패턴에 맞는 요리명을 뽑아와서 list_temp에 저장시킨다.
그 다음, 각 요리명의 row를 구해서, 패턴에 맞는 점수 값들을 해당 row의 score 컬럼에 저장시킨다.
마지막으로, 반복이 끝나면 각 점수들의 평균을 구하여 school_info의 score에 저장시키고,
해당 학교의 점수 산정이 끝났음을 출력한 뒤, 다음 학교로 넘어간다.

결과

school_info 중, 학교명과 평균 점수만 따로 추출해서 본 결과는 다음과 같았다.

점수가 고르게 분포된 것 같지만, 전처리가 제대로 안된건지, 0점도 간간히 보인다.

점수를 기준으로 내림차순으로 정렬해보면, 서울 전체 초중고 중에서, 내 기준으로 서울신성초등학교라는 곳의 급식이 가장 맛있다고 나온다. 그렇다면 실제 급식은 어떨까.

음, 꽤 괜찮아 보이는 식단이다.

느낀 점

서울의 모든 학교의 급식에 대한 데이터를 가져오고, 처리하는 데만 한 학교에 약 3초, 총 1시간 정도가 소요되었다.
이 속도를 개선할 방안을 찾아봐야겠다. 그리고 가장 점수가 낮은 식단을 찾아보니, 생각보다 불순물이 잘 걸러지지 않았다.
정규식 필터를 좀 더 다듬어야겠다.

금융 관련 데이터를 이용해 데이터 분석을 연습해보고 싶어서 데이터를 찾아보던 중, 한국신용정보원에서 제공하는 CreDB 개인신용 교육용DB를 발견했다. (링크)

CreDB는 신용정보원에 저장된 신용정보를 표본추출한 뒤, 이를 비식별 조치하여 교육 목적으로 이용자에게 제공하는 서비스이다. 내가 받은 데이터는 light 버전으로, 2000명의 대출,연체,카드개설정보가 담겨 있다.

연령별 대출액의 대표값

먼저 이 데이터로 연령별 대출액의 대표값을 구하겠다.

library(ggplot2)
library(gmodels)

df_id <- read.csv("./data/ID.csv")
df_loan <- read.csv("./data/LN.csv")
df_delay <- read.csv("./data/DLQ.csv")
df_cdopn <- read.csv("./data/CDOPN.csv")

먼저 라이브러리와 개인신용 데이터를 import한다.

df_id$age <- as.integer((2018 - df_id$BTH_YR) / 10)
df_loan_new <- df_loan %>% group_by(JOIN_KEY, COM_KEY, SCTR_CD, LN_CD_1, LN_CD_2, LN_YM, LN_AMT) %>%
  summarise(YM = max(YM))
df_loan_sum <- df_loan_new %>% group_by(JOIN_KEY) %>% summarise(SUM_AMT = sum(LN_AMT))
df_id_loan_sum <- merge(df_id, df_loan_sum, by="JOIN_KEY", all.y = TRUE)

순서대로 설명하자면 다음과 같다.

1. 기준 년도(2018)와 생년 정보의 차이를 통해 나이를 구한 뒤, 이를 10으로 나누어 연령대를 구한다.

2. 월마다 대출 정보가 중복되기 때문에, dplyr 라이브러리의 group_by 함수에 YM을 제외한 컬럼을 넣어주고, summarise 함수로 YM의 최대값으로 함축시켜준다. 그렇게 하면 기존에 58922개였던 데이터가 5382개로 줄어들 것이다.

3. 중복이 제거된 데이터를 다시 group_by를 통해 JOIN_KEY(회원코드)로 묶어준다. 또한 summarise 함수를 통해, SUM_AMT라는 컬럼을 추가해주고, 회원별로 LN_AMT(대출액)의 합이 되는 값을 넣어준다.

4. 연령대 데이터가 들어있는 df_id와 회원별 대출액의 합이 들어있는 df_loan_sum을 JOIN_KEY를 매개로 merge시킨다. 이때, 대출을 하지 않은 사람이 존재할 수도 있으므로, all.y=TRUE를 주어 RIGHT JOIN을 시킨다.

df_mean_result <- df_id_loan_sum %>% group_by(age) %>%
  summarise(AMT = round(mean(SUM_AMT)), TYPE = "mean")
df_median_result <- df_id_loan_sum %>% group_by(age) %>%
  summarise(AMT = round(median(SUM_AMT)), TYPE = "median")
df_result <- rbind(df_mean_result, df_median_result)

age(연령대)로 그룹화하여, AMT와 TYPE 컬럼을 생성시킨다. 여기서 두 개의 데이터프레임을 생성하는 이유는, 시각화할 때 각 대표값의 차이를 명확히 보이게 하기 위함이다. 처음에 한 개의 데이터프레임에 모두 넣어서 시각화를 시도해봤으나, 잘 되지 않았다. 따라서, 두 개의 데이터프레임에 평균값과 중위값을 각각 넣은 다음, TYPE 컬럼에 평균값이면 mean, 중위값이면 median을 넣어주었다. 마지막으로 rbind 함수로 이 두 데이터프레임을 병합시켰다.

ggplot(df_result, aes(age, AMT, fill=df_result$TYPE)) + geom_bar(stat='identity', position = 'dodge') +
  geom_text(aes(y=AMT,label=AMT))

마지막으로 ggplot을 통해 막대그래프로 시각화시킨 결과, 다음과 같은 그래프가 나왔다. 평균값과 중위값의 차이가 꽤나 크다는 점을 볼 수 있다.

연체액과 연체 기간 상관분석

rm("df_id_loan_sum", "df_loan_new", "df_loan_sum", "df_mean_result", "df_median_result", "df_result")

먼저 위 대표값들을 구하는 과정에서 만든 데이터프레임들을 제거한다.

df_delay_new <- df_delay %>% group_by(JOIN_KEY, COM_KEY, SCTR_CD,DLQ_TYPE, DLQ_CD_1, DLQ_CD_2, DLQ_YM,DLQ_AMT) %>%
  summarise(DLQ_COUNT = n())
df_delay_new$DLQ_AMT <- ifelse(df_delay_new$DLQ_AMT < 500000, df_delay_new$DLQ_AMT, NA)
ggplot(df_delay_new, aes(x=DLQ_COUNT, y=DLQ_AMT)) + geom_point()
cor.test(df_delay_new$DLQ_COUNT, df_delay_new$DLQ_AMT)

group_by와 summarise 함수를 통해 DLQ_COUNT 컬럼(개별 연체 기간)을 포함한 데이터프레임을 생성한다. 그 다음, DLQ_AMT(개별 연체액)과 DLQ_COUNT 컬럼을 산점도로 표시하면 다음과 같다. 이때, 개별 연체액이 1500000인 데이터 때문에 실제와는 다른 결과가 발생할 수 있다. 따라서, 두 번째 줄에서 보이듯이 이상치를 제거해줬다. 이를 산점도로 다시 표시하면 다음과 같고, cor.test 함수로 상관분석을 실행하면 다음과 같은 결과가 나온다.

data:  df_delay_new$DLQ_COUNT and df_delay_new$DLQ_AMT
t = 1.162, df = 880, p-value = 0.2455
alternative hypothesis: true correlation is not equal to 0
95 percent confidence interval:
 -0.02694022  0.10488202
sample estimates:
      cor 
0.0391412 

t검정 값은 1.162가 나오고, p-value(유의확률)의 값은 0.2455로, 95%의 신뢰수준에서 개별 연체액과 개별 연체 횟수 간 상관관계는 낮다고 볼 수 있다.

그렇다면 개인별 총 연체액과 총 연체 기간 간 상관관계는 어떨까. 코드는 다음과 같다.

df_delay_final <- df_delay_new %>% group_by(JOIN_KEY) %>% summarise(DLQ_CNT = sum(DLQ_COUNT), DLQ_AMT = sum(DLQ_AMT))
df_delay_final <- subset(df_delay_final,DLQ_CNT < 100 & DLQ_AMT < 500000)
ggplot(df_delay_final, aes(x=DLQ_CNT, y=DLQ_AMT)) + geom_point()
cor.test(df_delay_final$DLQ_CNT, df_delay_final$DLQ_AMT)

이번에는 개별 연체액의 총합인 DLQ_CNT 컬럼과 개별 연체 기간의 총합인 DLQ_AMT를 포함한 데이터프레임을 생성했다. 이를 산점도로 표시하면 다음과 같다. 여기서도 이상치가 발생하므로, 두 번째 줄처럼 범위를 지정해서 이를 제거해준 뒤, 산점도로 나타내면 다음과 같고, cor.test 함수로 상관분석을 실행하면 다음과 같은 결과가 나온다.

data:  df_delay_final$DLQ_CNT and df_delay_final$DLQ_AMT
t = 4.2706, df = 385, p-value = 2.459e-05
alternative hypothesis: true correlation is not equal to 0
95 percent confidence interval:
 0.1154312 0.3058730
sample estimates:
      cor 
0.2126708 

t-검정 값은 4.2706이고, p-value 값은 2.459e-05으로, 이는 95% 신뢰수준에서 유의수준인 0.05보다 낮다고 볼 수 있다. 따라서 총 연체액과 총 연체 기간 간 상관관계는 있다고 볼 수가 있다.

느낀 점

사실 처음에는 개인신용 데이터를 기반으로 신용점수를 계산해보는 코드를 작성하려 했으나, 생각만큼 잘 되지는 않았다. 만약 데이터에 신용점수까지 포함되어 있었다면 회귀분석을 통해 구할 수 있었을까...

우리가 보는 지하철 노선도는 각 노선별 지하철역들을 한 눈에 볼 수 있게 실제 지도와는 다르게 노선도를 표시한다. 그렇다면 실제 지도에서의 지하철 역의 분포는 어떤지, R을 이용해 시각화해보겠다. 이 작업을 위해 이 글 을 참조했다.

데이터셋

먼저 이 곳 에서 실제 행정구역 공간 데이터를 다운로드할 수 있다. 이 때, 참조한 글에서는 2017년 시군구 데이터를 다운로드 받으라고 했는데, 최신 데이터의 경우에는 구별로 겹치는 포인트가 있어, 코딩 중 오류가 뜨기 때문이라고 한다.

그 다음, 이 곳 에서 실제 지하철역의 위도, 경도 좌표를 다운로드할 수 있다. 여기서 주의할 점으로, 이 csv 데이터에서 5호선 양평역의 좌표가 경의중앙선 양평역의 좌표로 되어 있다는 점이다. 따라서 5호선 양평역의 좌표를 (37.525648,126.885778)으로 수정해줬다.

코드 작성

library(ggmap)
library(ggplot2)
library(raster)
library(rgeos)
library(maptools)
library(rgdal)
Sys.setlocale("LC_ALL",".1251")

먼저 위의 라이브러리들을 import한다. 그 다음, 로케일을 위의 마지막 줄 같이 변경하는데, csv를 읽을 때 한글 데이터가 섞여 있어, 제대로 읽어오지 못하거나 한글이 깨지는 현상이 발생했기 때문이다. 이에 관해 여러 가지 해결법을 시도해보았고, 내 경우에는 시스템의 로케일을 바꾸니 해결되었다.

map <- shapefile("./map/TL_SCCO_SIG.shp")
map <- spTransform(map, CRSobj = CRS('+proj=longlat + ellps=WGS84 +datum=WGS84 +no_defs'))
new_map <- fortify(map, region = 'SIG_CD')
new_map$id <- as.numeric(new_map$id)
metro_map <- subset(new_map, new_map$id <= 11740 | (new_map$id >= 41000 & new_map$id < 42000) | (id >= 28000 & id < 29000 & long >= 126))

다운로드 받은 공간 데이터 중, .shp의 경로를 넣어주고, 참조한 글을 토대로 위와 같이 작성했다. 지하철이 서울에만 운행하는 건 아니기 때문에, 적어도 경기도와 인천은 포함해야 된다. 시도코드가 경기도는 41, 인천은 28이라는 점을 감안하여, 마지막 줄을 추가하여, 경기도와 인천을 포함시켰다.

station <- read.csv("./station_coordinate.csv",
                    na.strings = c("", " ", NA),
                    as.is = TRUE,
                    encoding = "UTF-8")

그 다음, 실제 지하철역 좌표 csv를 읽는다. 그냥 읽어오니 인코딩 관련 에러가 발생했고, encoding=UTF-8 파라미터를 추가해주니, 정상적으로 처리되었다.

ggplot(station, aes(x=lng, y=lat)) + geom_polygon(data = metro_map, aes(x=long, y=lat, group = group), fill='white', color='black') +
  geom_point(aes(color=X.U.FEFF.line))

마지막으로 ggplot 라이브러리로 실제 지하철역들의 위치를 시각화했다. geom_polygon으로 수도권 지도를 그리고, geom_point로 지하철역 위치를 점으로 찍었다. 이 때, 노선별로 다른 색깔의 점을 찍게 했다.

전체 코드와 시각화된 지도는 다음과 같다.

## 1번 코드
library(ggmap)
library(ggplot2)
library(raster)
library(rgeos)
library(maptools)
library(rgdal)
Sys.setlocale("LC_ALL",".1251")

##2번 코드
map <- shapefile("./map/TL_SCCO_SIG.shp")
map <- spTransform(map, CRSobj = CRS('+proj=longlat + ellps=WGS84 +datum=WGS84 +no_defs'))
new_map <- fortify(map, region = 'SIG_CD')
new_map$id <- as.numeric(new_map$id)
metro_map <- subset(new_map, new_map$id <= 11740 | (new_map$id >= 41000 & new_map$id < 42000) | (id >= 28000 & id < 29000 & long >= 126))

##3번 코드
station <- read.csv("./station_coordinate.csv",
                    na.strings = c("", " ", NA),
                    as.is = TRUE,
                    encoding = "UTF-8")

##4번 코드
ggplot(station, aes(x=lng, y=lat)) + geom_polygon(data = metro_map, aes(x=long, y=lat, group = group), fill='white', color='black') +
  geom_point(aes(color=X.U.FEFF.line))

더 좋은 시각화

막상 지도를 봐보니, 실제 노선 색깔과 다르며, 어떤 노선인지 구분이 잘 안되었다. 그래서 3번 코드와 4번 코드 사이에, 다음 코드를 추가했다.

metro_palette <- c('#003DA5','#77C4A3','#0C8E72', '#0090D2','#A17800','#F5A200','#81A914',
                   '#F5A200','#D4003B','#509F22','#B0CE18','#FDA600','#7CA8D5','#ED8B00',
                   '#0052A4','#009D3E','#EF7C1C','#00A5DE', '#996CAC','#CD7C2F','#747F00',
                   '#EA545D', '#BB8336')

그리고 4번 코드를 다음과 같이 바꿨다.

ggplot(station, aes(x=lng, y=lat)) + geom_polygon(data = metro_map, aes(x=long, y=lat, group = group), fill='white', color='black') +
  geom_point(aes(color=X.U.FEFF.line)) + scale_color_manual(values = metro_palette)

그리고 다시 실행해주면 다음과 같은 지도가 나온다.

서울만 시각화

서울, 인천, 경기 지도를 그려보니, 서울은 작게 나오고 지하철역의 점들로 거의 보이지 않았다. 이번에는 서울만 그리고, 지하철역도 서울 부근만 나오게 했다.

먼저 서울만 그리게 하기 위해, 2번 코드의 마지막 줄을 다음과 같이 바꿨다.

metro_map <- subset(new_map, new_map$id <= 11740)

그 다음 서울 부근의 지하철역만 포함시키기 위해, 3번 코드에 다음 코드를 추가했다.

seoul_station <- subset(station, lat>37.41 & lat<37.72 & lng>126.73 & lng<127.27)

포함되지 않는 노선이 생기므로, 서울 부근 노선에 맞는 팔레트를 추가해줬다.

seoul_metro_palette <- c('#77C4A3','#0C8E72','#0090D2','#A17800','#F5A200','#81A914','#D4003B','#B0CE18',
                         '#7CA8D5','#ED8B00','#0052A4','#009D3E','#EF7C1C','#00A5DE', '#996CAC',
                         '#CD7C2F','#747F00','#EA545D', '#BB8336')

마지막으로, 4번 코드를 다음과 같이 수정했다. 이때, geom_point에 size=3을 추가하여, 점 크기도 키워줬다.

ggplot(seoul_station, aes(x=lng, y=lat)) + geom_polygon(data = metro_map, aes(x=long, y=lat, group = group), fill='white', color='black') +
  geom_point(aes(color=X.U.FEFF.line), size=3) + scale_color_manual(values = seoul_metro_palette)

그리고 실행해주면, 다음과 같은 지도가 나온다.

느낀 점

지도 시각화보다 한글 인코딩 처리 과정에서 가장 힘들었다. 그리고 노선별 색깔 매핑에서 노선명 정보에 맞는 색깔을 매핑시키고 싶었지만, 실패하고 순서대로 색깔을 집어넣었다. 여러 가지로, 아직은 많이 부족함을 느꼈다.

로또를 사는 누구나 일확천금을 꿈꾸며 자신이 가지고 있는 번호들이 당첨번호와 일치하길 바란다. 혹자는 지난 회차들의 당첨번호를 보면서 많이 나온 번호들 또는 반대로 적게 나온 번호들로 로또 번호를 찍기도 한다. 이 글에서는 지난 회차들에서 가장 많이 나온 번호와 가장 적게 나온 번호를 나열하고, 이들의 확률이 균일한 편인지 검정해볼 것이다.

데이터 수집

2021년 1월 13일 기준으로 현재까지 총 944번의 로또 추첨이 시행되었다. 이 당첨 번호들은 동행복권(dh.lottery.co.kr)에서 제공하는 api를 호출하여 가져와서 csv로 저장했다. 코드는 다음과 같다.

library(httr)
library(jsonlite)
basic_url <- 'https://www.dhlottery.co.kr/common.do?method=getLottoNumber&drwNo='
df_lotto_num <- NULL
for (x in 1:944) {
  req_url <- paste0(basic_url, x)
  df_response <- as.data.frame(fromJSON(req_url))
  df_sub <- subset(df_response, select = c("drwNo", "drwtNo1", "drwtNo2", "drwtNo3", "drwtNo4", "drwtNo5", "drwtNo6", "bnusNo"))
  if(x == 1) {
    df_lotto_num <- df_sub
  } else {
      df_lotto_num <- rbind(df_lotto_num, df_sub)
  }
  print(paste(x , "crawled."))
}
write.csv(df_lotto_num, "./lotto.csv")

전처리

lotto.csv에서 데이터를 읽어와서, 각 회차별 보너스 번호를 제외한 6개의 번호들만 추출한다. 그 다음, 1~6번째 번호별로 1부터 45까지의 번호가 얼마나 나왔는지 total() 함수로 집계한 뒤, 이를 다시 합쳐서 집계했다. 코드와 집계된 데이터프레임은 다음과 같다.

df_lotto_num <- read.csv("./lotto.csv")
df_lotto <- subset(df_lotto_num, select = c("drwtNo1", "drwtNo2", "drwtNo3", "drwtNo4", "drwtNo5", "drwtNo6")) #보너스 번호는 제외
df_count <- apply(df_lotto, 2, table)
df_sum <- NULL
for(item in df_count) {
  if(is.null(df_sum)) {
    df_sum <- as.data.frame(df_count$drwtNo1)
  } else {
    df_item <- as.data.frame(item)
    df_sum <- rbindlist(list(df_sum, df_item))[,lapply(.SD, sum, na.rm=TRUE), by = Var1]
  }
}
df_sum

##     Var1 Freq
##  1:    1  132
##  2:    2  124
##  3:    3  126
##  4:    4  129
##  5:    5  128
##  6:    6  118
##  7:    7  125
##  8:    8  127
##  9:    9   95
## 10:   10  131
## 11:   11  128
## 12:   12  135
## 13:   13  134
## 14:   14  133
## 15:   15  127
## 16:   16  123
## 17:   17  136
## 18:   18  137
## 19:   19  130
## 20:   20  132
## 21:   21  125
## 22:   22  107
## 23:   23  113
## 24:   24  124
## 25:   25  122
## 26:   26  125
## 27:   29  114
## 28:   35  115
## 29:   27  139
## 30:   28  117
## 31:   30  112
## 32:   31  127
## 33:   32  110
## 34:   33  131
## 35:   34  146
## 36:   36  126
## 37:   37  128
## 38:   38  127
## 39:   39  136
## 40:   40  134
## 41:   41  114
## 42:   42  123
## 43:   43  140
## 44:   44  126
## 45:   45  133
##     Var1 Freq

시각화

먼저 로또 번호별 등장 개수를 막대 그래프로 시각화해봤다.

library(ggplot2)

ggplot(df_sum, aes(df_sum$Var1, df_sum$Freq))+geom_bar(stat = 'identity')

이 등장 개수들을 오름차순으로 다시 정렬해보면,

ggplot(df_sum, aes(x=reorder(Var1, Freq), y=Freq))+geom_bar(stat = 'identity')

34번이 가장 많이 등장했고, 9번이 가장 적게 등장했음을 알 수 있다.

검정

지금까지 나온 번호들이 모두 균일하게 나왔는지에 대해, 카이제곱검정을 통해 검정할 수 있다. chisq.test() 함수로 검정해 본 결과,

chisq.test(df_sum$Freq)

## 
##     Chi-squared test for given probabilities
## 
## data:  df_sum$Freq
## X-squared = 32.552, df = 44, p-value = 0.8985

카이제곱 값(X^2)은 32.552, 자유도(df)는 44, 유의확률(p-value)는 0.8985의 값이 나왔다. 이때, 신뢰수준을 95%로 가정하면, 유의수준(alpha level)은 0.05가 되고, 이는 유의확률보다 매우 작다. 다시 말해, 95%의 신뢰 수준에서, 로또 당첨번호별 등장 확률은 균일하다고 볼 수 있다.

결론

어느 번호가 더 많고, 어느 번호가 더 적게 나왔지만, 그럼에도 번호별 등장 확률은 균일하다는 검정이 나왔다. 아무래도 로또 1등이 되는 방법은 하늘에 기도하는 방법밖에 없는 모양이다 :(