為了探究云原生應(yīng)用系統(tǒng)的內(nèi)部狀態(tài)，我們希望向觀測數(shù)據(jù)中注入盡量豐富的標(biāo)簽，這些標(biāo)簽以往通過開發(fā)人員手動在代碼中注入，或通過配置 Promtheus、OpenTelemetry 實(shí)現(xiàn)，一方面造成了很大的工作量和資源開銷，另一方面也導(dǎo)致不同信號源的數(shù)據(jù)標(biāo)簽不一致形成數(shù)據(jù)孤島。DeepFlow 依靠 AutoTagging 機(jī)制可以為所有觀測信號統(tǒng)一注入標(biāo)準(zhǔn)的、豐富的標(biāo)簽，很好的解決了這些問題。SmartEncoding 的高性能編碼機(jī)制通過對標(biāo)簽數(shù)據(jù)的分離編碼和查詢時(shí)關(guān)聯(lián)，我們將存儲開銷降低了 10~50 倍，并且能支持無限量的 K8s label/annotation 等信息作為業(yè)務(wù)自定義標(biāo)簽。朋友們大家好，我是云杉網(wǎng)絡(luò)的宋貞，很高興今天能和大家一起分享 DeepFlow 的 AutoTagging 和 SmartEncoding 技術(shù)。這是 DeepFlow 的兩項(xiàng)關(guān)鍵核心技術(shù)，希望通過今天的介紹，可以讓大家詳細(xì)了解 AutoTagging 和 SmartEncoding 的實(shí)現(xiàn)方法，并為各位在可觀測性平臺的性能提升或者說是資源優(yōu)化方向提供一個(gè)思路。內(nèi)容下載：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)今天的分享將會從五個(gè)方面展開：

從可觀測性建設(shè)角度出發(fā)，總結(jié)大家在日常工作中遇到的痛點(diǎn)；
介紹 DeepFlow 的軟件架構(gòu)、系統(tǒng)組成；
講解 DeepFlow 的關(guān)鍵特性 AutoTagging 技術(shù)；
講解支撐 AutoTagging 10x 性能提升的 SmartEncoding 技術(shù)；
總結(jié)并分享后續(xù)的迭代和演進(jìn)計(jì)劃。

01觀測數(shù)據(jù)存儲的挑戰(zhàn)

可觀測性建設(shè)從去年開始在國內(nèi)非常的火熱，大家談的越來越多。隨著云原生、微服務(wù)的發(fā)展落地，可觀測性建設(shè)逐漸成為了一個(gè)必不可少的工程手段。

可觀測性建設(shè)耗時(shí)長我們認(rèn)為應(yīng)用開發(fā)團(tuán)隊(duì)花了一半的時(shí)間用于可觀測性的建設(shè)。這張圖里面可以看到，開發(fā)者通常需要考慮在不同的 Dev Stack 和 Infra Stack 中如何埋點(diǎn)、如何插碼、如何傳遞追蹤上下文、如何生成指標(biāo)/追蹤/日志數(shù)據(jù)并進(jìn)行關(guān)聯(lián)，需要考慮的問題太多太雜。除此之外開發(fā)者還有很多時(shí)間在做 Debug，而這些 Debug 之所以耗費(fèi)了這么多時(shí)間，通常大部分是因?yàn)榭捎^測性建設(shè)的欠缺導(dǎo)致。

可觀測性建設(shè)數(shù)據(jù)關(guān)聯(lián)難可觀測性指標(biāo)數(shù)據(jù)一般分為Tracing、Metric和Logging三類。

Tracing關(guān)注的元數(shù)據(jù)是traceID/spanID/service/...；
Metric關(guān)注的元數(shù)據(jù)是vpc/instance/node/kvm/...；
Logging關(guān)注的元數(shù)據(jù)是type/level/time/message/...。

