대용량 로그분석 Bigquery로 간단히 사용하기 20160930
7 likes1,554 views
구글 GDG 9월 27일, 29일 발표 자료.
![© NBT All Rights Reserved.
TableDecorator,PartitionDecorator
BigQuery가제공하는Decorator
장점
• 날짜별 table이 존재하듯이 사용
• 손쉬운 range 검색
• 기간별, 일자별 table 생성이 용이
고려 사항
• Table 생성 시 Partitioned Table로
생성되어야 함
SELECT COUNT(*) FROM cashslide:dataset.table$20160830
2016년 8월 30일 데이터 조회
SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000]
1시간 이전까지의 과거 데이터 조회](https://image.slidesharecdn.com/bigquery20160930-160930050734/85/Bigquery-20160930-21-320.jpg)
![© NBT All Rights Reserved.
TableDecorator
유용한Decorator2가지(1/2)
고려 사항
• 최대 7일 이전 데이터까지 조회
가능
• Milliseconds 단위
# Snapshot decorators
@<time>
# Range decorators
@<time1>-<time2>
Syntax
# Snapshot example
SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000]
# Range example
SELECT
COUNT(*)
FROM
[cashslide:dataset.table@-3600000--1800000]
Example](https://image.slidesharecdn.com/bigquery20160930-160930050734/85/Bigquery-20160930-23-320.jpg)
![© NBT All Rights Reserved.
PartitionDecorator
유용한Decorator2가지(2/2)
고려 사항
• $YYYYMMDD decorator를 이
용한 snapshot 검색
• Pseudo column을 이용한
range 검색
[TABLE_NAME]$YYYYMMDD
Syntax
# Snapshot example
SELECT COUNT(*) FROM cashslide:dataset.table$20160505
# Range example
SELECT
field
FROM
table
WHERE
_PARTITIONTIME BETWEEN TIMESTAMP('2016-01-01')
AND TIMESTAMP('2016-01-21');
Example](https://image.slidesharecdn.com/bigquery20160930-160930050734/85/Bigquery-20160930-24-320.jpg)
대용량 로그분석 Bigquery로 간단히 사용하기 20160930
- 1. 대용량 로그분석, BigQuery로 간단히 사용하기 ㈜엔비티 / Devops / 이재광 2016년 09월 facebook.com/openstakcs
- 2. © NBT All Rights Reserved. Contents Part 1. 1. NBT Lumberjack Log Analysis Architecture 2. ISSUE Part 2. 1. BigQuery 실전 구현 시나리오 2. BigQuery 구축 시 고민들 3. 변경된 시나리오 Part 3. 1. BigQuery 활용 TIP
- 3. © NBT All Rights Reserved. 왜BigQuery사용을고민하게되었나
- 4. © NBT All Rights Reserved. Kafka+ELK+Spark+Zeppelin NBTLumberjacklogAnalysisArchitecture client L4 Kafka proxy Kafka & Zookeeper Cluster Logstash Elasticsearc h Spark Kibana Zeppelin S3 Lumberca mp Jenkins
- 5. © NBT All Rights Reserved. Kafka+ELK+Spark+Zeppelin Issues client L4 Kafka proxy Kafka & Zookeeper Cluster Logstash Elasticsearc h Spark Kibana Zeppelin S3 Lumberca mp 성능저하 고민 Disk 증설 고민 Elasticsearch 성능 고민 Long Query 2시간 이상 수행되면 다른 작업 불가능 Jenkins
- 6. © NBT All Rights Reserved. 오랜시간개선에힘을쏟기보다는 관리포인트를GooglePlatform으로전환시켜보자
- 7. © NBT All Rights Reserved. GoogleCloudAccount생성이제일어려웠을만큼쉽게구성가능했던BigQuery 우리가경험했던BigQuery
- 8. © NBT All Rights Reserved. 대략몇군데만손보면금방구현될듯 손이갈만한것들을추려보자면 1. 현재의 logstash 서버를 활용하고 2. BigQuery API만 잘 뚫어주 면 3. 우리의 log format에 맞게 잘 정의된 스키마로 데이터를 집어 넣고 4. 잘 사용하는 것 만이 할 일이다.
- 9. © NBT All Rights Reserved. 이런작업은하루면됩니다. proto-type구현 1. 현재의 json log 일부를 test 전송 2. Google App Key를 발급하 여 API 권한 획득 3. 최소한의 schema를 넣고 test 진행 4. 빠른 것 같긴한데.. 이제 실데이터를 가지고 조회해 볼까
- 10. © NBT All Rights Reserved. 기존logstash서버에저장된jsonlogfile을BigQuery로전송후조회 실전구현시나리오작성 Logstash Elasticsearc h Spark Kibana ZeppelinS3 BigQuery 고려 사항 • 서버의 자원 부담 최소화 (현재도 부담 되는 중) • 전송 처리 실패에 대한 보장 • 전송 처리 작업 시간 개선 • 전송 작업 이력 관리 • 네트워크 구간 전송 효율 개선 DataStudi o etc Jenkins
- 11. © NBT All Rights Reserved. BigQuerySchema생성시ES의Nestedtpye에서문제발생 BigQuery구축시고민1 고려 사항 • Nested와 유사한 Repeated Mode • 'info' column을 Record type의 Repeated Mode로 생성 • Repeated Mode의 column 안에 또 한번의 Repeated Mode는 지원 안됨. ES도 마찬가지. • 이 경우는 String 처리에 대한 고민 • 일단 제외 { "name": "info", "type": "RECORD", "mode": "REPEATED", "fields": [ { "mode": "NULLABLE", "name": "step_i", "type": "INTEGER" }, { "mode": "NULLABLE", "name": "recommended", "type": "STRING" }, { "name": “app_config”, "type": “RECORD", "mode": “REPEATED”, “fields” : [ { “mode”: NULLABLE “name": “adison_enables” “type”: “STRING” }, { “mode”: NULLABLE “name": “abusing_devices” “type”: “STRING” },
- 12. © NBT All Rights Reserved. jsonfilesize:7~35Gperhour,7.5Gjsonfileloading작업이약1시간정도소요 Embulk를이용한BigQueryData적재 Logstash Elasticsearc h Spark Kibana ZeppelinS3 BigQuery 고려 사항 • 서버의 자원 부담 최소화 (현재도 부담 되는 중) • 전송 처리 실패에 대한 보장 • 전송 처리 작업 시간 개선 • 전송 작업 이력 관리 • 네트워크 구간 전송 효율 개선 DataStudi o etc Jenkins
- 13. © NBT All Rights Reserved. embulk를도입했어도Jsonfile을BigQuery로적재하기에는너무느림 BigQuery구축시고민2 Logstash Elasticsearc h Spark Kibana ZeppelinS3 BigQuery 고려 사항 • 1시간 이상 걸리는 BigQuery Data 적재 작업 • Parsing 처리 비용이 너무 높다. • 시간당 30G 이상의 파일을 전송하 는 경우 발생하는 네트워크 전송량도 너무 많다. • 바이너리 압축 전송을 하면 BigQuery Loading은? DataStudi o etc Jenkins
- 14. © NBT All Rights Reserved. Jenkins를이용해서gzfile을GCS로전송후BigQueryLoadingJob을추가실행 GCStoBigQuery 해결 • Transport Tool을 embulk에서 gsutil로 교체 • gsutil을 이용한 바이너리 파일 병렬 전송으로 작업 속도 향상 • Gzip으로 GCS 전송 후 BigQuery로 Data 적재 작업을 수행하는 경우 Job 형태로 async 수행 및 관리 가능 Logstash BigQuery DataStudi o Cloud Storage gsutil Jenkins
- 15. © NBT All Rights Reserved. BigQuery의ComputingResource비용은무료 BigQuery의Extract&Loading 무료 • 비용은 Storage와 Streaming Inserts, Queries 요금만 존재 • 속도도 빠르고 관리도 용이한 BigQuery Loading이 무료 (GCS pricing) BigQuery pricing
- 16. © NBT All Rights Reserved. 기존S3로전송하던gzfile을GCS로전송후BigQuery로적재 실전구현시나리오변경 Logstash Elasticsearc h Spark Kibana ZeppelinS3 BigQuery 변경된 시나리오 • json file -> gzip file • embulk -> gsutil • to BigQuery -> to GCS • sync -> async DataStudi o Cloud Storage gsutil Jenkins gsutil Json 7.5G 약 1 hour GZ 350M 약 14 sec BigQuery Cloud Storage json gzip
- 17. © NBT All Rights Reserved. 기존S3의gzfile을GCS로마이그레이션수행 데이터마이그레이션 고려 사항 • BigQuery Console Web 화면 에서 한달치 데이터를 적재한 table을 만들때 sub-directory의 file들은 적재가 안됨 • 이 경우 별도의 BigQuery 적재 스크립트 필요 • 필요한 기간에 따라 디렉토리 구 조를 적절히 가져가는 것이 필요 S3 Cashslide/prd/lumberjack/2016/06/01/01/timestamp.gz Cashslide/prd/lumberjack/2016/06/01/02/timestamp.gz Cashslide/prd/lumberjack/2016/06/01/03/timestamp.gz Cashslide/prd/lumberjack/2016/06/01/04/timestamp.gz : : Cloud Storage Cashslide/prd/lumberjack/2016/06/timestamp.gz Cashslide/prd/lumberjack/2016/06/timestamp.gz Cashslide/prd/lumberjack/2016/06/timestamp.gz Cashslide/prd/lumberjack/2016/06/timestamp.gz : :
- 18. © NBT All Rights Reserved. BigQuery속도는빠른가 BigQuery조회해보기 고려 사항 • 한달치 1.34TB data를 스캔해서 result 까지 걸린 시간 6초 • 7명이 동시에 쿼리를 수행해도 동일하게 빠른 성능을 보여줌 • 그런데 한번 조회에 1.34TB면 얼마지?
- 19. © NBT All Rights Reserved. HowmuchBigQuery BigQuery구축시고민3 비용 요소 • GCS 비용 + BigQuery Storage 비용 + Query 비용 • BigQuery는 10MB 단위로 청구 (월 1TB 무료) 1.34TB는 약 $6.7 고려 사항 • 사용자가 range query를 제대로 수 행하지 않으면 많은 비용이 발생할 수 도 있다. • 대안으로 테이블을 사용자 용도에 맞 게 복제해주거나 구글의 cost control 을 통한 Quota 제한 고민
- 20. © NBT All Rights Reserved. 기간별table을쉽게생성하는방법?
- 21. © NBT All Rights Reserved. TableDecorator,PartitionDecorator BigQuery가제공하는Decorator 장점 • 날짜별 table이 존재하듯이 사용 • 손쉬운 range 검색 • 기간별, 일자별 table 생성이 용이 고려 사항 • Table 생성 시 Partitioned Table로 생성되어야 함 SELECT COUNT(*) FROM cashslide:dataset.table$20160830 2016년 8월 30일 데이터 조회 SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000] 1시간 이전까지의 과거 데이터 조회
- 22. © NBT All Rights Reserved. 나중에이걸확인한다면BigQuery적재작업의처음으로돌아가시오. 편리한Partitionedtables 고려 사항 • Dataset table 생성 시 Date- Partitioned tables로 생성 가능 • 생성 시 Expiration time은 second 기준 • _PARTITIONTIME 이름의 pseudo column 을 포함하며, data 적재 시점을 기준으로 TIMESTAMP(“2016-04-15”) 형식의 값을 저장함. UTC 기준 $bq mk --time_partitioning_type=DAY --time_partitioning_expiration=259200 mydataset.table Partitioned tables 생성 예제 $bq show --format=prettyjson mydataset.table 생성된 테이블 정보 확인 { ... "tableReference": { "datasetId": "mydataset", "projectId": "myproject", "tableId": "table2" }, "timePartitioning": { "expirationMs": "2592000000", "type": "DAY" }, "type": "TABLE" }
- 23. © NBT All Rights Reserved. TableDecorator 유용한Decorator2가지(1/2) 고려 사항 • 최대 7일 이전 데이터까지 조회 가능 • Milliseconds 단위 # Snapshot decorators @<time> # Range decorators @<time1>-<time2> Syntax # Snapshot example SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000] # Range example SELECT COUNT(*) FROM [cashslide:dataset.table@-3600000--1800000] Example
- 24. © NBT All Rights Reserved. PartitionDecorator 유용한Decorator2가지(2/2) 고려 사항 • $YYYYMMDD decorator를 이 용한 snapshot 검색 • Pseudo column을 이용한 range 검색 [TABLE_NAME]$YYYYMMDD Syntax # Snapshot example SELECT COUNT(*) FROM cashslide:dataset.table$20160505 # Range example SELECT field FROM table WHERE _PARTITIONTIME BETWEEN TIMESTAMP('2016-01-01') AND TIMESTAMP('2016-01-21'); Example
- 25. © NBT All Rights Reserved. 그런데BigQuery는 어떤종류의분석이가능한가요?
- 26. © NBT All Rights Reserved. 이렇게구축한BigQuery를잘활용하는데 도움되는TIP몇가지
- 27. © NBT All Rights Reserved. 최고의TIP은요약 BigQueryTip1 • ES의 Nested와 유사한 Repeated type 형태가 존재하는지 여부 검토 • BigQuery에서 Table 생성 시 Partitioned Table 고려 • GCS to BigQuery 구조로 Parsing은 Google의 자원을 무료로 사용하자 • GCS까지는 ‘gsutil -m’을 이용한 gz file 병렬 전송 • GCS to BigQuery 구조로 Job 현황 및 이력 관리 가능 • 운영 비용 절감은 Decorator를 활용한 용도별 table 생성 또는 cost control로 사용자 별 Quota 할당
- 28. © NBT All Rights Reserved. BigQueryComposer여러모로편리합니다. BigQueryTip2 TIP • Query box 안의 Color를 보면 현재 syntax, dataset name, table name, column name, function name 의 오류를 쉽게 확인 가능 • Results Tab 옆의 Explanation 을 보면 Query 수행 과정이 알기 쉽게 표기되어 Query 성능 개선 가능
- 29. © NBT All Rights Reserved. Fileexport는file당1G,일일최대10TB가능 BigQueryTip3 TIP • 쿼리 결과의 export는 파일당 최 대 1G 가능 • 그 이상의 결과를 export 하려는 경우 쿼리 결과에서 ‘Save as Table’로 저장 후 export 항목에 ‘*.json’ 형태로 기입
- 30. © NBT All Rights Reserved. BigQuery비용절감을위한UseCache사용 BigQueryTip4 TIP • 'Use Cached Results'를 사용하 여 캐싱된 이전 쿼리 결과를 사용 하면 중복되는 쿼리들의 비용을 절감 가능 Query Composer에서 'Show Options'를 눌러보면
- 31. © NBT All Rights Reserved. Zeppelin0.6.1부터‘%bigquery’인터프리터지원 BigQueryTip5 TIP • Zeppelin 0.6.1 버전부터 BigQuery Interpreter를 제공 • Data뿐만 아니라 BigQuery Computing resource를 활용하 여 작업 수행 가능 (AWS EMR, Google Dataproc의 비용 불필 요) • 기존 Notebook의 이전 작업이 필요
- 32. © NBT All Rights Reserved. 아쉬운부분: 이를활용할수있는Kibana,Zeppelin과같은도구가 좀더다양하게지원되었으면하는바램
- 33. © NBT All Rights Reserved. Q&A
- 34. THANK YOU 주소 : 서울시 서초구 서초동 1341-7 조이빌딩