“我們不能用創造時的相同思路來解決問題”——愛因斯坦

Datadog $Datadog(DDOG.US) 兩年前在納斯達克上市，集資 7.45 億美元，上市時市值 78 億美元。首日大漲 40%，兩年後的今天市值漲了 6.2 倍。此前寫了不少關於 SaaS 的股票和行業，其中寫網安的行業研究得到了讀者的廣泛歡迎，近期寫了一篇新股 Gitlab 的也得到了較高的關注度。Datadog 是一家多業務的數據及應用監控公司，與我之前寫的 SaaS 多少都有關聯，都是乘着企業數字化轉型和雲端遷徙的東風成長起來的公司。Datadog 與多個大型 SaaS 公司在細分領域均有競爭關係，與幾個 IaaS 平台公司也有競爭關係，通過了解 Datadog 的產品與財務情況，我們可以更深入地瞭解行業與雲計算。

什麼是 Datadog

Datadog 就是一個為雲端軟件基礎設施提供全維度監測的服務。提供對基礎設施全棧 (full stack) 性能的實時可見性（visibility）。上至最頂端的應用程序，到中間的 Kubernetes/Docker/Hypervisor，到操作系統，以及中間的數據庫，第三方服務等全棧的性能監測。

應用程序監測的歷史背景

任何一家傳統跨國大型企業都在運行着一些傳統的，高度定製化的企業級信息系統軟件。公司內部有成千上萬的員工用户同時使用這些系統。這些內部用户當在運行程序遇到問題時就會發出請求幫助的 Ticket（即請求 IT 部門協助的系統內部消息，填寫故障描述等），在收到這些 tickets 之前 IT 部門不會知道出了故障。可見如果沒有一種工具為企業 IT 部門提供監測（最好是實時監測）從發現問題開始的每一步都會延誤故障排查和解決的效率。如果這些故障與前端銷售相關，則每一分每一秒都會影響公司的收入。

在 Datadog 或其競品出現之前，企業是如何監測 IT 系統的呢？每一個技術 Stack 的同事及其團隊擁有一個自己的工具包來監測自己轄下的信息系統：數據庫團隊有一個自己的工具，Windows 團隊有一個自己的工具，網絡團隊有一個自己的工具，一個企業 IT 部門合共有十幾個監測工具。而這十幾個性能監測工具互不相連。當故障出現之後，相關的幾個團隊需要互發郵件將問題拼拼圖，拼出全貌，期間充滿延誤與挫折感。

上一篇 SaaS 專欄（Gitlab IPO）中講到當代的企業軟件和網略應用的迭代非常頻繁，微服務，Container，Kubernetes，分佈式計算等潮流推動了高速頻繁及碎片化的應用程序更新。如果每推出一些新的功能改善都等候人工測試或用户故障彙報，效率過低。有了實時監控系統後，企業可以自行使用軟件機器人等技術模擬測試任何新老應用的運行環境，配合實時監控系統，可以大大減少宕機時間和資源成本。

另一個例子，當疫情席捲世界後，許多跨國企業不同程度開始遠距離辦公，上萬員工同時在世界各地通過不同的設備接入公司網絡或雲端系統。一個統一的監測面板（dashboard）可以一目瞭然的監測到每一個個體員工的設備接入速率，帶寬情況，接入個別系統（微軟 Azure 或 Office 365）是否出現過度網絡延遲，哪些國家哪些地區的員工正在經歷數據包丟失，甚至可以指向當地的互聯網服務商（ISP），提醒 ISP 並儘快恢復網絡到正常水平。

當代的技術潮流讓傳統 IT 架構不堪重負

Containers, microservices, serverless……等等技術潮流帶動了企業信息系統雲轉型。這些技術令企業 IT 環境高度動態及短暫化（ephemeral），對比 on-prem 傳統體系的靜態化。SaaS 平台和開源工具為企業 IT 開發人員提供了爆發式增長且既強大又敏捷的技術支持。對比以往的大型軟件供應商，開源的軟件開發潮流使得所需計算資源指數級增長。應用程序的更新從以往幾個月到幾年縮短至以天以分鐘計。以往的傳統 IT 系統性能監控軟件無法適應並提供當代計算所需求的實時可見性與洞見（insight）。

