背景
產品經理想要實時查詢一些指標數據，在新版本的APP上線之后，我們APP的一些質量指標，比如課堂連接掉線率，課堂內崩潰率，APP崩潰率等指標，以此來看APP升級之后上課的體驗是否有所提升，上課質量是否有所提高，為下一步的APP升級做准備。
客戶端埋點
1.0版本設計
流程
按照需求打點，如果想知道某一指標如進入教室成功率，點擊進入教室這一動作上報數據，進入教室結果上報數據，同時上報課程id，用戶id等屬性。
缺點
埋點規范全靠Excel，產品經理編寫Excel埋點文檔，開發按照文檔埋點，測試按照文檔測試。出現如下幾類問題，
- 產品經理埋點文檔編寫失誤，漏埋點，埋點關鍵字錯誤，上報字段值不明確等；
- 埋點開發者打錯上報關鍵字，如device打錯成devcie，上報值使用全角輸入法，時間戳未按照規范上報成毫秒。
- 測試人員，不重視測試環節，只是粗略看下埋點是否存在，並未進行埋點質量的測試。
- 大數據開發進行數據清洗落地時，遇到未按照json格式上報的臟數據，由於上報值不規范，很多數據增加了清洗的難度和不確定性。
優點
整個流程跑起來了，有些計算指標具有參考意義。
2.0版本設計
規范埋點上報
經過調研，我們2.0采用Protobuf數據格式上報，並封裝成統一埋點SDK，一方面可以定義枚舉值，解決上報值和關鍵字不規范的問題。上報的信息進行歸類，簡潔明了。 我們定義了三種數據結構：
- 基礎信息
message BaseInfo {
//系統上報時間戳-毫秒(由銀河服務端生成) int64 sysTime = 1; //客戶端上報時間戳-毫秒 int64 time = 2; //會話Id，一段會話的唯一標識（客戶端每次啟動APP到下一次啟動APP之間生成一個會話id） //生成規則：16位隨機數+13位時間戳+3位(端表示pc:001 android:002 ios:003 web:004 server:005) string sessionId = 3; //設備唯一標識 string uuid = 4; //公司標識 Company company = 5; //sdk版本 SDKVersion sdkVersion = 6; //用戶ID string userId = 7; //用戶類型 UserType userType = 8; //日志類型 LogType type = 9; string eventId = 10;//事件ID (產品經理提供) NetType netType = 11;//網絡類型 OperatorType operatorType = 12;//網絡運營商類型 int32 requestCnt = 13;//接口請求次數，默認為1 string business = 14;//業務類型 (產品經理提供) //來源:安卓、iOS、pc、web、server Os os = 15; string channel = 16; // 渠道來源(針對前端的落地頁url編碼，H5商城的來源渠道) //APP版本號 string appVersion = 17; //APP類型：yimi/bubugao/yuxuepai string appType = 18; //設備型號，標示手機品牌+型號 string deviceInfo = 19; //設備操作系統版本號 string osVersion = 20; AppAction appAction = 21; //信息,崩潰信息 string info = 22; int64 stayTime = 23; //頁面停留時間 } - 教室內信息
message LiveInfo {
//課程id string lessonId = 1; //課程類型 LessonType lessonType = 2; //服務器IP string serverIp = 3; //用戶ip string userIp = 4; } - 其他信息
message ExtraInfo {
//額外字段key string key = 1; //額外字段value string value = 2; } 埋點元數據界面
基於1.0的一些缺點，我們進行了改造，開發了一個埋點元數據錄入的界面，產品經理只需要在上面錄入想要的埋點，規范上報值。開發者和測試者都可以在這個界面查看埋點的信息。
埋點測試流程規范
重新規划了埋點的測試流程，粗略流程如下
后端架構設計
Apache CarbonData是一種新的融合存儲解決方案，利用先進的列式存儲，索引，壓縮和編碼技術提高計算效率，從而加快查詢速度。其與Spark緊密結合，而我們公司的技術棧也包含Spark，經過測試查詢性能確實優秀，遂決定使用此組件。
社區BUG
在測試的過程中，由於想使用新版的Spark，所以使用了Spark2.3+CarbonData1.5的組合，但是在入庫的時候，發現了一個bug，Spark Streaming無法實時寫入表，社區對此bug至今也沒有解決。所以只能決定使用Spark 2.2+CarbonData1.5。
實時入庫
CarbonData表結構設計
CREATE TABLE IF NOT EXISTS carbon.dw_flow_disc_analyze_daily ( pt string, lesson_id string, app_version string, user_type string, app_device_type string, server_ip string, event_type string, err_msg string, msg_type string, galaxy_type string, sys_time string, app_type string, lesson_type string, result string, crash_type string, crash_msg string, down_load_result string ) STORED AS carbondata TBLPROPERTIES ( 'DICTIONARY_INCLUDE'='pt,lesson_id,server_ip,app_version,app_device_type,user_type,event_type,err_msg,msg_type,galaxy_type,app_type,lesson_type,result,crash_type,down_load_result,crash_msg', 'BAD_RECORD_PATH'='hdfs://bd-tst/apps/carbon/badrecords', 'INVERTED_INDEX' = 'lesson_id', 'sort_columns'='pt,lesson_id', 'SORT_SCOPE'='GLOBAL_SORT', 'RANGE_COLUMN'='pt', 'streaming'='true'); 參照CarbonData的官方文檔和例子，開發Spark Streaming程序，消費日志數據實時入庫。
OLAP
啟動Spark ThriftServer
nohup /opt/spark/spark-2.2.3/bin/spark-submit --master spark://bd-prod-master01:7077,bd-prod-master02:7077 --conf spark.sql.hive.thriftServer.singleSession=true --deploy-mode client --num-executors 4 --executor-memory 2g --executor-cores 2 --total-executor-cores 8 --class org.apache.carbondata.spark.thriftserver.CarbonThriftServer /opt/spark/spark-2.2.3/carbonlib/apache-carbondata-1.5.2-bin-spark2.2.1-hadoop2.7.2.jar hdfs://bd-prod/apps/carbon/warehouse >/dev/null 2>&1 & JDBC連接查詢
明細數據入庫之后，使用jdbc連接Spark ThriftServer，對指標進行實時聚合。
總結
優點
- 實時入庫，新版本APP上線后可以立刻看到買點數據；
- SQL靈活性高，可進行JOIN，條件可隨意定制；
- 查詢速度快，一個月之內的報表數據可在30s之內返回。
缺點
- 耗費資源比較嚴重，需要創建索引，需要的spark內存比較大，資源充足可忽略；
- 與Spark強耦合，不能使用Flink入庫；
- 社區不活躍。