블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

얼굴 인식 모델을 만들어보자 #5 학습된 모델을 Export 하기



조대협 (http://bcho.tistory.com)


앞의 글에서 CloudML을 이용하여 학습하는 부분까지 끝냈다. 그렇다면 학습된 모델을 이용하여 실제로 예측은 어떻게 할것인가? 여기에는 두가지 선택지가 있다.


첫번째는, 체크포인트로 저장된 파일을 이용하는 방식인데, 체크포인트에는 저장된 데이타는 텐서플로우 모델 그래프는 없고, 모델에서 사용된 변수 (Weight,bias etc) 만 저장하기 때문에, 이 데이타를 로딩하려면 텐서플로우 코드로 그래프를 그려준 다음에, 로딩을 해야한다. (상세 설명 http://bcho.tistory.com/1179 )


두번째는, 체크포인트처럼 변수만 저장하는 것이 아니라, 그래프를 함께 저장하는 방식으로 모델을 Protocol Buffer (http://bcho.tistory.com/1182) 타입으로 저장하는 방식이다. 이렇게 Protocol buffer (이하 pb)로 저장된 파일은 Prediction에 최적화된 엔진인 Tensorflow Serving (https://www.tensorflow.org/deploy/tfserve) 에 로딩하여 사용이 가능하다. 그런데, Tensorflow Serving의 경우 일일이 빌드를 해야 하는데, bazel 빌드 툴 (make,gradle과 같은 빌드툴. http://bcho.tistory.com/1160 )을 이용해서 빌드 및 배포를 해야 하는데 이 과정이 쉽지 않고, 또한 Tensorflow Serving에 배포된 모델을 호출하기 위해서는 Google protocol buffer (grpc)를 사용해야 한다.

이 과정에 많은 노력(삽질?)이 필요하고, 운영환경에 올리기 위해서는 모델 pb 파일에 대한 배포 프로세스 그리고 여러개의 Tensorflow Serving Cluster 설치 및 운영등의 이슈가 발생한다.


그래서 이를 플랫폼화하여 서비스로 만들어놓은 것이 Google CloudML Prediction 서비스이다. CloudML Prediction 서비스는 단순하게, 학습된 pb 파일만 배포하게 되면, 운영에 대한 이슈없이 대용량 서비스가 가능하고 grpc를 사용하지 않더라도 SDK를 이용하여 손쉽게 json으로 요청을 보냄으로써 prediction에 대한 구현이 가능하다.

모델 Export 하기

http://bcho.tistory.com/1180 에서 CloudML을 이용하여 얼굴 인식 모델을 학습 시켰다. 여기서 사용된 코드를 수정하여 학습이 끝나면, 모델(그래프와 변수값)을 Export 하는 코드를 추가해야 한다.

Export를 할때 주의할 점은 학습에 사용된 그래프를 그대로 Export 하는 것이 아니라 새로 그래프를 그려서 Export를 해야 한다. Export할 그래프는 Prediction을 위한 그래프이기 때문에, 학습에 사용된 그래프는 Dropout이나 또는 validation등을 위한 로직이 들어가 있기 때문에 이런 부분을 다 제거 하고 Prediction을 위한 그래프로 재정의하여 Export 해야한다.


얼굴 인식 모델에서 학습된 모델을 Export 하는 과정은

  1. 학습을 진행하고 학습 진행중에 체크포인트를 저장한다.

  2. 학습이 종료되면 Export를 위한 그래프를 새로 그린다.

  3. 체크포인트 파일에서 변수 값을 읽어서 2에서 그린 그래프에 채워넣는다.


자 그러면 코드를 보자. (전체 코드는 https://github.com/bwcho75/facerecognition/blob/master/CloudML%20Version/face_recog_model/model_localfile_export.py 에 저장되어 있다.)

체크 포인트 저장하기

코드 401 라인을 보면 아래와 같이 saver 객체를 이용하여 현재 학습이 종료된 세션의 값을 넘겨서 체크포인트 값으로 저장한다. 이 때 체크포인트 파일은 os.path.join(model_dir, 'face_recog') 에 저장한다.

       print('Save model')

       model_dir = os.path.join( FLAGS.base_dir , 'model')

       if not os.path.exists(model_dir):

           os.makedirs(model_dir)

       saver.save(sess, os.path.join(model_dir, 'face_recog'))

       print('Save model done '+model_dir)


다음으로 408 라인에서, 모델을 Export하는 함수 export_model 함수를 호출한다. 이때 첫번째 인자로는 체크포인트 파일 경로를 넘긴다.


       export_dir = os.path.join( FLAGS.base_dir , 'export')

       if  os.path.exists(export_dir):

          rmdir(export_dir)

       export_model(os.path.join(model_dir, 'face_recog'), export_dir)

Export용 그래프 그리기

274 라인의 def export_model(checkpoint, model_dir) 함수를 보자. 이 함수는 checkpoint 디렉토리를 입력받아서 model_dir에 모델을 export 해주는 함수이다.


앞에서도 설명했듯이 Export 용 그래프는 새롭게 그려줘야 하는데, 276~279 라인까지가 새롭게 그래프를 그리는 부분이다.

 with tf.Session(graph=tf.Graph()) as sess:


   images = tf.placeholder(tf.string)

   prediction = build_inference(images)


이미지를 입력할 input용 placeholer를 정의한다. 이때 중요한점이 우리가 학습에서는 float형 placeholder를 사용했는데, 여기서는 입력을 string으로 바꿨다. 이유는 모델을 학습한 후에 실제 운영 환경에 올렸을 때, 클라이언트 (웹이나 모바일)에서 이미지를 입력 받아서 학습된 모델을 호출할때 float 형 행렬로 넘기기에는 불편하고 데이타의 크기도 커진다. (행렬데이타를 [1,2,3,4…] 와 같은 문자열로 넘겨야 하기 때문에 ) 그래서 호출할때 데이타 전달을 쉽게 할 수 있도록 이미지를 문자열 바이너리로 입력 받도록 수정하였다.

다음 build_inference(images) 함수가 실제로 Export 용 그래프를 새로 그리는 부분인데

261 라인에 아래와 같이 정의 되어 있다.


def build_inference(image_bytes):

   # graph for prediction in CloudML

   #image_bytes = tf.placeholder(tf.string)

   rgb_image = tf.image.decode_jpeg(image_bytes[0],channels = FLAGS.image_color)

   rgb_image  = tf.image.convert_image_dtype(rgb_image, dtype=tf.float32)

   image_batch = tf.expand_dims(rgb_image, 0)

   #rgb_image_value = rgb_image.eval()

   #rgb_images = []

   #rgb_images.append(rgb_image_value)

   result = tf.nn.softmax(build_model(image_batch,keep_prob=1.0))

   

   return result


문자열로 입력받은 이미지 데이타는 배열형이기 때문에, [0] 로 첫번째 이미지를 골라내고 (이미지를 입력할때도 하나만 입력한다.) tf.image_decode_jpeg로 디코딩을 한후에, 타입을 tf_float32 형태의 행렬로 바꿔준다. 원래 우리가 사용했던 학습용 모델의 모양이 batch 형이기 때문에, tf.expand_dim으로 차원을 맞춰준다.

그 다음에 build_model() 함수를 이용하여 image_batch를 입력값으로 넣고 그래프를 그린다. dropout을 하지 않기 때문에, keep_prob=1.0 으로 한다. (build_model은 얼굴 인식 모델을 위해서 CNN 네트워크를 정의한 코드이다.)

build_model에 결과를 마지막에 softmax함수를 정의하여 result값을 리턴하도록 한다.

시그네쳐 정의하기

Tensorflow serving (CloudML inference)를 사용하기 위해서는 Tensorflow serving에 모델의 Input 과 Output 변수를 알려줘야 한다. 이를 시그네쳐라고 하는데,  SignatureDefs 를 이용하여 정의한다. (참고 https://github.com/tensorflow/serving/blob/master/tensorflow_serving/g3doc/signature_defs.md)


SignatureDefs는 용도에 따라서 Classification SignatureDef와 Predict SignatureDef 두가지로 나뉘어 진다. Cassification SignatureDef는 분류 모델에 최적화되어 정의된 시그네쳐로 출력값들이 클래스 종류나 클래스별 정확도등을 옵션으로 가질 수 있고, Predict SignatureDef는 분류 모델뿐 아니라 모든 모델에 범용적으로사용될 수 있는 형태로 입력과 출력값을 정의할 수 있다.


이 예제에서는 Predict Signature Def을 사용하였다.

   inputs = {'image': images}

   input_signatures = {}

   for key, val in inputs.iteritems():

     predict_input_tensor = meta_graph_pb2.TensorInfo()

     predict_input_tensor.name = val.name

     predict_input_tensor.dtype = val.dtype.as_datatype_enum

     input_signatures[key] = predict_input_tensor


코드에서는 images placeholder를 입력값으로 하여 “image”라는 이름의 입력 시그네쳐를 생성하였고, 마찬가지로 다음과 같이 출력 값은 prediction 변수를 “prediction”이라는 이름의 시그네쳐로 사용하여 정의하였다.

   outputs = {'prediction': prediction}

   output_signatures = {}

   for key, val in outputs.iteritems():

     predict_output_tensor = meta_graph_pb2.TensorInfo()

     predict_output_tensor.name = val.name

     predict_output_tensor.dtype = val.dtype.as_datatype_enum

     output_signatures[key] = predict_output_tensor


다음, 이렇게 생성한 시그네쳐 변수들을 ‘image’,’prediction’ 을 add_to_colleciton을 이용하여 텐서플로우 그래프에 추가하였다.


   inputs_name, outputs_name = {}, {}

   for key, val in inputs.iteritems():

     inputs_name[key] = val.name

   for key, val in outputs.iteritems():

     outputs_name[key] = val.name

   tf.add_to_collection('inputs', json.dumps(inputs_name))

   tf.add_to_collection('outputs', json.dumps(outputs_name))

체크포인트 데이타 로딩해서 Export 용 그래프에 채워넣기

Export할 그래프가 완성되었으면 여기에 학습된 값을 채워넣으면 된다.

학습된 값은 학습후에, 체크 포인트 파일에 저장되어있기 때문에, 이 체크 포인트 파일을 다시 로딩하자


init_op = tf.global_variables_initializer()

   sess.run(init_op)


   # Restore the latest checkpoint and save the model

   saver = tf.train.Saver()

   saver.restore(sess, checkpoint)


모델 저장

다음 최종적으로 모델을 저장하면 된다.

   predict_signature_def = signature_def_utils.build_signature_def(

       input_signatures, output_signatures,

       signature_constants.PREDICT_METHOD_NAME)


앞서 정의한 input,output 시그네쳐를 가지고, Predict Signature Def를 정의한다.

다음 SavedModelBuilder를 만들어서 디렉토리를 지정하고, add_meta_graph_and_variables 메서드를 이용하여, 정의한 시그네쳐를 넘겨주고, assets_collection을 통해서 그래프 값을 넘긴후, 최종적으로 save() 메서드를 이용하여 그 값을 저장한다.

   build = builder.SavedModelBuilder(model_dir)

   build.add_meta_graph_and_variables(

       sess, [tag_constants.SERVING],

       signature_def_map={

           signature_constants.DEFAULT_SERVING_SIGNATURE_DEF_KEY:

               predict_signature_def

       },

       assets_collection=tf.get_collection(tf.GraphKeys.ASSET_FILEPATHS))

   build.save()


저장된 모델 확인

모델 저장이 완료되면 Export 디렉토리데 다음과 같이 파일들이 생성된다

  • saved_model.pb (파일) : 그래프를 저장하고 있는 모델 바이너리 파일이다.

  • variables (디렉토리) : 디렉토리로 변수 값을 저장하고 있는 파일들이 저장되어 있다.

정리

텐서플로우 자료나 튜토리얼을 보면 대부분 모델을 만들고 학습 하는 정도만 있고 Prediction(또는 Inference)는 대부분 체크포인트에 저장된 값을 그래프로 복원하는 방식을 사용하고 있지 Tensorflow Serving등을 사용하는 자료가 별로 없다. 그래서 정리를 해봤는데, 생각보다 어렵기는 하지만 코드를 찬찬히 살펴보니 Signature와 Graph Collection 을 개념을 이해하고 나면 여러 예제코드를 보면서 진행하면 어느정도 할 수 있지 않을까 싶다. 개념 자체가 어려운것 보다는 이를 지원하는 예제나 문서가 적기 때문이라고 보는데,이것도 텐서플로우가 활성화되는 중이니 많은 예제가 나오지 않을까 기대해 본다.


다음 글에서는 이번에 Export 한 모델 (*.pb)을 이용하여 구글 CloudML을 통해서 예측 (Inference) 하는 방법에 대해서 알아보겠다.


참고 자료


구글 프로토콜 버퍼 (Protocol buffer)

프로그래밍 | 2017.06.25 19:30 | Posted by 조대협


구글 프로토콜 버퍼

조대협 (http://bcho.tistory.com)


텐서 플로우로 모델을 개발하다가 학습이 끝난 모델을 저장하여, 예측하는 데 사용하려고 하니, 모델을 저장하는 부분이 꽤나 복잡하여 찾아보니, 텐서플로우는 파일 저장 포맷을 프로토콜 버퍼를 사용한다는 것을 알았다.


그래서, 오래전에 살펴보았던 프로토콜 버퍼를 다시 살펴보았다.

개요 및 특징

프로토토콜 버퍼는 구글에서 개발하고 오픈소스로 공개한, 직렬화 데이타 구조 (Serialized Data Structure)이다. C++,C#, Go, Java, Python, Object C, Javascript, Ruby 등 다양한 언어를 지원하며 특히 직렬화 속도가 빠르고 직렬화된 파일의 크기도 작아서 Apache Avro 파일 포맷과 함께 많이 사용된다.

(직렬화란 데이타를 파일로 저장하거나 또는 네트워크로 전송하기 위하여 바이너리 스트림 형태로 저장하는 행위이다.)


특히 GRPC 라는 네트워크 프로토콜의 경우 HTTP 2.0 을 기반으로 하면서, 메세지를 이 프로토콜 버퍼를 이용하여 직렬화하기 때문에, 프로토콜 버퍼를 이해해놓으면 GRPC를 습득하는 것이 상대적으로 쉽다.


프로토콜 버퍼는 하나의 파일에 최대 64M까지 지원할 수 있으며, 재미있는 기능중 하나는 JSON 파일을 프로토콜 버퍼 파일 포맷으로 전환이 가능하고, 반대로 프로토콜 버퍼 파일도 JSON으로 전환이 가능하다.

설치 및 구성

프로토콜 버퍼 개발툴킷은 크게 두가지 부분이 있다. 데이타 포맷 파일을 컴파일 해주는 protoc 와 각 프로그래밍 언어에서 프로토콜 버퍼를 사용하게 해주는 라이브러리 SDK가 있다.


protoc 컴파일러와, 각 프로그래밍 언어별 SDK는 https://github.com/google/protobuf/releases  에서 다운 받으면 된다.


protoc 는 C++ 소스 코드를 직접 다운 받아서 컴파일하여 설치할 수 도 있고, 아니면 OS 별로 미리 컴파일된 바이너리를 다운받아서 설치할 수 도 있다.  


각 프로그래밍 언어용 프로토콜 버퍼 SDK는 맞는 버전을 다운 받아서 사용하면 된다. 파이썬 버전 설치 방법은  https://github.com/google/protobuf/tree/master/python 를 참고한다.

이 글에서는 파이썬 SDK 버전을 기준으로 설명하도록 한다.

구조 및 사용 방법

프로토콜 버퍼를 사용하기 위해서는 저장하기 위한 데이타형을 proto file 이라는 형태로 정의한다. 프로토콜 버퍼는 하나의 프로그래밍 언어가 아니라 여러 프로그래밍 언어를 지원하기 때문에, 특정 언어에 종속성이 없는 형태로 데이타 타입을 정의하게 되는데, 이 파일을 proto file이라고 한다.

이렇게 정의된 데이타 타입을 프로그래밍 언어에서 사용하려면, 해당 언어에 맞는 형태의 데이타 클래스로 생성을 해야 하는데, protoc 컴파일러로 proto file을 컴파일하면, 각 언어에 맞는 형태의 데이타 클래스 파일을 생성해준다.


다음은 생성된 데이타 파일을 프로그래밍 언어에서 불러서, 데이타 클래스를 사용하면 된다.

예제

간단한 파이썬 예제를 통해서 사용법을 익혀보자. 저장하고자 하는 데이타 포맷은 Person 이라는 클래스형으로, 이름,나이,이메일을 순차적으로 가지고 있는 데이타 포맷을 정의하여, Person 객체를 생성하여 데이타를 저장하고 이 객체를 파일에 저장했다가 읽어 들이는 예제이다.


이름과 이메일은 문자열, 나이는 숫자로 저장된다. 이 데이타형을 proto 형으로 정의하면 다음과 같다.

address.proto

syntax = "proto3";

package com.terry.proto;


message Person{

 string name = 1;

 int32 age=2;

 string email=3;

}


이 파일을 address.proto 라는 이름으로 저장한다. 다음 proto 파일을 파이썬용 코드로 컴파일한다. protoc 명령을 이용하면 되는데,


protoc -I=./ --python_out=./ ./address.proto


  • -I에는 이 protofile이 있는 소스 디렉토리

  • --python_out에는 생성된 파이썬 파일이 저장될 디렉토리

  • 그리고 마지막으로 proto 파일을 정의한다.


이렇게 컴파일을 하면 --python_out으로 지정된 디렉토리에 address_pb2.py 라는 이름으로 파이썬 파일이 생성된다. (pb2는 protocol buffer2를 의미하는 확장자이다.)


다음은 생성된 Person 클래스를 이용하여 객체를 만들고, 값을 지정한 후 이를 파일로 저장하는 예제이다.

write.py

import address_pb2


person = address_pb2.Person()


person.name = 'Terry'

person.age = 42

person.email = 'terry@mycompany.com'


try:

f = open('myaddress','wb')

f.write(person.SerializeToString())

f.close()

print 'file is wriiten'

except IOError:

print 'file creation error'


protoc에 의해 컴파일된 address_pb2 모듈을 import 한후에, address_pb2.Person()으로 person 객체를 생성한다. 다음에 person.name, person.age, person.email에 값을 넣은 후 파일을 열어서 파일에 person 객체의 내용을 넣는데, 이때 SerializeToString() 메서드를 이용하여 문자열로 직렬화 한다.


다음 코드는 이렇게 파일로 저장된 person 객체를 다시 파일로 부터 읽는 코드이다.

read.py

import address_pb2


person = address_pb2.Person()


try:

f = open('myaddress','rb')

person.ParseFromString(f.read())

f.close()

print person.name

print person.age

print person.email

except IOError:

print 'file read error'


앞의 코드와 같이 빈 person 객체를 만든 후에, 파일에서 문자열을 읽어서 ParseFromString() 메서드를 이용하여 문자열을 person 객체로 파싱한후에, 그 내용을 출력한다.

데이타 구조

위의 예제에서는 간단하게 name,age,email 정도의 구조만 간단하게 정의했지만, JSON과 같이 계층을 가지거나 배열형의 데이타 구조도 같이 정의할 수 있고, enum과 같은 타입 정의도 가능하다.

자세한 설명은 https://developers.google.com/protocol-buffers/docs/proto 를 참고하기 바란다.

간단한 팁 - JSON 변환

앞서 설명했듯이, 프로토콜 버퍼의 다른 장점중의 하나는 프로토콜 버퍼로 저장된 데이타 구조를 JSON으로 변환하는 것도 가능하고 역으로 JSON 구조를 프로토콜 버퍼 객체로 만들 수 도 있다.

아래 코드는 프로토콜 버퍼 객체인 person을 JSON으로 변환하여 출력하는 부분이다. MessageToJson 메서드를 사용하면 된다.


print person.name

print person.age

print person.email


from google.protobuf.json_format import MessageToJson

jsonObj = MessageToJson(person)

print jsonObj


다음은 실행 결과이다.


Terry

42

terry@mycompany.com

{

 "age": 42,

 "name": "Terry",

 "email": "terry@mycompany.com"

}



이 기능을 사용하면, 클라이언트(모바일)에서 서버로 HTTP/JSON 과 같은 REST API를 구현할때, 전송전에, JSON을 프로토콜 버퍼 포맷으로 직렬화 해서, 전체적인 패킷양을 줄여서 전송하고, 서버에서는 받은 후에, 다시 JSON으로 풀어서 사용하는 구조를 취할 수 있다. 사실 이게 바로 GRPC 구조이다.

API 게이트웨이를 백앤드 서버 전면에 배치 해놓고, 프로토콜 버퍼로 들어온 메세지 바디를 JSON으로 변환해서 백앤드 API 서버에 넘겨주는 식의 구현이 가능하다.


파이어베이스 애널러틱스를 이용한 모바일 데이타 분석

#3 빅쿼리에 연동하여 모든 데이타를 분석하기


조대협 (http://bcho.tistory.com)


파이어베이스 애널러틱스의 대단한 기능중의 하나가, 모바일에서 올라온 모든 원본 로그를 빅쿼리에 저장하고, 이를 빅쿼리를 통해서 분석할 수 있는 기능이다. 대부분의 매니지드 서비스 형태의 모바일 애널리틱스 서비스는 서비스에서 제공하는 지표만, 서비스에서 제공하는 화면을 통해서만 볼 수 있기 때문에, 상세한 데이타 분석이 불가능하다. 파이어베이스의 경우에는 빅쿼리에 모든 원본 데이타를 저장함으로써 상세 분석을 가능하게 해준다.


아울러, 모바일 서비스 분석에 있어서, 상세 로그 분석을 위해서 로그 수집 및 분석 시스템을 별도로 만드는 경우가 많은데, 이 경우 모바일에 설치될 로그 수집 에이전트에서 부터 로그를 수집하는 API 서버, 이를 저장하기 위한 분산 큐(카프카 Kafka)와 같은 복잡한 백앤드 시스템을 설계 구현해야 하는데, 파이어베이스 애널러틱스의 로깅 기능을 이용하면 별도의 이런 인프라 구현이 없이도 손쉽게 로그를 수집 및 분석할 수 있다. (일종의 무임 승차라고나 할까?)


가격 정책

그렇다면 가장 고민이 되는 것이 가격 정책일 것이다. 파이어베이스 애널러틱스에서 빅쿼리에 데이타를 저장하려면 파이어베이스 플랜중 무료가 아닌 유료 플랜인 Blaze 플랜을 사용해야 한다.

그러나, 다행이도 Blaze 플랜은 “Pay as you go” 모델로 사용한 만큼 비용을 지불하는 모델인데, “Google Cloud Integration”은 별도의 비용이 부과 되지 않는다.



단지 빅쿼리에 대한 비용만 부담이 되는데, 빅쿼리의 경우 데이타 로딩은 무료이고, 저장 요금 역시 GB당 월 0.02$ (약 22원)이며, 90일동안 해당 데이타를 사용하지 않으면 이 요금은 50%로 자동 할인되서 GB당 월 0.01$(약 11원)만 과금된다. 이외에 쿼리당 비용이 과금되는데, 쿼리당 비용은 쿼리에서 스캔한 데이타 용량 만큼만 과금이 된다. TB를 쿼리 했을때 5$가 과금이되는데, 이역시 전체 테이블을 스캔을 하는것이 아니라, 쿼리에서 스캔하는 컬럼에 대해서만 과금이 되고, 전체 테이블이 아니라, 쿼리에서 스캔하는 날짜만 과금이 되기 때문에, 실제 과금 금액은 미미하다고 볼 수 있다. 실제로 실 서비스에서 모 앱의 하루 데이타를 수집한 경우 17만건의 이벤트가 수집되었는데 저장 용량은 전체 350 MB에 불과하다. 전체 컬럼을 스캔한다고 하더라도 (전체 컬럼을 스캔할 일은 없겠지만….) 쿼리 비용은 0.00175$에 불과하다.


파이어베이스 애널러틱스와 빅쿼리를 연동하여 데이타 수집하기

파이어베이스 애널러틱스에서 데이타를 빅쿼리로 수집하기 위해서는 앞에서 언급한바와 같이 먼저 파이어베이스 플랜을 Blaze로 업그레이드 해야 한다. 파이어베이스 콘솔 좌측 하단을 보면 아래와 같이 UPGRADE 버튼이 있다. 이 버튼을 눌러서 Blaze 플랜으로 업그레이드를 하자


다음으로 파이어베이스 애널러틱스 프로젝트를 빅쿼리와 연결을 해줘야 한다.

파이어베이스 콘솔 좌측 상단에서 설정 버튼을 누른 후에, Project settings 메뉴를 선택한다.


프로젝트 세팅 메뉴에 들어가서 상단 메뉴중에 ACCOUNT LINKING이라는 메뉴를 선택한다.


그러면 구글 플레이나 광고 플랫폼등과 연결할 수 있는 메뉴와 함께 아래 그림처럼 빅쿼리로 연결할 수 있는 메뉴와 “LINK TO BIGQUERY”라는 버튼이 화면에 출력된다.


이 버튼을 누르면 작업은 끝났다. 이제부터 파이어베이스의 모든 로그는 빅쿼리에 자동으로 수집되게 된다.

만약에 수집을 중단하고 싶다면 위의 같은 화면에서 LINK TO BIGQUERY라는 버튼이 MANAGE LINKING으로 바뀌어 있는데, 이 버튼을 누르면 아래와 같이 App Details가 나온다.



여기서 스위치 버튼으로 Send data to BigQuery를 끔 상태로 변경해주면 된다.

이제 부터 대략 한시간 내에, 데이타가 빅쿼리에 수집되기 시작할 것이다.  

수집 주기

그러면 파이어베이스 애널러틱스에서는 어떤 주기로 데이타를 수집하고 수집된 데이타는 언제 조회가 가능할까? 이를 이해하기 위해서는 앱 로그 수집에 관여되는 컴포넌트와 흐름을 먼저 이해할 필요가 있다.

로그 수집이 가능한 앱은 크게, 구글 플레이 스토어에서 배포되는 앱, 구글 플레이 스토어를 통하지 않고 배포되는 앱 그리고 iOS 앱 3가지로 나눌 수 있다.

이 앱들이 파이어베이스 서버로 로그를 보내는 방식은 앱마다 약간씩 차이가 있다.


  • 플레이스토어에서 다운 받은 앱 : 각 개별 앱이 이벤트 로그를 수집하여 저장하고 있다가 1시간 주기로, 모든 앱들의 로그를 모아서 파이어베이스 서버로 전송한다.

  • 플레이스토어에서 다운받지 않은 앱 : 플레이스토어에서 다운로드 받은 앱과 달리 다른 앱들과 로그를 모아서 함께 보내지 않고 한시간 단위로 로그를 모아서 개별로 파이어베이스에 전송한다.

  • iOS 앱 : 앱별로 한시간 단위로 로그를 모아서 파이어베이스 서버로 전송한다.


이렇게 앱에서 파이어베이스 서버로 전송된 데이타는 거의 실시간으로 구글 빅쿼리에 저장된다.

그러나 파이어베이스 애널러틱스의 대쉬 보다는 대략 최대 24시간 이후에 업데이트 된다. (24시간 단위로 분석 통계 작업을 하기 때문이다.)


이 전체 흐름을 도식화 해보면 다음과 같다.



수집된 데이타 구조

그러면 빅쿼리에 수집된 테이블은 어떤 구조를 가질까?

테이블 구조를 이해하기 전에 테이블 종류를 먼저 이해할 필요가 있다.

앱에서 수집한 로그는 안드로이드와 iOS 각각 다른 데이타셋에 저장되며, 테이블 명은

  • app_events_YYYYMMDD

가 된다. 2016년 8월30일에 수집한 로그는  app_events_20160830 이 된다.



Intraday 테이블

여기에 intraday 테이블이라는 개념이 존재하는데, 이 테이블은 app_events_intraday_YYYYMMDD 라는 이름으로 저장이 되는데, 이 테이블은 실시간 데이타 수집을 목적으로 하는 테이블로 오늘 데이타가 저장된다. 예를 들어 오늘이 2016년9월1일이라면, app_events테이블은 app_events_20160831 까지만 존재하고, 9월1일자 데이타는 app_events_intraday_20160901 이라는 테이블에 저장된다.

9월1일이 지나면 이 테이블은 다시 app_events_20160901 이라는 이름으로 변환된다.

intraday 테이블의 특성중의 하나는 몇몇 필드들은 값이 채워지지 않고 NULL로 반환된다. 모든 데이타를 수집하고 배치 연산을 통해서 계산이 끝나야 하는 필드들이 그러한데, LTV 값과 같은 필드가 여기에 해당한다.


여기서 주의할점 중의 하나가 intraday 테이블이 하나만 존재할것이라는 가정인데. 결론 부터 이야기 하면 최대 2개가 존재할 수 있다. 9월1일 시점에  app_events_intraday_20160901 테이블이 존재하다가 9월2일이 되면 app_events_intraday_20160902 테이블이 생성된다. app_events_intraday_20160901 를 app_events_20160901 테이블로 변환을 해야 하는데, 단순히 복사를 하는 것이 아니라, 배치 연산등을 수행하기 때문에 연산에 다소 시간이 걸린다. 그래서 연산을 수행하는 동안에는 app_events_intraday_20160901 테이블과 app_events_intraday_20160902이 동시에 존재하고, 9월1일 데이타에 대한 연산이 종료되면 app_events_intraday_20160901 은 app_events_20160901 로 변환 된다.  

테이블 스키마

빅쿼리에 저장된 데이타의 테이블 구조를 이해하기 위해서 빅쿼리의 데이타 저장 특성을 이해할 필요가 있는데, 빅쿼리는 테이블 데이타 구조를 가지면서도 JSON과 같이 컬럼안에 여러 컬럼이 들어가는 RECORD 타입이나, 하나의 컬럼안에 여러개의 데이타를 넣을 수 있는  REPEATED 필드라는 데이타 형을 지원한다.



<그림. 레코드 타입의 예>

레코드 타입은 위의 그림과 같이 Name이라는 하나의 컬럼 내에 Last_name과 First_name이라는 두개의 서브 컬럼을 가질 수 있는 구조이다.

아래는 REPEATED 필드(반복형 필드)의 데이타 예인데, Basket이라는 컬럼에 Books,Galaxy S7, Beer 라는 3개의 로우가 들어가 있다.


<그림. 반복형 필드 예>

이런 구조로 인하여, 빅쿼리는 JSON과 같이 트리 구조로 구조화된 데이타를 저장할 수 있고, 실제로 파이어베이스 애널러틱스에 의해 수집되어 저장되는 데이타도 JSON과 같은 데이타 구조형으로 저장이 된다.

많은 데이타 필드가 있지만, 큰 분류만 살펴보면 다음과 같은 구조를 갖는다.



하나의 레코드는 하나의 앱에서 올라온 로그를 나타낸다. 앱은 앞의 수집 주기에 따라서 한시간에 한번 로그를 올리기 때문에, 하나의 레코드(행/로우)는 매시간 그 앱에서 올라온 로그라고 보면 된다.


가장 상위 요소로 user_dim과, event_dim이라는 요소를 가지고 있다.

user_dim은 사용자나 디바이스에 대한 정보를 주로 저장하고 있고, event_dim은 앱에서 발생한 이벤트들을 리스트 형태로 저장하고 있다.

user_dim에서 주목할만한 것은 userid에 관련된 것인데, userid는 사용자 id 이지만, 파이어베이스가 자동으로 수집해주지는 않는다. 개발자가 앱의 파이어베이스 에이전트 코드에서 다음과 같이 setUserId 메서드를 이용해서 설정해줘야 빅쿼리에서 조회가 가능하다. (앱 서비스의 계정을 세팅해주면 된다.)

mFirebaseAnalytics.setUserId(Long.toString(user.id));

다음 주목할 필드는 user_dim에서 app_info.app_instance_id 라는 필드인데, 이 필드는 각 앱의 고유 ID를 나타낸다. 파이어베이스가 자동으로 부여하는 id로 설치된 앱의 id이다.

예를 들어 내가 갤럭시S7과 노트7를 가지고 같은 앱을 설치했다고 하더라도 각각 다른 디바이스에 설치되었기 때문에 각각의 앱 id는 다르다.


다음은 event_dim인데, event_dim은 이벤트들로 레코드들의 배열(리스트)로 구성이 되고 각각의 이벤트는 이벤트 이름과 그 이벤트에 값을 나타내는 name 과 params라는 필드로 구성이 되어 있다.  params는 레코드 타입으로 여러개의 인자를 가질 수 있고, params내의 인자는 또 각각 key와 value식으로 하여 인자의 이름과 값을 저장한다. values는 string_value,int_value,double_value 3가지 서브 필드를 가지고 있는데, 인자의 타입에 따라서 알맞은 필드에만 값이 채워진다. 예를 들어 인자의 타입이 문자열 “Cho” 이고, 인자의 이름이 “lastname”이면, params.key “lastname”이 되고, params.value.string_value=”Cho”가 되고 나머지 필드인 params.value.int_value와 params.value.float.value는 null이 된다.


   "event_dim": [

     {

       "name": "Screen",

       "params": [

         {

           "key": "firebase_event_origin",

           "value": {

             "string_value": "app",

             "int_value": null,

             "float_value": null,

             "double_value": null

           }

         },

         {

           "key": "Category",

           "value": {

             "string_value": "Main",

             "int_value": null,

             "float_value": null,

             "double_value": null

           }

         },

      ]

    },

     {

       "name": "Purchase",

       "params": [

         {

           "key": "amount",

           "value": {

             "string_value": null,

             "int_value": “5000”,

             "float_value": null,

             "double_value": null

           }

         }

         },

      ]

    },


위의 예제는 빅쿼리에 저장된 하나의 행을 쿼리하여 JSON형태로 리턴 받은 후, 그 중에서 event_dim 필드 내용 일부를 발췌한 것이다.

Screen과 Purchase라는 두개의 이벤트를 받았고,

Screen은 firebase_event_origin=”app”, Category=”main” 이라는 두개의 인자를 받았다.

Purchase는 amount=5000 이라는 정수형 인자 하나를 받았다.


전체 빅쿼리의 스키마는 다음과 같이 되어 있다.




파이어베이스 애널러틱스에서 빅쿼리로 저장된 테이블 스키마에 대한 상세는 https://support.google.com/firebase/answer/7029846?hl=en 를 참고하기 바란다.


구글 빅쿼리에 대한 자료 아래 링크를 참고하기 바란다.


  1. 2016.08.01 빅쿼리를 이용하여 두시간만에 트위터 실시간 데이타를 분석하는 대쉬보드 만들기

  2. 2016.07.31 빅데이타 수집을 위한 데이타 수집 솔루션 Embulk 소개

  3. 2016.06.18 빅쿼리-#3 데이타 구조와 접근(공유) (3)

  4. 2016.06.16 구글 빅데이타 플랫폼 빅쿼리 아키텍쳐 소개

  5. 2016.06.15 구글 빅데이타 플랫폼 빅쿼리(BIGQUERY)에 소개

  6. 빅쿼리로 데이타 로딩 하기 http://whitechoi.tistory.com/25


다음은 데이타랩을 통하여 데이타를 직접 분석해보도록 하겠다.