Datadog 試圖做到的是將企業原本的十幾個到最多幾十個互相割裂的 IT 監測系統整合成一個，既提高監控效率，又降低企業的 IT 支出。

Datadog 的技術核心

Datadog 的技術核心處在上圖這個流程表中綠色的這一部分。

(我認為了解這個行業需要了解數據庫技術的歷史以及背景知識，內容比較乾燥，沒有興趣的額可以直接跳到產品特性及競爭格局)

Observability 的三大支柱

網絡應用在開發及使用過程中會產生 Logs，Metrics 和 Traces。這三者所提供的數據構成了監測的三大支柱。

Log

事件日誌 Event logs 是不可變的，有時間標記的單獨事件，事件日誌 log 的格式可以有多種，但均包含時間信息和事件背景紀錄。系統之中不常見的問題調試通常需要事件日誌，長尾故障可以通過了解分析背景紀錄得到洞見。事件日誌對發現系統的緊急或不可預見錯誤非常有用。

複雜的分佈式系統（多雲，分佈式計算）的故障通常不是單一組件的單一事件觸發的。高度相連的組件中可能有多個觸發點。如果單獨審視某個系統某個時間的單一事件，無法找出所有觸發點。想要找出所有觸發點，就要做到以下幾個步驟：

1.從某個系統的高層 Metric 或者一個 Log 所顯示的症狀着手；

2.在分佈式系統的各部件 Infer 這個請求（ request ）的整個生命週期；

3.在此過程中通過迭代檢查系統各部件的互動作用。

以上三個步驟是傳統 log management 軟件無法做到的，Datadog 的新產品 Synthetics 比較好的可以做到這種模擬推論。

Log 是最容易生成，幾乎所有的編程語言，應用架構，庫都支持某種日誌行為。但雖然 log 生成很容易，但性能卻參差不齊。如果 logging 沒有足夠的優化，可能也會影響應用程序的運行。