每類指標(biāo)關(guān)注的元數(shù)據(jù)/標(biāo)簽各不相同，所以經(jīng)常會出現(xiàn)由于缺少數(shù)據(jù)標(biāo)簽，導(dǎo)致無法下鉆定位具體的主機(jī)、微服務(wù)、Pod、實(shí)例、API Endpoint；又或者無法關(guān)聯(lián)具體的 git commit id、service owner。同時(shí)數(shù)據(jù)標(biāo)簽的概念和定義繁多，比如有的用 service 表示服務(wù)，有的用 app 表示，進(jìn)一步導(dǎo)致了可觀測性數(shù)據(jù)的關(guān)聯(lián)困難。Prometheus應(yīng)該是大家都非常熟悉的一款軟件，它的 relabeling 機(jī)制能夠?qū)?Metrics 的標(biāo)簽進(jìn)行靈活的管理，Metrics 的所有標(biāo)簽都是在這個(gè)階段統(tǒng)一注入或轉(zhuǎn)換的，特別是 K8s 資源相關(guān)的信息。但是用過的各位應(yīng)該知道 relabeling 的配置非常復(fù)雜，可參見具體配置^[3]。可觀測性業(yè)界很火的 OpenTelemetry 也需要做復(fù)雜的 opentelemetry processor 配置去注入/丟棄/改寫標(biāo)簽。讓人崩潰的是，當(dāng)你歷盡千辛萬苦做到了各類指標(biāo)數(shù)據(jù)的無縫關(guān)聯(lián)，你會發(fā)現(xiàn)一個(gè)指標(biāo)需要攜帶上百個(gè)標(biāo)簽，消耗巨大的存儲資源，“可觀測性系統(tǒng)的資源消耗甚至超過了業(yè)務(wù)系統(tǒng)”。但幸運(yùn)的是，目前就有一款軟件可以很好的解決上面這些問題，而又不會耗費(fèi)過多資源，那就是DeepFlow可觀測性數(shù)據(jù)平臺。

02、DeepFlow 軟件架構(gòu)

DeepFlow軟件架構(gòu)DeepFlow的架構(gòu)其實(shí)非常簡單，它簡單到只有一個(gè)Agent和一個(gè)Server，分別是數(shù)據(jù)采集組件和數(shù)據(jù)存儲查詢組件。Agent是使用Rust來實(shí)現(xiàn)的，高性能且內(nèi)存安全，它通過eBPF技術(shù)實(shí)現(xiàn)了對任意開發(fā)技術(shù)棧、任意基礎(chǔ)設(shè)施的全自動應(yīng)用性能指標(biāo)數(shù)據(jù)采集（AutoMetrics），以及自動化的分布式鏈路追蹤（AutoTracing），這兩項(xiàng)是DeepFlow Agent獨(dú)有的能力，能極大降低開發(fā)者建設(shè)可觀測性的工作量。Server包含了4個(gè)內(nèi)部模塊：Controller面向采集器Agent的管理，能納管多資源池的10萬量級的Agent；Labeler面向標(biāo)簽數(shù)據(jù)的自動注入，提供AutoTagging的能力；Querier面向數(shù)據(jù)查詢，提供統(tǒng)一的SQL接口；Ingester面向數(shù)據(jù)存儲，提供插件化的、可替換可組合的數(shù)據(jù)庫接口。它支持水平擴(kuò)展，而且完全不依賴外部的消息隊(duì)列或負(fù)載均衡，就能夠去實(shí)現(xiàn)對多個(gè)Region、多個(gè)資源池中Agent的負(fù)載均攤。Server也有兩個(gè)非常核心的技術(shù)，AutoTagging和SmartEncoding。通過AutoTagging我們能為Agent采集到的所有觀測數(shù)據(jù)自動注入統(tǒng)一的資源、實(shí)例和API標(biāo)簽，使得我們能夠消除不同數(shù)據(jù)類型之間的隔閡，增強(qiáng)所有數(shù)據(jù)的關(guān)聯(lián)、切分、下鉆能力。SmartEncoding是我們非常創(chuàng)新的一個(gè)高性能的標(biāo)簽編碼機(jī)制，通過這個(gè)機(jī)制，我們既能方便的進(jìn)行數(shù)據(jù)關(guān)聯(lián)，又能將標(biāo)簽注入的存儲性能提升10倍，這在我們的實(shí)際生產(chǎn)環(huán)境中已經(jīng)進(jìn)行了廣泛的驗(yàn)證。

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

AutoTagging通過云API、K8s apiserver自動同步30多種資源標(biāo)簽、100多種自定義微服務(wù)標(biāo)簽，來構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系。

DeepFlow資源同步DeepFlow的標(biāo)簽體系：

