“我们不能用创造时的相同思路来解决问题” ——爱因斯坦
Datadog 两年前在纳斯达克上市，集资 7．45 亿美元，上市时市值 78 亿美元。首日大涨 40％，两年后的今天市值涨了 6．2 倍。
此前写了不少关于 SaaS 的股票和行业，其中写网安的行业研究得到了读者的广泛欢迎，近期写了一篇新股 Gitlab 的也得到了较高的关注度。
Datadog 是一家多业务的数据及应用监控公司，与我之前写的 SaaS 多少都有关联，都是乘着企业数字化转型和云端迁徙的东风成长起来的公司。Datadog 与多个大型 SaaS 公司在细分领域均有竞争关系，与几个 IaaS 平台公司也有竞争关系，通过了解 Datadog 的产品与财务情况，我们可以更深入地了解行业与云计算。
一
什么是 Datadog
Datadog 就是一个为云端软件基础设施提供全维度监测的服务。提供对基础设施全栈 （full stack） 性能的实时可见性（visibility）。上至最顶端的应用程序，到中间的 Kubernetes／Docker／Hypervisor，到操作系统，以及中间的数据库，第三方服务等全栈的性能监测。
1）应用程序监测的历史背景
任何一家传统跨国大型企业都在运行着一些传统的，高度定制化的企业级信息系统软件。公司内部有成千上万的员工用户同时使用这些系统。这些内部用户当在运行程序遇到问题时就会发出请求帮助的 Ticket（即请求 IT 部门协助的系统内部消息，填写故障描述等），在收到这些 tickets 之前 IT 部门不会知道出了故障。可见如果没有一种工具为企业 IT 部门提供监测（最好是实时监测）从发现问题开始的每一步都会延误故障排查和解决的效率。如果这些故障与前端销售相关，则每一分每一秒都会影响公司的收入。
在 Datadog 或其竞品出现之前，企业是如何监测 IT 系统的呢？每一个技术 Stack 的同事及其团队拥有一个自己的工具包来监测自己辖下的信息系统：数据库团队有一个自己的工具，Windows 团队有一个自己的工具，网络团队有一个自己的工具，一个企业 IT 部门合共有十几个监测工具。而这十几个性能监测工具互不相连。当故障出现之后，相关的几个团队需要互发邮件将问题拼拼图，拼出全貌，期间充满延误与挫折感。
上一篇 SaaS 专栏（Gitlab IPO）中讲到当代的企业软件和网略应用的迭代非常频繁，微服务，Container，Kubernetes，分布式计算等潮流推动了高速频繁及碎片化的应用程序更新。如果每推出一些新的功能改善都等候人工测试或用户故障汇报，效率过低。有了实时监控系统后，企业可以自行使用软件机器人等技术模拟测试任何新老应用的运行环境，配合实时监控系统，可以大大减少宕机时间和资源成本。
另一个例子，当疫情席卷世界后，许多跨国企业不同程度开始远距离办公，上万员工同时在世界各地通过不同的设备接入公司网络或云端系统。一个统一的监测面板（dashboard）可以一目了然的监测到每一个个体员工的设备接入速率，带宽情况，接入个别系统（微软 Azure 或 Office 365）是否出现过度网络延迟，哪些国家哪些地区的员工正在经历数据包丢失，甚至可以指向当地的互联网服务商（ISP），提醒 ISP 并尽快恢复网络到正常水平。
2）当代的技术潮流让传统 IT 架构不堪重负
Containers， microservices， serverless……等等技术潮流带动了企业信息系统云转型。这些技术令企业 IT 环境高度动态及短暂化（ephemeral），对比 on－prem 传统体系的静态化。SaaS 平台和开源工具为企业 IT 开发人员提供了爆发式增长且既强大又敏捷的技术支持。对比以往的大型软件供应商，开源的软件开发潮流使得所需计算资源指数级增长。应用程序的更新从以往几个月到几年缩短至以天以分钟计。以往的传统 IT 系统性能监控软件无法适应并提供当代计算所需求的实时可见性与洞见（insight）。
Datadog 试图做到的是将企业原本的十几个到最多几十个互相割裂的 IT 监测系统整合成一个，既提高监控效率，又降低企业的 IT 支出。
二
Datadog 的技术核心
Datadog 的技术核心处在上图这个流程表中绿色的这一部分（我认为了解这个行业需要了解数据库技术的历史以及背景知识，内容比较干燥，没有兴趣的额可以直接跳到产品特性及竞争格局）
1）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和新派的 Elastic。两者的最大区别就是对于 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。
1）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 却能卖钱。
如果只提一点是 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 倍。
风险提示：此文出于传递更多信息之目的，文章内容仅供参考，不构成投资建议。
