Treasure Data의 대용량 데이터 벤치마크
7688 단어 TreasureDatahivehadoop
넘치는 데이터
회사에서 Treasure Data을 사용한 분석 시스템을 만들고 있다. 게임 정보를 수집하여 유저의 체험 향상에 도움을 주기 위해서다. 그 때문에, 사용자의 행동을 세밀하게 파악할 필요가 있다. 기세 데이터 용량은 증가한다. 또한 온라인 게임은 패키지 게임과 달리 판매가 끝나지 않고 이후 몇 년 동안 서비스를 제공합니다. 따라서 사용자의 행동 로그는 수억 건에 달하는 것도 드물지 않다.
Treasure Data에서 로그 분석
먼저 썼지만, 대량의 로그에 대응하기 위해 hadoop을 이용한 문제 해결이 다양한 기업에서 제공되기 시작했다. 타이틀에 있다 Treasure Data 역시 그 기업의 하나다. 여기에서는 로그를 보내는 것만으로 hadoop과 hive를 이용한 분석 환경을 제공해 준다. 한편, 이쪽이 분석기재를 준비하는 것은 아니기 때문에, 어느 정도의 속도로 분석할 수 있는지 모른다. 특히 복잡한 Hive 쿼리의 경우 얼마나 걸리나요? 데이터량이 늘어났을 때 어떤 행동을 나타내는지는 스스로 시도하지 않으면 진짜는 모른다.
Treasure Data를 사용한 hive 벤치마크
그 때문에 Treasure Data를 사용한 hive의 벤치마크를 실시했다. 사용한 데이터는 실제 게임을 모방한 더미 데이터이다.
이 더미 데이터를 10억 건 넣은 테이블(데이터 사이즈는 305GB)을 작성해, 거기에 복잡한 Hive 쿼리를 던졌다.
{"response":
{"presents":
[
{
"id":335,
"type":1,
"name":"連続ガチャ",
"quantity":1,
"unit": {
"mode":0,
"is_new":false,
"master_id":3027,
"unit": {
"id":5495,
"master_id":3027,
"level":1,
"exp":0,
"skill_learning": [
{
"master_id":30012,"exp":0
}
],
"learned_action_ids":[9930032,9930033,9930036,9930054,9930057,9930058],
"union_count":0,
"state":null,
"role":1
}}}]}}
이 쿼리도 가상의 것이지만 Hive 쿼리의 내용은 login이라는 API에서 user_id를 집계하여 총 로그인자 수를 빼내는 것이다. distinct를 하지 않은 것은 더미 데이터로서 중복하는 user_id를 사용하여 사용하고 있어 집계값이 늘어나지 않기 때문에, distinct는 제외했다.
SELECT COUNT(a.user_id)
FROM (SELECT get_json_object(v['response'],'$.user.id') AS user_id
FROM complex_10m_test_json
WHERE (v['api_name']='login')
AND (get_json_object(v['response'],'$.user.id') IS NOT NULL) ) a;
벤치마크 결과
10억 건의 데이터에 대한 벤치마크는 데이터를 1천만 건씩 늘리면서 100회 실시했다(표에서는 억의 값만 발췌).
아래에 회귀식을 썼지만, 기본적으로 처리 시간은 선형으로 증가했다. 최초의 1억에서 2억 건 정도에서는 8cpu 코어 이상은 사용하고 있지 않았지만, 그 후, 건수가 늘어나면 32 코어 cpu 써냈다.
벤치마크 결과표
건수
쿼리 초 수
1000만건
133
1억
227
2억
500
3억
615
4억
756
5억
1035년
6억
1924년
7억
724
8억
943
9억
1119년
10억
1220년
벤치마크 결과에서 회귀식을 만들어 보았다.
f(x)=361.2182401 exp(0.01666789 * x)
R2 = 0.5828
대체로 5~6억 건으로 1000초를 넘을 정도라고 생각하면 된다고 생각한다.
td의 CPU 사용량
Treasure Data에서는 계약 머신의 CPU 사용량 등을 공개하고 있다. 상기 벤치마크를 취했을 때의 CPU 사용량에 대해서 그래프를 조사하였다. 그런데 CP 사용 코어 수가 떨어지는 곳은 벤치마크 프로그램에 버그가 있어 계측을 중단한 곳이다.
데이터 크기 358GB
데이터 용량 22억건
요약
Treasure Data에 대해 벤치마크를 수행했습니다. MySQL처럼 데이터가 늘어나면 급격하게 처리 시간이 늘어나는 것도 없었다. 간편하게 여러가지 분석하기에는 좋은 환경이 아닐까 생각한다.
Reference
이 문제에 관하여(Treasure Data의 대용량 데이터 벤치마크), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/shibacow/items/ce40c015a489ab3b2110텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)