自定義標(biāo)簽
- k8s.label/k8s.env/k8s.annotation/..
- os.app/os.proc/...
- cloud.tag
進(jìn)程
- 進(jìn)程名
云資源
- 資源池：區(qū)域/可用區(qū)
- 計(jì)算資源：云服務(wù)器/宿主機(jī)
- 網(wǎng)絡(luò)資源：VPC/子網(wǎng)/路由器/IP地址
- 網(wǎng)絡(luò)服務(wù)：安全組/負(fù)載均衡器/NAT網(wǎng)關(guān)/對等連接/云企業(yè)網(wǎng)
- 存儲資源：云數(shù)據(jù)庫RDS/Redis
容器資源
- 容器集群/容器節(jié)點(diǎn)/命名空間/Ingress/容器服務(wù)/工作負(fù)載/POD

下面，我們依次介紹一下對各類資源信息的同步機(jī)制，以實(shí)現(xiàn)標(biāo)簽庫的構(gòu)建。同步 K8s 資源:

為什么是 Agent watch 并上報(bào) K8s資源？一個(gè) Server 可以管理多個(gè)集群中的 Agent，Agent在所屬集群中watch K8s，避免了集群外部用 server watch 時(shí)涉及到的權(quán)限和配置問題。
如何控制 Agent 對 K8s 資源的 watch？避免 K8s 的 API 壓力過大，不能讓所有的 Agent 都去 watch K8s，Server 在每個(gè)集群中選舉一個(gè) Agent；僅讓被選中的 Agent watch K8s 資源。

除此之外，我們還需要考慮資源規(guī)模的問題，我們通過如下兩個(gè)措施降低 deepflow-agent 的資源消耗：

內(nèi)存優(yōu)化：Agent 僅抓取同步必須的字段，同時(shí)會第一時(shí)間進(jìn)行壓縮。
帶寬優(yōu)化：僅當(dāng) K8s 資源有變化時(shí)，Agent 才會向 Server 發(fā)送具體的資源信息

同步K8s資源的數(shù)據(jù)流同步云資源

同步云資源信息：通過調(diào)用云平臺 API 進(jìn)行資源抽象和轉(zhuǎn)換，然后將相關(guān)標(biāo)簽信息保存至 MySQL 中，并定期更新 ClickHosue 中的字典。
同步 Legacy Host 信息：一些環(huán)境中，可能沒有真正意義的云平臺，或者存在一些傳統(tǒng)主機(jī)需要監(jiān)控，這就需要用Legacy Host同步方案。由于沒有具體的云API，我們完全通過Agent抓取所在服務(wù)器的名稱等基本信息和網(wǎng)卡信息，上報(bào)給Server匯總并進(jìn)行資源抽象。
同步托管 K8s 信息：當(dāng) K8s 平臺部署在云資源上時(shí)，要做到真正的可觀測性，需要將K8s的資源和云資源關(guān)聯(lián)起來，才能真正做到無縫地關(guān)聯(lián)、切分和下鉆。我們一方面通過獲取 K8s 資源所在的 VPC，基于 VPC 內(nèi) IP 的唯一性，通過 VPC + IP 將 K8s 的容器節(jié)點(diǎn)與云服務(wù)器關(guān)聯(lián)起來；另一方面通過將云平臺的 API 調(diào)用與 K8s 獨(dú)立，兩者使用不同的調(diào)用頻率，從而解決大規(guī)模場景下，云平臺 API 慢與 K8s 資源更新快的矛盾。

同步云資源的數(shù)據(jù)流理想很豐滿，現(xiàn)實(shí)很骨感。我們努力想實(shí)現(xiàn)觀測數(shù)據(jù)無縫跳轉(zhuǎn)，但當(dāng)上百個(gè)標(biāo)簽呈現(xiàn)在眼前時(shí)，你會發(fā)現(xiàn)后端資源消耗飆升，性能急劇下降，整個(gè)平臺別說無縫跳轉(zhuǎn)了，連使用都成了問題。于是 SmartEncoding 技術(shù)誕生了。

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

SmartEncoding 將標(biāo)簽注入分為3個(gè)階段，通過采集時(shí)編碼、存儲時(shí)編碼、和查詢時(shí)編/解碼降低標(biāo)簽寫入的資源消耗，我們來詳細(xì)看看每個(gè)階段都如何實(shí)現(xiàn)：采集時(shí)編碼

