现在很火的云原生到底是什么？

现在很火的云原生到底是什么？

提起云原生很多人都会想到 K8s，当然 K8s 目前已经是事实的云原生的基石。很多人直观的理解是把程序拆成一堆微服务，然后通过简单的 kubectl apply 一个 yaml，基本就是云原生了。其实抛开很多比较官方的定义来说，云原生基本的特征也基本上如此。

但是今天我们从一个大数据的云原生视角，看看云原生到底是什么，意味着什么，跟云又是个什么关系？

最开始云的概念被提出来主要是满足了如下几点需求：

1. 容易使用，拉来就能用，用完就能释放的计算资源

2. 容易扩展，能根据流量和业务负载动态的调整资源的使用规模

同时又在商业上能够成立：

1. 规模化的资源集中管理，能显著提高管理水平，水平高了就变成了护城河也能吸引更多的客户

2. 资源的超卖可以实现高额的利润

个人对腾讯云比较熟悉，拿腾讯云的 CDW 数仓举例，一般的公司做个数据分析，想要自己从头搭建一套 ClickHouse，那基本都要组件一个大数据部门，部门规模小了大概率做出一堆天天挂，又难用的东西，耽误了服务稳定性不说。数据搞错了，影响商业决策，那损失就难以估量了……

从另外一个角度考虑，大数据相关的工作负载和普通的线上业务有很大的不同，线上业务随着时间的变化使用的机器资源波动一般也就在 3~5 倍左右，说实话这种类型的业务从计算资源的性价比考虑，云的竞争优势并不是特别大。但大数据就不同了，我写一个 SQL 查询，自己搭建个分布式集群，集群有多大，基本性能也就有限的这么多。但如果你用的是云，你完全可以跑任务的时候把集群扩张到一个非常夸张的数字，跑完业务再缩回来。这时候你就把“云原生”的意义从 K8s+微服务升华成了“这波不亏”+“真香”。

以腾讯云大数据峰会的 PPT 里借用的 CDW 架构图为例，做过大数据系统搭建的同学肯定明白，一个大数据系统看上去功能很多，但基本每一个功能都是“干重活”的时候非常必要的功能。但我的经验是，选择云服务的时候，需要重点关注的其实是运维层面的功能。只有具备完善的“企业级运维”功能后，才可以实现榨干云原生的每一滴潜质，实现降本增效（反薅云一把羊毛）

云原生的 Power 还远不只是计算资源上。现在很多 OLAP 引擎都支持基于对象存储的运算模式，早些年我以为这里主要是出于成本的考量，毕竟几乎在所有云上对象存储的成本都至少是块存储的 1/4。

但后来一个偶然的事情让我发现了我还是太年轻。不知道大家注意到没有，几乎所有云的对象存储都只说自己的QPS，不说吞吐能力。有一次和一个做了 15 年存储系统的大牛闲聊得知，对象存储在云内部的实现系能瓶颈主要是元数据性能，云的对象存储都是会在 AZ 范围内进行数据打散，所以1 万个对象后面很可能为你服务的是1 千台服务器。基本上对象的 size 越大吞吐上限就越大，只要读取端网络带宽扛得住，这个吞吐量几乎可以认为是无上限。

我们知道大多数 OLAP 任务都是要对数据进行很大范围的读取，特别是聚合操作（Aggregation）。所以其实在对象存储上构建数据湖不仅仅是节省存储成本，更是能薅公有云对象存储吞吐性能好的羊毛。

说了这么多，总结一下，一个比较理想的云原生数据湖（Cloud Native Data Lake）应该有如下几个特质：

1. 计算层可方便自由伸缩

2. 存储层可以利用对象存储的廉价，近乎无限的吞吐能力

3. 有一个缓存层把元数据、热数据进行缓存，补充对象存储这方面的弱点

那么，你完全可以试试这个现成的：

在 10 年前的那个时代，也许企业信息化还可以从自己买服务器、上架、搭环境开始玩。但现在这个时代，对于一个想要专注做好自己业务的公司而言，云几乎是公认的 Best Practice。也是顺应这这个分工细化，专业深化的潮流，云原生也成了技术圈的大势所趋。

大数据领域是一个充满了需要踩无数坑才能“正常”运作的领域。技术方案的决定是需要慎之又慎，我见过太多技术决策者从「自信满满」到「更与何人说」。

激进的技术选择导致的不仅仅是人力、硬件成本的浪费，更可怕的是浪费宝贵的时间，导致机会成本的增加。本来 1 周能够上线的功能，最终花了 2 周才上线，谁知道你错过了什么呢？只有基于一个稳固的底座才能高效稳妥地构建出你自己的业务系统，才能避免在一些隐性的坑坑洼洼上浪费宝贵的时间。

当年的吃鸡大战，国内各个巨头都发现了吃鸡手游的巨大机会，但大家心理都明白，只有尽快的上线才能迅速的聚拢玩家，第二个开发出来的厂商只能接受成王败寇的命运。也是依托腾讯云强大的基础设施后盾，腾讯才在这场战争中取得了先手优势。不仅仅是游戏行业，就像腾讯云这种在各行各业积累了无数的案例的供应商肯定是能帮助我们绕过无数的技术大坑。