Datadog 的 Log Management 產品是通過收購 Logmatic.io 公司實現的。Logmatic 是 2012 年創始的公司，幾個法國人是一家法國知名的數據分析公司 QuartetFS（現名 ActiveViam）的核心產品 ActivePivot 的團隊成員。Logmatic 產品 2014 正式推出，不到三年後就在 2017 年被 Datadog 收購 (金額未披露，老鄉一切好説）。

Log 管理有兩大技術派系分別是老派的 Splunk（$Splunk.US ）和新派的 Elastic（$Elastic NV(ESTC.US) ）。兩者的最大區別就是對於 log 的處理方式是 Schema on read 或 Schema on write。要了解這兩者的區別就要了解結構性數據（Structured data）和非結構性數據（Unstructured data）。所謂結構性數據就是將數據結構化：

我們拿餐廳的菜單來做個例子：

上圖的數據是錄入的結構化數據，第 9 行之前都是在定義結構：第 5 行規定第一項是商品編號，並定義商品名稱，第 7 行定義商品編號下的 4 個成分，第 9 行則規定商品編號下的卡路里，脂肪，蛋白質和鈉的量。13-15 行就是方便機器閲讀的結構化數據，每一格的數據都已經被清晰定義。

再看上圖的數據就是非結構數據，這個數據可以是直接鍵盤輸入的，商品名稱，成分列表，然後各項營養數據都是平行列出，這種方便人類閲讀但是不方便機讀的就是非結構數據。

Schema on write 就是圖一的處理數據方式：將 log 等信息在錄入數據庫時就進行結構化。優點是方便錄入後未來每一次查詢（query）都可以快速得出結果。尤其是數據規模爆炸式增長時，且如果任務偏重於數據分析的實時性和性能更重要時，搜索速度和效率就會更有價值。

Schema on read 則是圖二的數據處理方式：將 log 等信息高速錄入數據庫，但是隻有在每次調用時才進行結構化。當有大量新增數據來源或者短時間內需要錄入大量數據時，on read 可以高速記錄節省時間，但是對於大數據分析則難以與 on write 效率相比。

將非結構性數據轉成結構性數據的這個步驟叫做 Parse。

自從有數據庫技術以來，兩種模式都有各自的用武之地。然而，自企業數字化轉型及雲遷徙浪潮展開以來，數據可見性，應用監控，性能分析，商業洞見分析，雲網絡安全，以及一系列的數據搜索需求都將天平向優先搜索效率傾斜。上述的這些應用範圍都是基於搜索的（search 或者查詢 query）結構性數據搜索即使範圍再大也都能在毫秒級完成，而同樣的搜索在非結構數據庫的時間在幾分鐘到幾小時之間。對於 Observability 應用，結構性數據才能做到 Log，Metric 和 Trace 的相互關聯性（correlate），發出一個查詢之後可以在三者之間任意切換才可以全局性瞭解事件的起因，影響和最佳解決方案。而高效高規模化地完成這個任務，Schema on write 的事件管理系統無疑更優。

Datadog（收購回來的 Logmatic）就是基於 Elastic 的架構的事件管理系統。目前所有搶佔市場份額的 Log management 都是基於 Elastic 的而不是 Splunk。那麼 Datadog 是如何解決或者減緩數據 ingest（攝取數據）過程中的前端資源消耗問題的呢？Ingest 的成本與性能平衡是所有 Log Management 軟件需要完成的任務。後文介紹 Datadog Log Management 產品的部分會講到。

Traces 和 Metrics 是 Log 的兩條正交軸上的抽象化預處理和編碼的信息，分別是請求（Request）相關信息 Traces 和系統相關信息 Metrics。

Metric

Metric 是測量一段時間內數據的量化表示。Metric 可以利用數學模型和預測來獲取對系統在過去或未來一段時間內的行為的掌握。

對比 log，metric 的間接消耗資源是相對恆定的。用户數據增加並不會增加 metric 成本。應用程序的流量增加並不會增加 Metric 所佔用的磁盤空間，處理複雜程度，可視化速度，和其他的相關成本。雖然 metric 存儲需求會應主機數增加，container 增加，services 增加而相應增加，但不受用户流量影響。Metric 的數字屬性讓其更容易用於數學，統計，概率用途：取樣，加和，概括，相關性分析等。這些特性讓 metric 更適合分析系統整體健康度。

Metric 也更加適合觸發警報：在本地內存時序數據庫中做一個查詢（query）的效率和效果遠高於在分佈式計算系統中做搜索。

Trace/Distributed tracing

不論是 log 還是 metric 都有一個大限制：他們均囿於系統。除了某個特定系統以外發生的事，log 和 metric 提供不了太多幫助。非特定系統的請求（request）相關 metric 就要被綁定一個獨特 ID，作為標籤。伴生的 metric 扇出增加了 metric 存儲量需求。UID 在數據庫中屬於高基數（high cardinality）即去重唯一值過多，如果作為標識（label/tag）付於 log 或 metric 之上會拖慢查詢速度以及拖累運算性能。傳統的 Observability/monitor 軟件依賴 UID 標識，壓垮時序數據庫。Datadog 等新一代的 observability 軟件着力攻克此問題。

Trace 是記錄在分佈式計算體系中穿行於不通系統之間的端到端的一系列互為因果的事件流程的表述。Trace 是 log 的表述，trace 的數據結構跟事件日誌很像。一條 trace 既能提供對一條請求的路徑可見性，也能顯示請求的結構。請求的路徑可以使軟件工程師理解請求路徑上的所有涉及的服務，而請求的結構則可以使我們瞭解每個接合點的異步性帶來的效果。

當請求開始時，就會分配一個獨特 ID，這個 ID 標籤將在 trace 的每一步繼續傳播並加入並不斷豐富的 metadata（元數據，描述數據的數據）。雖然 Tracing 也有 UID，但是存儲資源消耗卻遠遠不及 logging。因為 tracing 通常都會經過重度取樣，以減低運行消耗和數據存儲量需求。

然而 tracing 的限制在於不同系統和 IT 基礎設施之間有效實施，需要沒一個接合點都能傳播 trace。由於並非所有的系統或應用程序都在使用者或 IT 架構者的控制之內（尤其涉及遺留系統或者野生程序等，尤為艱難）。Tracing 往往在統一使用核心編程語言和架構的機構內最容易成功部署。

產品特性與行業競爭格局

在 Datadog 的招股書中將競爭者分成了四個來源：分別是 On-prem 的 IT 基建監測服務商，提供 APM 的服務商（Cisco（AppDynamics），New Relic，Dynatrace），Log 管理服務商（Splunk 和 Elastic）以及雲平台服務商（谷歌亞馬遜微軟等）。我們可以將第一類和第四類直接篩除，因為 On-prem 是雲原生趨勢下的萎縮市場，未來增量可以忽略，最後一類的雲平台服務商自帶的基建監測也可以篩掉因為他們主要針對自己雲基建上的數據和應用進行監測，雖然都有一定程度的外接能力，但支持格式不全面，且無法同時監測 on-prem。且這幾家的業務性質也不同，不算同體量競爭對手。

那麼我們只需要研究在 APM 領域和 Log 領域的這四個主要競爭對手即可。Splunk 和 New Relic 也不用看了，Splunk 解釋過，New Relic 就不解釋了。我們專注對比 APM 界的 Dynatrace 和 Log Management 界的 Elastic。

Datadog 的 APM+Log management 產品特性

雖然是兩個單獨的產品，APM 在 2017 年推出，而 LogManagement 在 2019 推出。但 Log Management 從第一天起就是以完善 Obervability 為使命。Datadog 的 APM 和 Log Management 使用的是統一的標註規則（tagging），提供 Log，metric 和 trace 之間的相關性。

首先看看 Datadog 的 log 攝取和索引化的方法論：

上文提到 Elastic 的數據搜索系統是當下最流行的數據庫搜索解決方案。其全棧（full stack）結構均為開源，基於 Lucene 開源程序庫開發，一般稱作 ELK 棧（其中包括負責數據聚合及處理功能的Logstash，提供存儲以及搜索功能的Elasticsearch，以及提供分析及可視化功能的Kibana）。也就是説基於數據攝取和索引化的底層技術來自 Elastic，但是免費。其實，在 ELK 全棧的前端還有對接攝取 log 數據之前的一個步驟，就是 log 數據的緩衝，在這個步驟上又有兩個占主導地位的開源技術：Redis 和 Kafka。理論上，企業 IT 部門可以不花一分錢使用這些開源全棧架構自行實現全鏈條監控服務。但是，要企業 IT 部門自行組建團隊來設計一套數據攝取到可視化分析的簡單易用的軟件超出了企業的能力和興趣範圍。企業 IT 人員（Dev+Ops+Sec）應該將時間花在獲取了有效信息（而非數據）之後與業務部門商討如何解決問題點併合作提高前端業務效率，而非搭建底層工具體系。這就是為什麼雖然雲時代的企業軟件基本都是基於開源系統全免費可得，但是仍然有高度依附於這些開源架構但可以收費的軟件公司。這與傳統軟件公司的閉源開發邏輯不同，值得投資者瞭解。

於是 Elastic NV 雖然旗下整個科技全棧 ELK 均是開源，但是公司自己也能基於此開發產品賣錢（Log Management 產品和 APM 產品，未來的 BI（商業分析）產品），因為 Kibana 的原始形態太難用了，一定要做足夠的定製化才能做到簡易使用。同理，這也是為什麼 Apache Kafka 是開源技術，但是 Confluent Kafka 卻能賣錢（$Confluent(CFLT.US) ）。

如果只提一點是 Observability 或廣義數據管理 SaaS 軟件需要做到的特性，那就是整合。能最有效地，儘可能多地整合最受歡迎的開源技術棧的軟件方案就是優秀的數據類軟件。在開源技術時代走在最前端的軟件技術公司的技術比拼是一場賽跑而不是一場城池攻防戰。進步速度與領先差距幅度遠比護城河重要。

上面兩圖圖一現實的是傳統 log management 遇到的取捨窘境：如果如左側方案，攝取所有 log 並且進行索引將會使成本不堪承受；如果如右側方案只篩選及索引化一部分 log 就會影響可見度。Datadog 的解決理念是將所有 Log 分成兩類，既能低成本地攝入所有的 log，又只索引部分有價值的 log：比如會被用作搜索，分析，警報，Dashboard 以及被用作 log/metric/trace 關聯性的這部分 log。

Log Management 產品的獨特優勢，使得 Datadog 在 2019 年後的收入增速大幅拋離競爭對手（體量都差不多）

上圖是 Datadog 過去三年 2 季度的 Log Management 的 ARR 增幅圖，由於管理層不單獨披露 Log Management 產品的收入或 ARR，因此該圖並沒有顯示金額數。這個收入增幅，包括 Datadog 的 APM 產品組合的 ARR 增幅都遠高於競爭對手 Dynatrace 和 Elastic。

三家公司財務與經營數字對比

ARR 我用的是季度收入 *4，由於 ARR 不是會計準則要求披露數字，公司一般有自己的一套算法，Elastic 用月度收入 *12，Dynatrace 用匯報期最後一天收入 *365；但是由於月和日收入沒人披露，所以我這兒就用了季度收入 *4，來作為超高增速公司的年化收入的 Run-rate。可見比較範圍的三家公司都是一個收入級別的公司，但是 Datadog 的增速（70%）顯著高於 Elastic（50%）又顯著高於 Dynatrace（30%）。

另外 DBNRR（或者 net retention rate 或者 net expansion rate）三家公司最新季度分別處於 Datadog 的 130%+，Elastic 的略低於 130%，以及 Dynatrace 的 120%+。其中 Datadog 和 Dynatrace 均是十幾個季度穩定於現水準。需要提到一點：對於數據監控類的軟件公司，或多或少都有按使用量定價的佔比，而非單純固定月費。所以即使同客户不流失，不增加新產品購買（比如以前只買 APM，現在加購 log management 等），也應該有一定的隨着數字化應用增加而帶來的收入增速。

因此公司 ARR 的驅動因素有三個：ARR 增速=new logo 增速 *DBNRR* 數據量自然增速。除了第三個驅動因素是行業因素之外（大概率健康快速增加）其他兩項都是公司的運營成果。

New logo 就是新客户。Datadog 和 Elastic 的總客户數在 15000~17000 家範圍。Dynatrace 只做大客户，即他們的所有客户從第一天開始 ARR 都大於 10 萬美元，客户數在 3100+ 家。而 Datadog 和 Elastic 的策略都是 Land-and-expand 的銷售策略，但只有 10 萬美元的客户才能算做有效客户（Datadog 的 10 萬 + 客户貢獻收入佔比超過 80%），因此他們兩家都披露 10 萬 + 的客户數。

由上面兩圖可見，Dynatrace 由於其銷售策略只專注於 10 萬 + 的大客户，所以其總客户增速就是新客户數的增速。可見顯著的增速放緩，在 6 個季度間從一個 3 位數的增長下降至 15%。也就是説現在 Dynatrace 中 30% 左右的 ARR 增速其中 15% 來自客户數增加，而 20% 來自 DBNRR 的增加。

Datadog 和 Elastic 方面，由於大小客户均有，首先將 ARR 拆成 DBNRR 和 new logo，再加上大客户增速如上表。我們可以發現 Datadog 的 ARR 增速接近大客户數的增速，而 Elastic 的 ARR 增速卻和大客户數增速相去甚遠。這在某程度上反映新增客户的變現速度較慢。

行業 TAM 與未來新市場潛力

Gartner 對 Observability 的行業規模預測是在 2025 年達到超過 500 億美元。2021 年也有 380 億美元。目前 Datadog 和 Dynatrace 兩家在 Observability 做得最好的公司 ARR 加起來也沒有 20 億美元，成長空間仍然巨大。

未來 Observability 最自然地延展方向是網絡安全和商業智能分析。網絡安全是個一百多億美元的市場，而 BI 也是一個一百多億的市場。

我們再看看文章開頭的那副圖，這是公司 2019 年 IPO 時候的 ppt，上面只有 5 個產品，分別是：基礎設施監測，APM，Log Management，網絡性能監控，用户體驗監測。時至今日，已經有幾十個最大的客户在使用 Datadog 的 7 個產品。

這是 Datadog 現在的產品系列（中間列），其中用户體驗監控產品增加了 Synthetics（模擬請求），增加了網絡安全產品，增加了 continuous profiler（方便分析在程序持續發佈和持續集成 CI/CD 過程中給的低效率代碼，從開發端（而非生產端）解決運行性能瓶頸，找出耗時耗資源的部分，提升 MTTR（平均修復時間），提升用户體驗，節省雲服務開支等）。短短兩年間 Datadog 不僅發佈了多項新產品，這些產品還快速佔據了市場。

定價策略

這張圖是跟上文講到 Log management 的圖很像。Datadog 幫助客户攝取所有數據，即左邊箭頭，這部分的按量計價是不提供價值（但佔用資源）的，Datadog 降低每單位數據的價格，讓這部分定價低於傳統 Observability 軟件競爭對手。另一部分右邊的箭頭是客户認為有價值的數據分析功能。這部分則由用户決定哪些要使用，保留，保留時間。這部分因為對客户的價值遠高於定價，則可以標較高的單位數據價格。

獲客成本

上面兩圖是 Datadog 對比競爭對手的獲客成本。圖一可見以新增大客户數來做分母，增加同樣數量的$10 萬 + 客户，Datadog 付出營銷費用成本最低。（定義：上個季度營銷費用/新增 10 萬 + 客户數）

圖二則是公司使用的營銷費用回本時間（CAC Payback，這個指標好於客户數指標，因為營銷工作不僅限於發展 new logo）。定義為：上個季度營銷費用/季度環比淨增毛利。可見 Datadog 取得同樣的毛利增量，只需要 7 個月就能做到營銷費用回本。而 Dynatrace 需要 17 個月，而 Elastic 也需要 21 個月。Datadog 的營銷效率在相似體量的發展階段冠絕同業且差距巨大。

研發取向

最後我們來看看各家公司對研發投入的力度。Datadog 是在研發投入方面最進取的公司。最新季度的研發開支佔當季收入百分比達到 42%，Elastic 只有 31% 而 Dynatrace 更只有 17%。如果用 TTM 過去 12 個月的研發開支對比銷售收入，Datadog 數字超過 30%，也同樣遠高於同業。

綜上，Datadog 在各項數字，包括收入增速，新客户獲取，現有客户擴張，營銷效率，研發投入等均無一例外遠遠拋離競爭對手。在 Observability 業界沒有接近的對手。

估值比較

2022 年底三家公司的華爾街一致預期收入為 Datadog14.1 億，Elastic（2023 年 1 月底）9.7 億，Dynatrace10.8 億。EV/收入倍數分別為（11 月 26 日收盤價）：39.7 倍，14.2 倍，16.7 倍。

*****

補充一張 IPO 時公司提供的 Cohort 分析圖

上圖左側單位是美元百萬。請留意上圖青色，紫色，綠色甚至是藍色的 2012-2015 年加入的客户羣他們的額外購買力極弱（2014 年的客户羣在 2018 年底總共只有不到 2000 萬美元的收入），也就説明他們購買的早期產品並不具備與 Datadog 近年來提供的新產品具備協同性。也説明公司近五年贏得的新企業客户的支付能力更強，交差銷售潛力更大。公司並沒有在近期更新這張 Cohort 分析圖。

但是公司的 ARR 已經從這張圖右側的 2.4 億美元上升至上個季度末的 10.8 億美元。而這 3 年 350% 的 ARR 增量可以合理推斷賴相對較新的 Cohort 羣體。

（完）