采集時(shí)編碼Controller 根據(jù)云平臺和 K8s 資源抽象好標(biāo)簽信息進(jìn)行 Int 編碼后，并不會將所有的標(biāo)簽下發(fā)給 Agent。僅會下發(fā)最少量的標(biāo)簽。這樣 Agent 只需要為數(shù)據(jù)追加很少的Int標(biāo)簽即可。在混合云場景下，為了標(biāo)識資源我們可以用 VPC ID 作為基，它能和 IP 地址聯(lián)合決定客戶端、服務(wù)端對應(yīng)的實(shí)例和服務(wù)；可以通過 gpid 解決遠(yuǎn)端進(jìn)程信息標(biāo)記的問題。我們主要考慮 Agent 做的工作盡量少，這樣可以最大限度的降低采集器的 CPU、內(nèi)存消耗，以及傳輸數(shù)據(jù)的帶寬消耗。我們在生產(chǎn)環(huán)境中發(fā)現(xiàn)有些 K8s 的標(biāo)簽會非常長，key 和 value 高達(dá)上百個(gè)字節(jié)。可以想象如果我們將上百個(gè)標(biāo)簽注入每個(gè)請求傳輸?shù)胶蠖?，消耗的帶寬會非常可觀。存儲時(shí)編碼

存儲時(shí)編碼同樣 Controller 會向 Ingester 下發(fā) Int 標(biāo)簽，但僅下發(fā)持久化存儲的標(biāo)簽。Ingester 在收到 Agent 發(fā)過來的數(shù)據(jù)后，會進(jìn)行一輪標(biāo)簽的擴(kuò)充，將 Agent 注入的少量標(biāo)簽擴(kuò)展為更為豐富的標(biāo)簽集合。但這里注意的是，我們并不存儲自定義標(biāo)簽。標(biāo)簽的存儲是為了方便檢索和聚合，我們只需要保證每個(gè)切分粒度上都有標(biāo)簽存在即可。舉例來講我們存儲 Region、AZ、VM、Node、Namespace、Service、POD 等固定的云或者 K8s 資源標(biāo)簽即可，而其他的自定義的標(biāo)簽一般是依附在這些標(biāo)簽之上的，存在一定的對應(yīng)的關(guān)系。另外，自定義標(biāo)簽動態(tài)性高，也不適合全部存儲。根據(jù)我們的經(jīng)驗(yàn)，一般每一個(gè)請求涉及到的的固定標(biāo)簽在40個(gè)左右，自定義標(biāo)簽在60個(gè)左右。通過只存儲固定的資源標(biāo)簽，我們能將壓力進(jìn)一步降低。查詢時(shí)編/解碼

查詢時(shí)編解碼DeepFlow SQL支持通過字符串查詢和聚合，并且也支持自定義標(biāo)簽的查詢和聚合。這里我們依賴 ClickHouse 的字典能力。通過編碼自定義標(biāo)簽的 Filter 和 Group 查詢請求，利用 ClickHouse 的字典轉(zhuǎn)換為系統(tǒng)標(biāo)簽；同時(shí)對于 Select 請求也可以利用 ClickHouse 的字典將系統(tǒng)標(biāo)簽轉(zhuǎn)為字符串或者自定義標(biāo)簽返回。我們再來回顧一下這三級編解碼，可以發(fā)現(xiàn)它能為我們節(jié)省大量的資源消耗，性能提升應(yīng)該十分可觀。一方面采集器的CPU、內(nèi)存可以降低，傳輸帶寬可以降低，最主要的還是后端存儲開銷的降低。我們在談?wù)摽捎^測性時(shí)經(jīng)常會談到采樣、避免高基數(shù)等。ClickHouse 采用稀疏索引，很好的避免了高基數(shù)問題。我們在此之上的多級編解碼又能將存儲開銷顯著降低，而且由于查詢階段掃描的數(shù)據(jù)量變小了，所以能獲得更好的查詢性能。這里有一些數(shù)據(jù)可以看一下，DeepFlow 默認(rèn)使用 ClickHouse 存儲數(shù)據(jù)，在 SmartEncoding 的加持下，標(biāo)準(zhǔn) Tag 的 CPU 和磁盤消耗相比 LowCard 存儲或直接存儲有一個(gè)數(shù)量級的優(yōu)化，而由于自定義 Tag 不會隨數(shù)據(jù)寫入，在通常的場景下整體寫入資源消耗可降低50倍。

