1-1 빅데이터의 정착
'분산 시스템의 발전'과 '클라우드의 서비스의 보급'에 따라
대량의 데이터를 효율적으로 처리하는 일이 어렵게 되면서 분산처리가 발달되었다..
분산 시스템에 의한 데이터 처리의 고속화
- 빅데이터의 취급하기 어려운 점을 극복한 두 가지 대표 기술
일단 현대에 들어오면서 대량의 데이터를 작은 회사에서도 다룰 수 있는 기회가 많아지고
그 데이터 안에 새로운 가치를 창출하거나 의사 결정을 위해 이용하는 일이 보편화되었다고 말할 수 있다.
가장 대표적으로 클라우드 가 발전함에 따라 회사에 규모에 의해 좌우되었던 infrastructure 가
극복 되면서누구라도 대용량 데이터를 다룰 수 있는 기회가 주어졌음 물론 돈만 있다면 ㅎ
빅데이터를 취급하기 어려운 이유는 2가지라고 볼 수 있다
- 데이터 분석 방법을 모른다
- 데이터 처리에 수고와 시간이 걸린다
즉 이말은 데이터 가 있어도 방향성을 가지고 니즈에 맞춰 가치를 창조하지 못하면 의미가 없고
지식이 있어도 시간을 많이 소비한다면 할 수 있는 것은 한정된다
이 2가지는 자전거의 바퀴와 같아서 두 가지를 갖추고 나서야 비로소 가치 있는 정보를 얻을 수 있다..
이 말은 결국 내가 또는 조직이 데이터를 가지고 있더라도 상황에 맞춰서 데이터의 가치를 뽑을 수 있는
도메인 능력 니즈에 맞춰 시각화를 하여 데이터의 가치를 증명할 수 있는 분석 능력이 가장 중요하여
이 두개가 올바르게 있어야 데이터의 가치를 올바르게 뽑아낼 수 있다는 말이다
이것 또한 맞는 말인 게
내가 항만 물류를 모르는 상태에서 데이터를 받았을 때
이 데이터가 정말 가치 있는 데이터인가 아닌가 를 알 수 있는지를 모르는 것이다
그러면 한 가지 궁금한 게 알고 싶은 정보가 이미 있다는 전제하에 어떻게 효율적으로 실행할 것인가..?
위에서도 말했듯이 너무 많은 시간을 소비하는 것도 할 수 있는 것이 매우 한정된다
그러면 가능한 적은 노력으로 할 수 있는 기술들이 뭐가 있는지 한번 살펴보자
빅데이터 기술의 요구 (Hadoop과 NoSQL의 대두)
빅데이터 기술에서 가장 먼저 예를 들을 수 있는 것은 Hadoop과 NoSQL이다.
하둡은 다수에 컴퓨터에서 다량의 데이터를 처리하기 위한 시스템이라고 할 수 있다
이 하둡은 구글에서 개발된 분산처리 프레임워크인 MapReduce를 참고해서 야후에서 만들었다
하지만 이 하둡을 사용하려면 Java를 알고 있어야 해서 진입 장벽이 있었음
그래서 SQL과 같은 쿼리 언어를 Hadoop에서 실행하기 위한 소프트웨어로 hive가 개발되어 2009년에 출시되었다
NoSQL은 전통적인 RDB의 제약을 제거하는 것이 목표로 한 db의 총칭이라고 할 수 있다 다양한 종류가 있는데
- key - value 형태 (Key-Value-Store [KVS])
- Cassandra DB
- JSON과 같은 복잡한 데이터를 저장하는 Document Strore
- MongoDB
- 여러 키를 사용하여 높은 확장성을 제공하는 wide-colume-strore
- HBase
Nosql DB들은 각자 추구하는 방향이 다르기 때문에 단순 비교는 어렵지만 RDB 보다 고속으로 읽기, 쓰기가 가능하다
분산 시스템의 비즈니스 이용 개척
이것은 쓸 내용은 얼마 없는데 감명 깊은 내용을 찾아냈다
분산 시스템에 발전에 따라 기존이라면 DW(Data Warehouse) 이하 DW이라고 부름 ) 도 hadoop를 사용하는 일 이 증가했다는 것이다 초기에는 데이터가 쌓여 갈수록 DW의 부하 가 기하급수적으로 늘어났는데 hadoop의 등장으로 DW의 부하가 많이 줄어들자
기술적으로 지원하는 비즈니스가 성립되었는데 이때 사용하게 된 키워드가 빅데이터였다는 것이다..
그리고 클라우드의 발전에 따라서 더욱더 빅데이터의 처리 능력이 올라가면서 활용이 증가했다고 볼 수 있다
1-2 빅데이터 시대의 데이터 분석 기반
데이터 파이프 라인이란 일반적으로 차례대로 전달해 나가는 데이터로 구성된 시스템을 말한다
이 파이프라인은 어디에서 데이터를 수집해서 무엇을 실현하고 싶은지에 따라 변화한다
즉 내가 또는 조직이 뭘 하고 싶냐 에 따라 달라진다는 것이다.
간단하게 도 끝날 수 있지만
하고 싶은 일이 많으면 그만큼 복잡성이 증가한다
데이터 수집 (벌크 형 스트리밍)
데이터 파이프라인을 일단 데이터를 모으는 부분부터 시작함 이건 당연한 거임
지금 같은 여러 환경에서 데이터가 쏟아지는데 데이터가 들어오는 곳이 정해져 있다고 말할 수 있는 가? 절대로 없다
데이터 전송은 두 가지
- 벌크(bulk) 형
- 일괄 처리
- 스트리밍(streaming) 형
- 지속적으로 처리
스트림 처리는 장기적인 데이터 분석에는 적합하지 않은 문제가 있음
1년간 데이터를 분석하라고 하면 데이터 양은 단번에 수천 배 혹은 수만 배로 증가하는데 이때
실시간데이터 처리와 장기적인 데이터 분석 결과를 하나로 묶는 건 불가능함
그래서 데이터를 처리하기 위한 다양한 처리 방식이 있는데
ETL ELT 가 있다 이건 내가 따로 블로그 글을 올려놨으니 이걸 확인해 주세요 잇힝 ~ㅎ
데이터 레이크
빅데이터 시대 가 되면서 ETL 프로세스 자체의 한계점을 느낌 모든 데이터는 DW를 가정해서 만들어지지 않는 다
그래서 일단 데이터를 축적해 두고 나중에 뽑아 쓸 때 필요에 따라 가공하는데 이것이 여러 곳에서 데이터가 흘러들어 오는 데이터를 호수에 비유해 데이터 레이크라고 부름
근데 이 데이터 레이크는 단순한 스토리지 (aws의 s3가 대표적이다) 이거 하나만으로는 데이터를 가공하기 힘들다
그래서 일단 일회성으로 데이터를 분석을 하영 애드혹 분석이라고 하는데 sql를 직접 작성해서 실행하더나 시트 같은 걸 확인해서
그래프를 그려보고 진행하고 해 보고 괜찮다 싶으면 진행하는 것 도 있다.
1-3 스크립트 언어에 의한 특별 분석과 데이터 프레임
데이터는 다양한 장소에 존재하며 그것을 수지바는 과정에서 스크립언어가 자주 사용한다
전처리르 하는 데는 python이 최고죠! 이건 동의어 보감 할 거임..!! 왜 좋은지는 생략하겠다
한번 실습해 보자..
웹 서버의 액세스 로그의 예 -- pandas dataframe으로 간단히 처리
1. 정규식 parsing을 해보자
일단 로그 포맷은 다음과 같다
214.155.43.28 - - [08/May/2023:23:04:33 ] "GET /app/main/posts HTTP/1.0" 200 5010
174.156.117.140 - - [08/May/2023:23:07:18 ] "GET /wp-content HTTP/1.0" 200 4934
50.187.16.222 - - [08/May/2023:23:10:46 ] "DELETE /wp-content HTTP/1.0" 200 4970
113.87.89.254 - - [08/May/2023:23:11:40 ] "GET /app/main/posts HTTP/1.0" 200 4963
178.152.79.149 - - [08/May/2023:23:16:22 ] "PUT /posts/posts/explore HTTP/1.0" 200 4984
152.214.9.254 - - [08/May/2023:23:17:19 ] "POST /wp-admin HTTP/1.0" 200 5026
이 로그 포맷을 정규식을 이용해서 파싱 하도록 한다 일회성으로 로그를 처리함으로 generate를 사용했다
import re
import pandas as pd
from typing import *
patterns = re.compile(r'^\S+ \S+ \S+ \[(.*)\] "(.*)" (\S+) (\S+)$')
def parsing_preprocessing(path: pd.DataFrame) -> Generator[str, None, Any]:
for line in open(path):
for m in patterns.finditer(line):
print(m)
yield m.groups()
path: str = 'access_log_20230508-230002.log'
columns: List[str] = ["time", "request", "status", "byte"]
df = pd.DataFrame(parsing_preprocessing(path), columns=columns)
# 결과값
time request status byte
0 08/May/2023:23:04:33 GET /app/main/posts HTTP/1.0 200 5010
1 08/May/2023:23:07:18 GET /wp-content HTTP/1.0 200 4934
2 08/May/2023:23:10:46 DELETE /wp-content HTTP/1.0 200 4970
3 08/May/2023:23:11:40 GET /app/main/posts HTTP/1.0 200 4963
4 08/May/2023:23:16:22 PUT /posts/posts/explore HTTP/1.0 200 4984
... ... ... ... ...
47284 07/Aug/2023:01:49:36 GET /wp-admin HTTP/1.0 200 4876
47285 07/Aug/2023:01:50:12 DELETE /search/tag/list HTTP/1.0 200 4931
47286 07/Aug/2023:01:54:05 GET /wp-content HTTP/1.0 200 5004
47287 07/Aug/2023:01:57:40 GET /wp-content HTTP/1.0 200 4906
47288 07/Aug/2023:02:00:34 PUT /list HTTP/1.0 200 4970
[47289 rows x 4 columns]
데이터 가공 표준 시간 포맷으로 변경
df = pd.DataFrame(parsing_preprocessing(path), columns=columns)
df["time"] = pd.to_datetime(df["time"], format='%d/%b/%Y:%X', exact=False)
# 결과
time request status byte
0 2023-05-08 23:04:33 GET /app/main/posts HTTP/1.0 200 5010
1 2023-05-08 23:07:18 GET /wp-content HTTP/1.0 200 4934
2 2023-05-08 23:10:46 DELETE /wp-content HTTP/1.0 200 4970
csv까지 저장하자 시각화를 해보니깐
import pandas as pd
import plotly.graph_objects as go
import matplotlib.pyplot as plt
df1 = pd.read_csv("access_log.csv", parse_dates=['time'])
df2 = df1.set_index("time")
df3 = df2['2023-05-08': '2023-08-07']
log_data3 = df3.resample("1d").size()
print(log_data3)
# time
# 2023-05-08 19
# 2023-05-09 537
# 2023-05-10 514
# 2023-05-11 521
# 2023-05-12 523
# ...
# 2023-08-03 538
# 2023-08-04 526
# 2023-08-05 508
# 2023-08-06 535
# 2023-08-07 49
# Freq: D, Length: 92, dtype: int64
log_data3.plot.line()
plt.show()
fig = go.Figure(layout=go.Layout(title=go.layout.Title(text="Log -- Visualization")))
fig.add_trace(
go.Scatter(
x=log_data3["time"],
y=log_data3["status"],
name="total",
mode="lines",
)
)
fig.show()
이렇게 에드 혹 하게 진행할 수 있다
데이터를 집계하는 부분에서는 데이터 웨어사하우스 나 레이크를 이용하고 프레임 변환 해두면 스몰데이터를 관리하기 편하다
근데 여기서 데이터 분석을 자동화하려면 데이터 마트를 만든다
자주 업데이트 되는 데이터와 다수의 사람에게 공유되는 데이터 등 중요성이 높은 것은 차례로 자동화해 나간다.
결국 자주 갱신되고 분석에 자주 활용되는 데이터는 데이터 마트를 만들고 BI를 자동 갱신한다는 것이다
이것에 대한 장단점을 비교하는 건 그때마다 상황에 맞춰서 하는 것이기에 분류하는 것 은 의미가 없음
그렇지만 데이터 마트를 만드는데 시간이 걸리는 것뿐이지 한번 만들면 업무를 익히지 않아도 바로 뛰어들 수 있다
'책 > Streaming System' 카테고리의 다른 글
Chapter 1. Streaming 101 (2) (0) | 2024.02.22 |
---|---|
Chapter 1 . Streaming 101 (1) (0) | 2024.02.21 |