原文地址

最近在容器服務的官方鏡像中，新增了loghub-shipper的鏡像，使用該鏡像，可以訂閱日誌服務中的日誌庫，以秒級的延時將日誌數據從日誌服務中讀出並轉換成結構化數據存儲在表格存儲中，以滿足實時在線服務的精確查詢需求。

什麽是日誌服務？

日誌服務（Log Service，Log）是針對日誌場景的一站式解決方案，解決海量日誌數據采集/訂閱、轉儲與查詢功能，比如在海量遊戲日誌收集與分析場景上的應用。

什麽是表格存儲？

表格存儲(TableStore)提供海量NoSQL數據的存儲與實時訪問服務，能夠支持單表PB級數據量、百萬TPS，現在針對不同的場景有兩種實例規格可供使用：__高性能實例__，高並發低延時的特點適用於金融風控、互聯網社交等應用，而__容量型實例__以更具性價比的存儲和訪問成本，更適用於日誌、物聯網IoT等場景，比如基於表格存儲的高性能監控數據存儲計算方案。

為什麽需要將數據從日誌服務結構化到表格存儲中？

在日誌服務中，日誌數據以json形式進行存儲，並以日誌組為寫入與讀取的基本單位，這種情況下無法根據特定條件（比如某個App近12個小時的日誌數據)對日誌做快速的查詢和分析，只能拿到一段時間內所有設備、應用的日誌信息。

假設日誌數據格式如下：

{"__time__":1453809242,"__topic__":"","__source__":"10.170.148.237","ip":"10.200.98.220","time":"26/Jan/2016:19:54:02 +0800","url":"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0UjpekFQOVJW45A&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1","status":"200","user-agent":"aliyun-sdk-java"}
 

···

將其寫入到表格存儲中主鍵為”ip”、”time”的數據表中，其格式如下：

在表格存儲中，很容易對某個ip根據時間對歷史數據進行精確的檢索。

應用場景

日誌數據結構化到表格存儲之後，可以充分利用表格存儲的高並發、低延時、按量計費的特點提供精確查詢的在線服務：
1. 電商、信息類網站的最近瀏覽記錄展示。
2. 推薦引擎的數據源，基於用戶歷史行為習慣進行分析。
3. 實時推薦計算，根據用戶最近瀏覽實時調整推薦策略。
4. 對某個時間點的日誌信息的精確查詢，比如某臺出故障的機器最近24小時的運行情況。
5. 應用程序API基於時間段的延時統計、分析。

開啟數據同步

準備工作

在表格存儲上建好兩張表：數據表和狀態表。

數據表用來存儲從日誌服務中同步過來的日誌數據。教程裏我們假設這張表有三個主鍵列，分別是

rename，類型是 STRING。
trans-pkey，類型是 INTEGER。
keep，類型是 STRING。

狀態表用來存儲每個日誌服務Project以及各個shard上日誌數據的同步進度，該表的主鍵需要按照如下方式設置。 您的服務於多個 project 和 log store 的傳送服務可以復用同一張狀態表。 我們建議您將這張表的數據生命周期設置為一天或二天，這樣可以降低使用成本。 狀態表的主鍵有四列，分別為：

project_logstore，類型為 STRING。
shard，類型為 INTEGER。
target_table，類型為 STRING。
timestamp，類型為 INTEGER。

在容器服務控制臺創建集群和初始化

TIPS：當已經有ECS服務器時，可以將已購買的雲服務器添加到指定集群，添加已有雲服務器步驟

您需要對默認設置根據實際情況做一些改動。

• 低於盡可能和日誌服務與表格存儲選在同一個區域，這樣可以使用私網地址避免公網流量以及公網帶來的不確定性。
• 傳送服務並不是一個HTTP服務，不需要暴露任何端口。所以也無需負載均衡。
• 本教程選擇“新增節點”以方便演示。 生產上我們建議您選擇“不創建節點”，隨後按照添加已有雲服務器步驟添加現有的雲服務器。
• 傳送服務並不需要高配置的單機。一般情況下，“1核1GB”也足夠用了。 傳送服務可以完全動態的水平擴容縮容。 這裏可以選擇任意多臺ECS。