做了這么復(fù)雜的編碼以后，如何讓查詢變得簡單呢？下面我們來介紹 deepflow-server 的查詢抽象層，它向用戶隱藏了寫時(shí)編碼和讀時(shí)關(guān)聯(lián)的復(fù)雜邏輯，用戶對數(shù)據(jù)的查詢就像在一張大寬表上進(jìn)行，體驗(yàn)非常絲滑。例如，我們可以直接查詢所有表中的數(shù)據(jù)：

SELECTcol_1,col_2,col_3 FROMtbl_1 WHEREcol_4=y GROUPBYcol_1,col_2 HAVINGcol_5>100 ORDERBYcol_3 LIMIT100 ``` 我們可以查詢某個(gè) Tag 的所有候選項(xiàng)： ```sql SHOWtag${tag_name}valuesFROM${table_name}

SHOWtag${tag_name}values FROM${table_name} WHEREdisplay_nameLIKE'*abc*'

SELECTpod FROM`vtap_flow_port.1m` WHEREpod_cluster='cluster1' GROUPBYpod 更多詳細(xì)用法^[4]查詢 Universal Tag

ClickHouse 的觀測數(shù)據(jù)表中保存tag ID

CREATETABLEflow_metrics.`vtap_flow_port.1m` ( `time`DateTime('Asia/Shanghai')COMMENT'v6.1.8'CODEC(DoubleDelta), `ip4`IPv4COMMENT'IPv4地址', `ip6`IPv6COMMENT'IPV6地址', `is_ipv4`UInt8COMMENT'是否IPV4地址.0:否,ip6字段有效,1:是,ip4字段有效', `l3_device_id`UInt32COMMENT'ip對應(yīng)的資源ID', `l3_device_type`UInt8COMMENT'ip對應(yīng)的資源類型', `l3_epc_id`Int32COMMENT'ip對應(yīng)的EPCID', `pod_cluster_id`UInt16COMMENT'ip對應(yīng)的容器集群ID', `pod_group_id`UInt32COMMENT'ip對應(yīng)的容器工作負(fù)載ID', `pod_id`UInt32COMMENT'ip對應(yīng)的容器PODID', `pod_node_id`UInt32COMMENT'ip對應(yīng)的容器節(jié)點(diǎn)ID', `pod_ns_id`UInt16COMMENT'ip對應(yīng)的容器命名空間ID' ) ENGINE=Distributed(...)

ClickHouse 的字典表中保存tag ID和名稱對應(yīng)關(guān)系

CREATEDICTIONARYflow_tag.pod_map ( `id`UInt64, `name`String, `icon_id`Int64 ) PRIMARYKEYid SOURCE(...)

通過 dictGet 實(shí)現(xiàn)tag ID到名稱的轉(zhuǎn)換

SELECTdictGet(flow_tag.pod_map,'name',toUInt64(pod_id))ASpod FROM`vtap_flow_port.1m` WHEREpod='deepflow' GROUPBYpod LIMIT1 查詢 K8s label

ClickHouse 的字典表中保存tag ID和 K8s label對應(yīng)關(guān)系

CREATEDICTIONARYflow_tag.k8s_label_map ( `pod_id`UInt64, `key`String, `value`String, ) PRIMARYKEYpod_id,key SOURCE(...) LIFETIME(MIN0MAX60) LAYOUT(COMPLEX_KEY_HASHED())

通過 dictGet 實(shí)現(xiàn)tag ID到 K8s label 的轉(zhuǎn)換

SELECTdictGet(flow_tag.k8s_label_map,'value',(toUInt64(pod_id),'app'))AS`label.app` FROM`vtap_flow_port.1m` WHERE`label.app`='xxx' LIMIT1 查詢集成數(shù)據(jù)，包括 Prometheus、Telegraf、OpenTelemetry 等數(shù)據(jù)。

存儲集成數(shù)據(jù)時(shí)，會將數(shù)據(jù)中原有的 Tag 和 Metric 的 name 和 value 分別定義為 Array 類型，一一對應(yīng)。

