本文是我在使用 Pandora 平臺的過程中遇到的問題總結，希望可以幫助到大家。
心動不如行動，趕緊開始使用 Pandora 來構建屬於你們自己的大數據平臺吧。
大數據是什麼？
大數據（英語：Big data），又稱爲巨量資料，指的是傳統數據處理應用軟件不足以處理它們的大或複雜的數據集的術語。在總數據量相同的情況下，與個別分析獨立的小型數據集（Data set）相比，將各個小型數據集合並後進行分析可得出許多額外的信息和數據關係性，可用來察覺商業趨勢、判定研究質量、避免疾病擴散、打擊犯罪或測定即時交通路況等；這樣的用途正是大型數據集盛行的原因。【摘自維基百科】
大數據平臺又是什麼？
我先給大家看看使用 Pandora 大數據平臺構建的一些效果圖吧。
Grafana 統計監控：

配置告警後的告警歷史
觸發警戒值之後還會發郵件的哦（帶圖的哦）
日誌上報後的查詢界面
上面這些圖表和功能，有沒有讓你心動呢？
基本介紹
Pandora 潘多拉(https://qiniu.github.io/pandora-docs/)是一套面向海量數據，以及基礎技術人員的，管理大數據傳輸、計算、存儲和分析的大數據平臺。
Pandora 共包含五個組件級服務：
如何開始？
目前 Pandora 大數據平臺產品處於有限開放、免費試用階段，你可以聯繫七牛的銷售或客服申請開通試用，也可以發送郵件給 pandora[AT]qiniu.com 註明您的公司名稱及聯繫方式，申請試用。他們在收到申請後一個工作日內爲您審覈。
* 申請註冊七牛賬號，登錄之後的界面如下：
- 申請 Pandora 大數據平臺的相關權限，通過之後登錄的界面如下：
從圖中，我們可以看出，側邊欄多了大數據工作流引擎、時序數據庫、日誌檢索，容器應用市場，這是 Pandora 包含的 5 個組件的入口。
- 容器應用市場
準備工作
Pandora 大數據平臺的基本流程如下：
* 通過（logkit/SDK/API ）打數據到工作流（workflow）；
* 在 workflow 中，進行數據計算和導出 (可導出到 TSDB/LogDB/HTTP/對象存儲)；
* 然後在 TSDB/LogDB 中查詢數據，或通過 Grafana 進行圖表繪製。
其中幾個組件服務的基本情況：
* 實時工作流、離線工作流（實時的數據源和消息隊列的數據存儲時間是2天）；
* 時序數據庫：創建倉庫（類比：數據庫）、序列（類比：表）[最大的數據存儲時限是30天]；
* 日誌檢索：創建倉庫[數據存儲時限：最大可設置爲永久]
* 容器應用市場：目前官方應用提供有Grafana，Kibana，XSpark；（這 3 個默認是沒有開通的，還需要再申請開通），第三方應用暫無；
構建實時和離線工作流
導出數據到對象存儲，需要注意：
* 如果我創建導出到對象存儲的時候選擇最早的話，工作流會追溯所有的數據，一直追到最新的數據（全量數據）；
* 如果我創建導出到對象存儲的時候選擇最新的話，工作流只從此時開始導數據（從此時開始的所有數據）；
* 全量數據也只追溯到2天前，因爲實時數據源和消息隊列的數據存儲時間只有2天。
通過（logkit/SDK/API ）打數據到工作流（workflow），我們在調用的時候要進行數據包封裝，最好不要一次觸發一次上報。
新功能：
* 工作流即將支持狀態，可以啓動和停止；
* 工作流即將增加行爲日誌；
服務器性能監控
參考文檔-服務器性能監控(https://qiniu.github.io/pandora-docs/#/demo/monitoring)進行構建的。
直接看我搭建好的效果圖吧。

以上數據是使用七牛優化過的 telegraf 上報的。
問題清單：
Q0: telegraf 是什麼？
telegraf(https://github.com/influxdata/telegraf) 是用於收集和上報指標的插件驅動服務器代理（這裏使用七牛優化後的版本）。
Q1: 運行 telegraf 報錯：create series diskio for repo monitor fail pandora error: StatusCode=404, ErrorMessage=E7100: Repo does not exist!
我們可以提前創建好對應的 Repo ，也可以讓程序在第一次使用的時候自動創建資源，如果存在以後就不會創建了。
日誌檢索，構建容器應用 Kibana
參考文檔-運維日誌分析 – Nginx 日誌分析搭建案例(https://qiniu.github.io/pandora-docs/#/demo/nginxlog)進行構建的。
我們先來看看效果圖吧，��
以上圖表數據均由 logkit 自動上報。
接下來我將遇到的問題，以 QA 的形式列出來，希望對大家有幫助。
Q0: 七牛的 LogDB+Kibana 和自建的 ElasticSearch+Kibana 相比有什麼優勢？
* 減少運維成本
* 資源開銷更少
* 自建的 ElasticSearch 是單機版的（當然也可以搭建集羣），而七牛的 LogDB 是可以水平擴容的；
* 七牛的日誌數據庫 LogDB 還可以和我們的 workflow 結合，做各種各樣的數據轉換等功能；
* 還有功能強大的 logkit ；
* 可以直接使用容器應用提供的 Kibana；
Q1: logkit 是什麼？
logkit(https://github.com/qiniu/logkit) 是七牛 Pandora 開發的一個通用的日誌收集工具，可以將不同數據源的數據方便的發送到 Pandora進行數據分析，除了基本的數據發送功能，logkit 還有容錯、併發、監控、刪除等功能。
支持的數據源：文件(包括csv格式的文件，kafka-rest日誌文件，nginx日誌文件等,並支持以grok的方式解析日誌)
* MySQL
* Microsoft SQL Server(MS SQL)
* Elasticsearch
* MongoDB
* Kafka
* Redis
Q2: logkit 日誌多久上報一次？
參看Runner之數據採集配置(https://github.com/qiniu/logkit/wiki/Runner之數據採集配置)。
Q3: [ERROR][github.com/qiniu/logkit/mgr] runner.go:389: Runner[nginx_runner] parser nginx_parser error : NginxParser fail to parse log
Nginx log format 不匹配導致（更多信息參考nginx-parser,grok-parser）。
Q4: 七牛的 CDN 日誌有延時嗎？
日誌延遲 8 小時，不能做實時監控，只能用離線工作流來做。
Q5: logkit 上報是什麼規則？
參看Runner之數據採集配置(https://github.com/qiniu/logkit/wiki/Runner之數據採集配置)。
Q6: 一次請求最大支持多少？
配置文件中可以配置，最大支持 2 MB，儘量將文件合併後上傳，減少調用次數，查看Runner之數據採集配置(https://github.com/qiniu/logkit/wiki/Runner之數據採集配置)。
Q7: 上報到日誌檢索服務後怎麼查看日誌來源？
logkit 有一個可支持配置的日誌來源的選項datasource_tag，更多請看File-Reader文檔(https://github.com/qiniu/logkit/wiki/File-Reader)
Q8: 搜索結果只有最近幾天的數據？
需要配置參數 retention，創建之後默認保留 3 天。
logkit(https://github.com/qiniu/logkit) 非常強大，一定要抽時間閱讀源碼。
時序數據庫，構建容器應用 Grafana
時序數據庫是什麼？
時間序列的數據庫。 業內比較著名的是 InfluxDB 。它是一個由 InfluxData 開發的開源時序型數據庫。它由Go寫成，着力於高性能地查詢與存儲時序型數據。InfluxDB 被廣泛應用於存儲系統的監控數據，IoT 行業的實時數據等場景。 本文則是 TSDB。
步驟很簡單：
SDK創建倉庫，然後再創建序列，再之後往序列上報數據。
問題（感謝我的小夥伴整理了這麼多的問題，希望能對你使用有幫助）：
Q0: 你們的時序數據庫 TSDB+Grafana 和自建的 InfluxDB+Grafana 相比有什麼優勢？
* 減少運維成本
* 資源開銷更少
* 自建的 InfluxDB 是單機版的，而七牛的 TSDB 是可以水平擴容的，不需要我們干預和關心；
* 七牛的時序數據庫 TSDB 還可以和他們的工作流（workflow） 結合，做各種各樣的數據轉換等功能；
* 可以直接使用容器應用提供的 Grafana ；
Q1: 通過 API 創建倉庫時出現 region 錯誤提示。
TSDB 目前只支持華東區域資源服務器，代號爲 nb ，需要指定。
Q2: 創建倉庫、序列、數據查詢過程中出現 bad token 提示。
鑑權不通過，token 過期，檢查 ak/sk 以及 token 。
Q3: 創建過工程中出現ak/sk錯誤。
* ak/sk 錯誤；
* 賬號並沒有添加 pandora 應用。
Q4: 插入數據時提示數據類型錯誤。
通過 API 請求插入數據時，需要注意類型對應的問題，在請求封裝時很有可能會因爲 map[][]而忽略這個問題。
Q5: 使用 distinct 去重查詢時，並且做 count 計算，數量不符。
需要注意空字段的情況，字段爲空時也佔用一個量。
Q6: 使用 select tag 查詢時出現錯誤
* 首先需要檢查字段是否錯誤。
* 在 TSDB 中，time 是一個默認的 tag ，在序列中也會自建 tag ，需要注意 tag 並不能作爲查詢主體，tag 只能作爲分組以及查詢條件。
Q7: TSDB 中 limit 與 offset 的使用。
limit 使用時與 MySQL 一致，需要注意的是空數據的存在。
Q8: group by 與 order by
group by 只能夠對 timestamp 以及 tag 使用，order by 可以用來對 timestamp 使用，做時間聚合。
Q9: TSDB 時間類型
RFC3339 YYYY-MM-DDTHH:MM:SS.nnnnnnnnnZ 使用時間作爲查詢條件時，可以採用如下運算符：
= 等於
<> 不等於
!= 不等於
大於
= 大於等於
< 小於
<= 小於等於
使用 TSDB 的 SDK 進行數據查詢時，可使用 time>’2017-09-18’ 的格式， 也可採用 InfluxDB 的時間格式 now() - 1d，需要注意的是在‘-’號左右都需要有空格，不然會提示語句出錯:E7200: Invalid sql: Invalid time condition, out of time range.。
Query 語句不支持select count(1) from stat_info where time >= ‘2017-09-19’， 報錯：E7200: Invalid sql, expected field argument in count()，field 必須指定。
Q10: 在初始化創建 Client 時，是否還要通過 SDK 函數生成配置？
需要通過 sdk.NewConfig() 生成配置，將其置於配置文件當中，否則就會出錯。
Q11: 錯誤定義是怎樣的？
在 TSDB 中，在 tsdb/error.go 裏面定義了錯誤類型，在開發時，可以進行引用，也可以通過 logger.Error() 進行輸出，通過對照編碼表查找錯誤原因。
Q12: API 建立倉庫、序列。
創建 Client 後，可以通過內置函數 CreateRepo() 以及 CreateSeries() 進行創建，參數定義在 tsdb/model.go 中，包含了需要傳入的參數以及返回數據類型結構。
Q13: API 數據查詢。
可以通過 client.QueryPoints() 進行查詢，參數爲 query 語句， 定義 query 語句傳入即可進行數據查詢，語法與 MySQL 以及 InfluxDB 大同小異。
返回類型包括：
QueryOutput{}
Result{}
Serie{}
在這裏常用的只需要返回 Serie 即可，通過 index 訪問數據，在這裏需要注意 index out of range ，所以需要進行非空判斷，以免造成程序出錯。
Q14: API 數據寫入
可以通過 client.WritePoints 寫入數據，需要注意區分 tags 與 fields ， 通過參數 point 進行參數配置，包括 SeriesName（序列名）、tags、fields 。
Q15: 序列的字段類型定義。
字段類型在創建序列時並不需要定義，在第一次傳入數據時，根據傳入數據的類型即定義了序列的字段類型， 需要注意的是序列不支持複合類型，之後進行數據寫入時，如果數據類型不一致，則會提示類型錯誤。
Q16: TSDB 存儲期限
目前最大支持 30 天，在自定義存儲期限時，也只允許定義在 30 天之內。
Q17: 數據查詢經常出現偏差(統計時較爲明顯)
* 確定語句是否按照標準，有一些語法與其他數據庫不一致；
* 字段名稱是否是 tsdb 關鍵字，如果是，需要通過雙引號；
* 如果使用了 distinct ，需要考慮字段爲空的情況；
* 如果使用了 order by 語句，需要考慮字段是否是 tag。
Q18: 有數據，但是查詢語句沒有結果。
Where field 查詢的時候要注意存儲的類型和你查詢的類型是否一致。
Q19: 在 Grafana 裏面 where 語句不能智能提示？
where 語句的下拉列表默認只智能提示 tag ，field 智能手動輸入。
Q20: Grafana 的Dashboard支持分配給不同的組織嗎？
不支持，智能導出某個Dashboard，然後在其他角色下重新導入。
Q21: Grafana 的數據源支持導出嗎？
不支持，只能手動錄入，同一個組織下可以共享數據源。
Q22: 統計指標多對頁面加載有影響嗎？
一個頁面的指標項太多會影響到整體的加載性能的。
七牛 APM
iOS https://github.com/pre-dem/pre-dem-objc
Android https://github.com/pre-dem/pre-dem-android
bugly 跟 七牛 APM 有什麼不同？
bugly 偏向於崩潰收集，七牛 APM 偏向於移動性能分析。
我們目前還未接入七牛 APM ，所以暫時沒有問題清單（還沒有踩坑，以後再補吧）。
其他
- 七牛是支持子賬號的，有需要的可以申請開通；
- 容器應用 Grafana 有自己的登錄賬號系統，Kibana 是用的七牛統一的賬號鑑權體系；
- Safari 可能默認是阻止彈窗的，記得允許彈窗；
總結
- 簡單
- 方便
- 好用
- 強大
擴展知識
可能會涉及到的知識點或開源組件，項目：
* InfluxDB
* OpenTSDB
* Grafana
* Kibana
* ElasticSearch
* logkit
* Nginx
* …