集群初始化需要一些時間，請您稍待。您可以點擊左側“集群”進入集群列表界面查看集群的狀態。

創建應用

進行基本的應用設置

按照下圖的參數填入一些應用環境參數信息，點擊頁面最後的“創建並部署”來部署傳送服務。

• 選擇傳送服務的鏡像。點擊“選擇鏡像”之後會彈出如上圖的選擇窗口。搜索"loghub-shipper"來快速找到傳送服務的鏡像，選中該鏡像（左上角藍底白色的勾），然後“確定”。

為鏡像添加配置信息：

• 部署服務需要一些時間。您可以通過服務列表來查看。就緒的服務如下圖。

到目前為止，傳送服務已經搭建好啦，讓我們想日誌服務中寫入一條日誌試試看效果吧。

寫入一條示例日誌數據

LogItem log = new LogItem();
log.PushBack("original", "12345");
log.PushBack("keep", "hoho");
ArrayList logs = new ArrayList<LogItem>();
logs.add(log);
loghub.PutLogs("lhshipper-test", "test-store", "smile", logs, "");

這是一條有兩個用戶字段的日誌，其中**original**字段的值為 "12345"，**keep**字段的值為 "hoho"。除此以外還有三個日誌服務添加的字段，其中 topic 為 "smile"，而 __source__ 和 __time__ 字段隨環境變化而變化。

查看數據表的信息

使用工具馬上可以看到表格存儲中數據表已經有了一條數據（轉成json格式方便描述）

[{"rename": "12345", "trans-pkey": 12345, "keep": "hoho"},
{"__topic__": "smile", "original": "12345"}]

其中，rename、trans-pkey、keep為主鍵列，__topic__與original為屬性列。

根據環境變量中的配置：

• 在 transform 中定義 "rename": "original"，日誌數據中original 的值為"12345"，故表格存儲中該行的rename的值也為 "12345"
• 在 transform 中定義 "trans-pkey": "(->int 10 original)"，傳送服務將original的值以十進制的方式轉成整數寫入表格存儲中的trans-pkey列
• keep沒有任何轉換規則，在表格存儲中，屬性類keep的值與日誌數據中的保持一致
• 日誌數據中的 __source__ 和 __time__ 字段由於在exclusive_columns 中配置了["__source__", "__time__" ]，這兩個字段的數據不會寫入數據表中
• topic和original兩個字段以屬性列的方式寫入數據表

查看狀態表

同時，我們也從狀態表中看到了如下數據（轉成json格式方便描述）：

[{"project_logstore": "lhshipper-test|test-store", "shard": 0, "target_table": "loghub_target", "timestamp": 1469100705202},
{"skip_count": 0, "shipper_id": "fb0d62cacc94-loghub-shipper-loghub-shipper-1", "cu_count": 1, "row_count": 1, "__time__": 1469100670}]

其涵義為傳送服務的某個worker（"shipper_id": "fb0d62cacc94-loghub-shipper-loghub-shipper-1"）， 在2016-07-21T11:31:45.202000Z添加了這條狀態（"timestamp": 1469100705202）

在之前的五分鐘裏，該worker從名為 lhshipper-test 的日誌 project中的 test-store 這個 log store （ "project_logstore": "lhshipper-test|test-store" ） 0號 shard （ "shard": 0 ）消費了一條日誌， 其中跳過日誌0條（ "skip_count": 0 ）， 寫入數據表的日誌1條（ "row_count": 1 ），消耗了1個CU（ "cu_count": 1 ）。

好啦，概耗時15分鐘就把日誌服務的數據秒級同步到表格存儲的傳送服務已經搭建好啦，日誌類數據就可以使用日誌服務的Logtail方便的采集到雲上，才通過傳送服務方便的將數據同步到表格存儲中，支持了不同的業務需要，簡直是神器啊~

原文地址

如何將日誌服務的數據秒級同步到表格存儲