CREATETABLEext_metrics.prometheus_web ( `time`DateTime('Asia/Shanghai')CODEC(DoubleDelta), `_tid`UInt8COMMENT'用于區(qū)分trident不同的pipeline', `az_id`UInt16COMMENT'可用區(qū)ID', `host_id`UInt16COMMENT'宿主機(jī)ID', `tag_names`Array(String)COMMENT'額外的tag', `tag_values`Array(String)COMMENT'額外的tag對應(yīng)的值', `metrics_float_names`Array(String)COMMENT'額外的metrics', `metrics_float_values`Array(Float64)COMMENT'額外的metrics值' )

Tag 候選項(xiàng)只需要保留不重復(fù)的值，所以我們使用 ReplacingMergeTree Engine

CREATETABLEflow_tag.ext_metrics_custom_field_local ( `time`DateTime('Asia/Shanghai')CODEC(DoubleDelta), `table`LowCardinality(String), `vpc_id`Int32, `pod_ns_id`UInt16, `field_type`LowCardinality(String)COMMENT'value:tag,metrics', `field_name`LowCardinality(String), `field_value_type`LowCardinality(String)COMMENT'value:string,float' ) ENGINE=ReplacingMergeTree(time)

通過 indexOf 進(jìn)行 name 和 value 的對應(yīng)

SELECTtag_values[indexOf(tag_names,'host')]AS`tag.host` FROMdeepflow_agent_collect_sender WHERE(tag_values[indexOf(tag_names,'host')])='xxxx' LIMIT1

05、總結(jié)與后續(xù)迭代計(jì)劃

通過以上分享，相信您會發(fā)現(xiàn)DeepFlow有豐富、統(tǒng)一的標(biāo)準(zhǔn)化標(biāo)簽體系，非常方便進(jìn)行數(shù)據(jù)關(guān)聯(lián)、切分、下鉆。通過 SmartEncoding 的性能優(yōu)化，Server + ClickHouse 的資源消耗通常為業(yè)務(wù)消耗的 1%，即監(jiān)控100個(gè) 16c64g 的容器節(jié)點(diǎn)，大概需要1個(gè) 16c64g 的 Node 部署 Server + ClickHouse，且可以通過對象存儲轉(zhuǎn)儲冷數(shù)據(jù)；而且常見的可觀測性數(shù)據(jù)一般都需要注入百量級的標(biāo)簽，DeepFlow Agent 由于只注入了 VPC、GPID 少數(shù)幾個(gè)字段，因此它用于標(biāo)簽注入的資源消耗幾乎只有其他方案的百分之幾。這樣10x性能的使用體驗(yàn)，相信 Cloud-Native、NewOps 都會喜歡！后續(xù)我們會支持更豐富的自定義標(biāo)簽，包括通過 K8s API 獲取的k8s.annotation 和 k8s.env、通過操作系統(tǒng)獲取的 os.proc 信息、通過執(zhí)行命令獲取 os.app 信息；會從時(shí)間和帶寬消耗兩方面進(jìn)一步優(yōu)化AutoTagging的性能，通過不同類型資源的 API 可以設(shè)置不同的調(diào)用頻率，避免每次都是重新獲取全部資源來縮短縮短大規(guī)模下的資源同步時(shí)間；通過Agent 僅發(fā)送有變化的 K8s 資源信息，進(jìn)一步降低帶寬消耗。

06、關(guān)于DeepFlow

DeepFlow^[5]是一款開源的高度自動化的可觀測性平臺，是為云原生應(yīng)用開發(fā)者建設(shè)可觀測性能力而量身打造的全棧、全鏈路、高性能數(shù)據(jù)引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術(shù)，創(chuàng)新的實(shí)現(xiàn)了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機(jī)制，幫助開發(fā)者提升埋點(diǎn)插碼的自動化水平，降低可觀測性平臺的運(yùn)維復(fù)雜度。利用 DeepFlow 的可編程能力和開放接口，開發(fā)者可以快速將其融入到自己的可觀測性技術(shù)棧中。審核編輯：李倩

聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。舉報(bào)投訴

核心技術(shù)

核心技術(shù)

+關(guān)注

關(guān)注
4

文章
625

瀏覽量
19553
數(shù)據(jù)存儲

數(shù)據(jù)存儲

+關(guān)注

關(guān)注
5

文章
950

瀏覽量
50810
軟件架構(gòu)

軟件架構(gòu)

+關(guān)注

關(guān)注
0

文章
64

瀏覽量
10268

原文標(biāo)題：DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

文章出處：【微信號：AI_Architect，微信公眾號：智能計(jì)算芯世界】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

5G手機(jī)?Redmi 10X性價(jià)比很高？Redmi 10X怎么樣？來看看Redmi 10X拆解

，Redmi又?jǐn)y手聯(lián)發(fā)科天璣820，發(fā)布Redmi 10X，最低售價(jià)1599。主打高性價(jià)比，是否如實(shí)，一拆便知。本次拆解的是Redmi 10X，6GB RAM+ 128GB ROM版。以下數(shù)據(jù)信息均以拆解

發(fā)表于 08-11 10:37 ?1.5w次閱讀

示波器的10X檔和1X檔輸入阻抗

選擇1X檔時(shí)，信號是沒經(jīng)衰減進(jìn)入示波器的。而選擇10X檔時(shí)，信號是經(jīng)過衰減到1/10再到示波器的。當(dāng)選擇10X檔時(shí)，應(yīng)該將示波器上的讀數(shù)也擴(kuò)大10

發(fā)表于 05-20 14:43

10X genomics課程筆記

課程筆記10X genomics10X genomics技術(shù)：文獻(xiàn)在10X官網(wǎng)中的publications。對單個(gè)細(xì)胞做RNA表達(dá)情況的定量分析?；谟桶闈嵋好阜磻?yīng)原理的分子生物學(xué)分析系統(tǒng)?？梢?/div>
發(fā)表于 07-29 09:00

微軟承認(rèn)基于虛擬化的功能將會讓W(xué)indows 10X的性能更出色

Windows 10X遠(yuǎn)不只是Windows 10的新版本，因?yàn)樗辉O(shè)計(jì)為有著與Windows 7或Windows 10不同的應(yīng)用程序、文件和軟件交互體驗(yàn)。在Windows 10X系統(tǒng)

發(fā)表于 03-10 14:21 ?1778次閱讀

微軟Windows 10X系統(tǒng)支持UWP應(yīng)用和Win32應(yīng)用程序運(yùn)行

微軟確認(rèn)Windows 10X系統(tǒng)能夠運(yùn)行UWP應(yīng)用、網(wǎng)頁應(yīng)用以及傳統(tǒng)的Win32應(yīng)用程序。Win32、UWP和PWA應(yīng)用程序都會通過Windows 10X的容器進(jìn)行運(yùn)行，從而保護(hù)操作系統(tǒng)免受潛在的惡意軟件和性能問題的影響。

發(fā)表于 05-15 17:04 ?2226次閱讀

Windows 10X春季正式上線，面向輕量級設(shè)備

根據(jù)目前掌握的信息Windows 10X將會在今 12月進(jìn)入RTM階段，預(yù)估會在今年春季正式上線。而Windows 10X系統(tǒng)的主要更新會在每年的春季上線，因此微軟希望Windows 10給其讓路

發(fā)表于 11-09 09:18 ?1267次閱讀

微軟正式公開Windows 10X取代Windows 10，12月進(jìn)入RTM階段

微軟已經(jīng)正式公開了Windows 10X了，作為取代Windows 10的新系統(tǒng)，你對它期待嗎？根據(jù)目前掌握的信息Windows 10X將會在今年12月進(jìn)入RTM階段（下月就能用到），預(yù)估會在今年

發(fā)表于 11-20 12:14 ?2110次閱讀

Windows 10X今年即將到來？

微軟正在開發(fā)Windows 10X系統(tǒng)，已經(jīng)不是什么秘密了。最近更是有消息顯示，在本年度的12月份，微軟就會公布Windows 10X的RTM版本，在明年的1月份Win10X則會正式推向市場。作為

發(fā)表于 12-06 10:11 ?1196次閱讀

微軟即將新推出Windows 10X系統(tǒng)

微軟正在開發(fā)Windows 10X系統(tǒng)，已經(jīng)不是什么秘密了。最近更是有消息顯示，在本年度的12月份，微軟就會公布Windows 10X的RTM版本，在明年的1月份Win10X則會正式推向市場。

發(fā)表于 12-06 11:00 ?2114次閱讀

盤點(diǎn)匯總Windows 10X的亮點(diǎn)功能

微軟已經(jīng)完成了Windows 10X的RTM版，并將分發(fā)給硬件制造商。預(yù)計(jì)，Windows 10X將于2021年初與微軟合作伙伴的硬件產(chǎn)品一起推出，包括惠普、戴爾、聯(lián)想等。

發(fā)表于 12-23 10:57 ?1198次閱讀

Windows 10X相較Windows 10有哪些亮點(diǎn)？

Windows 10X是一款面向雙屏可折疊設(shè)備的操作系統(tǒng)。在沉寂了幾個(gè)月后，微軟終于完成了Windows 10X的RTM版，后續(xù)將分發(fā)給硬件制造商，預(yù)計(jì)將于2021年初用在惠普、戴爾、聯(lián)想等品牌的硬件產(chǎn)品上。那么，Windows 10X

發(fā)表于 12-23 14:52 ?1780次閱讀

淺談Windows 10X與Windows 10的主要區(qū)別

Windows 10X是在Windows 10的基礎(chǔ)上開發(fā)，采用現(xiàn)代的組件取代舊的程序，用戶界面相似，但是取消了活動磁貼以及文件資源器等。Windows 10X在2020年12月就完成了RTM版，微軟計(jì)劃在3月-6月期間正式發(fā)布

發(fā)表于 01-12 09:24 ?3050次閱讀

微軟Windows 10X鏡像疑似泄露

盡管微軟尚未正式發(fā)布Windows 10X，但鏡像已經(jīng)泄露。

發(fā)表于 01-26 09:18 ?1791次閱讀

微軟全面開放Windows 10X的鏡像

微軟傾力打造的Windows 10X系統(tǒng)已經(jīng)完全泄露，但鏡像僅支持Surface Pro 7。

發(fā)表于 02-02 11:23 ?1607次閱讀

10x無源探頭正確使用方法介紹

用好無源探頭。10x無源探頭的最佳用法使用10x無源探頭時(shí)，有五個(gè)重要的最佳測量準(zhǔn)則要遵守，以獲得10x探頭的最佳性能并避免常見的錯誤： 1、使用示波器前面板上的校準(zhǔn)參考信號來補(bǔ)償探頭

發(fā)表于 04-06 16:06 ?4055次閱讀

搜索歷史

DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

01觀測數(shù)據(jù)存儲的挑戰(zhàn)

02、DeepFlow 軟件架構(gòu)

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

05、總結(jié)與后續(xù)迭代計(jì)劃

06、關(guān)于DeepFlow

評論

5G手機(jī)?Redmi 10X性價(jià)比很高？Redmi 10X怎么樣？來看看Redmi 10X拆解

示波器的10X檔和1X檔輸入阻抗

10X genomics課程筆記

微軟承認(rèn)基于虛擬化的功能將會讓W(xué)indows 10X的性能更出色

微軟Windows 10X系統(tǒng)支持UWP應(yīng)用和Win32應(yīng)用程序運(yùn)行

Windows 10X春季正式上線，面向輕量級設(shè)備

微軟正式公開Windows 10X取代Windows 10，12月進(jìn)入RTM階段

Windows 10X今年即將到來？

微軟即將新推出Windows 10X系統(tǒng)

盤點(diǎn)匯總Windows 10X的亮點(diǎn)功能

Windows 10X相較Windows 10有哪些亮點(diǎn)？

淺談Windows 10X與Windows 10的主要區(qū)別

微軟Windows 10X鏡像疑似泄露

微軟全面開放Windows 10X的鏡像

10x無源探頭正確使用方法介紹

搜索歷史

DeepFlow AutoTagging 10x性能提升實(shí)戰(zhàn)

01觀測數(shù)據(jù)存儲的挑戰(zhàn)

02、DeepFlow 軟件架構(gòu)

03、AutoTagging：構(gòu)建標(biāo)準(zhǔn)化的標(biāo)簽體系

04、SmartEncoding：實(shí)現(xiàn) 10x 性能提升

05、總結(jié)與后續(xù)迭代計(jì)劃

06、關(guān)于DeepFlow

評論

02、DeepFlow 軟件架構(gòu)

05、總結(jié)與后續(xù)迭代計(jì)劃