共计 8103 个字符，预计需要花费 21 分钟才能阅读完成。
导语 | 近几年煊赫一时的云原生首先由 Matt Stine 提出并连续应用至今，但其并没有规范的、严格的定义，比拟公认的四因素是：DevOps、微服务、继续交付、以及容器，更多的则是偏差利用零碎的一种体系架构和方法论。那么在云上如何改良大数据基础架构让其合乎云原生规范，同时给企业客户带来真真切切的数据分析老本升高和性能保障是一个开放性的话题。本文由腾讯专家工程师、腾讯云 EMR 技术负责人陈龙在 Techo TVP 开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」的《云原生环境下大数据根底技术演进》演讲分享整顿而成，与大家分享和探讨在云上如何实现存储计算云原生，以及将来下一代云原生大数据基础架构。
点击可观看精彩演讲视频
一、云原生规范和大数据根底技术
明天分享的内容分为四个局部：第一局部是云原生规范和大数据根底技术；第二局部是大数据根底技术如何实现云原生；第三局部是腾讯云大数据云原生解决方案；第四局部是下一代云原生大数据根底技术。
接下来看云原生规范和大数据根底技术，以及什么才是云原生的大数据根底技术。
1. 云原生的核心思想
“云原生”这个词，这几年十分炽热，对于这个词，堪称仁者见仁，智者见智。一个产品如果不加上“云原生”，如同就落后于这个时代，那么云原生讲的到底是什么？它所鼓吹的核心思想又是什么？咱们首先来看定义，云原生首先是由马特·斯泰恩提出并延用至今，比拟公认的蕴含四个因素，第一个是 DevOps，第二个是微服务，第三个是继续交付，第四个是容器化。
DevOps 实际上就是开发和运维的综合体，不像开发和产品常常兵戎相见，DevOps 实际上是麻利思维，是一种沟通文化，也是一种组织模式，为云原生提供继续交付能力。继续交付是不误时开发，不停机更新，小步快跑，反传统瀑布模型开发，这就要求开发版本和稳固版本并存，继续交付须要很多工具或者流程来反对。
再来看微服务，简直所有的云原生都蕴含微服务这个定义。跟微服务绝对应的是单体利用，微服务有实践根底——康威定律，领导如何拆这个服务。然而但凡能称为定律的货色，文字看起来都很简略，可能真正把握其精华或者对其了解透彻是十分艰难的，有时候微服务拆不好的话，反而是一种劫难。一个微服务到底拆得好不好，实际上受限于架构师对于这个业务场景的了解和宏观形象的能力。
而容器化是指采纳开源技术栈，个别是指 K8S 和 Docker 进行容器化，基于微服务架构来进步整个零碎的灵活性和扩展性，借助麻利办法、DevOps 反对继续迭代，基于云基础设施实现弹性伸缩、动静调度、优化整个资源利用率。
因而把这四个因素加以宏观演绎，其实云原生讲的就是两个词：老本和效率，即在开发整个软件的时候实现工业化生产。
2. 大数据的云原生定义
联合方才的探讨，云原生讲的内容就是让源码在变成一个产品的过程中要充分利用云计算软件交付模型，来构建和运行应用程序，从而实现整个软件生产的工业化，进而实现降本增效。
依照这个原理怎么推导出大数据的云原生？“大数据”也是目前比拟炽热的一个词，我集体了解大数据其实是对超大规模数据集的剖析解决技术。对于大数据，比拟官网的定义有两种：第一种，麦肯锡认为：指数据的规模超过了惯例的数据库工具获取、治理、存储和剖析的数据汇合，然而同时也强调并不是超过特定规模的数据才算是大数据。第二种，国内 IDC 数据公司则认为大数据有四个特色：数据规模大；数据流转快；类型多；价值密度低。
能够看到无论哪种定义，大数据的基本特征就是规模十分大，惯例的管理手段很难解决它，这就意味着要更为简单的分布式系统、并行计算等能力解决，简单也意味着成本上升和效率降落。
因而，联合方才的剖析，我感觉大数据云原生就是要充分利用云基础设施来解决超大规模数据集的获取、治理、存储和剖析问题，并在这个过程中实现老本升高和效率晋升，从而实现数据驱动商业。
3. 如何实现大数据云原生
在明确大数据根底云原生指标之后，咱们来看要通过什么伎俩或措施来实现大数据云原生。
数据驱动企业的商业倒退，数据作为企业最重要的资产之一，由企业的零碎产生，而企业的零碎多种多样，比方 CRM 零碎、IOT 设施、OA 零碎、HR 零碎等，这些零碎产生的数据在宏观上又能够分为结构化和非结构化数据，这些数据通过剖析和转换之后变成企业运行的各类指标，企业决策者就依据这些指标来调整整个企业的经营方向。联合方才的剖析，要在这个过程中实现云原生解决这些问题，咱们须要的一些规定和措施是什么？我感觉有四点：
第一是工业化交付，什么叫工业化交付？就是在现阶段很难实现繁多零碎解决掉所有的数据问题，那么须要一个生态级的零碎去解决数据问题，交付工业化是指当我须要某一个零碎的时候能够分钟级去创立这些零碎，并提供管控和运维能力。
第二是老本量化，老本量化分为两个维度，一是存储老本量化，二是计算成本量化。是指解决数据的零碎所应用的存储资源或者是计算资源可能有量化的能力。
第三是负载自适应，是指剖析解决这些数据的零碎所应用的资源规模应该随着数据规模的变动而变动。
第四是面向数据，对于企业来讲，数据是企业最重要的资产之一，而不是解决数据的这些零碎或者技术自身。假如我是一个做物流公司的，我买一架飞机是让整个物流效率晋升，而不是这个飞机的制作技术，所以面向数据应该是充分利用云平台根底能力，去解决数据分析问题，让企业更加聚焦于发现数据之间的关系、开掘数据的价值，进而更好地实现数据驱动。
基于这些准则和措施，咱们再联合一些落地的技术，看看如何实现大数据云原生。
在现阶段所有的大数据根底剖析都是围绕 Hadoop 生态技术构建，咱们以数据流来看这个问题。零碎产生的日志数据或者 ERP 产生的数据又或者 IOT 等其它产生的数据，个别会进入音讯管道，之后依照场景可能分为流场景或者批场景，别离有流解决引擎和批处理引擎，解决实现之后进入数据服务层，进入后，数据生产终端再通过 OLAP 引擎或者其它数据服务存储组件来生产这些数据。要实现大数据云原生来解决这些问题，即在整个解决零碎上对于每一个子模块或者零碎实现工业化交付，在整个生态解决链路上的每一个子模块或者零碎，它所应用的存储资源或者是计算资源可能做到老本量化。它占用的资源应该随着整个数据处理的负载变动而变动，通过这一系列的伎俩来实现面向数据，接下来咱们看每一个准则如何具体实现。
二、大数据根底零碎云原生实现
在现阶段，其实 Hadoop 生态的技术栈曾经成为大数据根底解决的事实标准，要实现云原生解决大数据根底问题，也就是要联合云基础设施和 Hadoop 生态技术栈实现工业化交付、老本量化、负载自适应和面向数据，基于 Hadoop 生态实现工业化交付不仅仅是指集群的创立，应该还包含管控、运维、数据 API 等。在惯例状况下可能不会频繁地创立集群，然而数据在云上的时候，我的数据可能在云存储，在须要的时候分钟级拉起一个集群去计算，计算实现后去开释这个集群，这时工业化交付就变得相当重要，即便你是一个常驻集群，对日常集群的管控和运维也是工业化交付的一部分，那么老本量化是指整个 Hadoop 集群所应用的存储资源或者计算资源在云上可能有透视的能力。第三个是负载自适应，是指整个 Hadoop 生态系统组件所应用的 IaaS 层规模应该随着解决数据量的变动而变动，尽量减少人工干预。
通过综上三条措施，最初让企业看见的是数据流动，而非零碎自身，最终实现面向数据。
接下来咱们看一下交付工业化如何实现。交付工业化就是要充分利用云基础设施一键化构建云上的数据分析系统，并同时提供管控、工作、查问或者治理的一些 API 能力，通过这些 API 能力大幅升高应用整个大数据分析的技术老本和运维老本，在现阶段数据处理须要一个生态级的解决方案，能够依据数据规模或者业务场景抉择一键化构建云上通过 Hadoop 服务、流计算服务、实时数仓服务或者数据湖服务，基于不同的解决方案，能够通过 API 来提交工作。举个例子，通过 API 来提交一个 Spark 工作，在 Spark 实现计算之后，我间接开释这个集群，或者是通过 API 间接提交，或者通过咱们的数据湖服务，依照扫描的数据量进行付费。通过这种工业化交付能力能够大幅升高整个大数据分析的资源老本。
要实现大数据分析老本量化，就必须基于现有的 Hadoop 架构进行改良，对于一个惯例的 Hadoop 集群而言，它的拓扑构造分为分布式协调节点，次要部署 zookeeper、journalNode 这种过程，主节点次要部署 Namenode、ResourceManager，计算节点次要部署 DataNode、Nodemanager 过程，然而现实情况是计算资源和存储资源并不对等，有时候计算是瓶颈，有时候存储是瓶颈，特地是在基于云存储的状况下。这时候只须要保留较少的存储节点用于存储、计算的两头长期后果以及日志等，基于老本量化准则，咱们把一个 Hadoop 集群的拓扑进行了改良，分为 Master、router、core 和 task，Master 是类比之前传统模式下的 Master 节点，次要部署 Namenode、ResourceManager。Router 节点能够用来部署一些无状态的服务，比方 HiveServer2 这种类型的过程，同时还能够利用云上的基础设施来简化整个大数据分析畛域里的高可用问题。举个例子：presto 的 coordinator 问题，能够将 presto 的 coordinator 部署在 router 上，通过云的负载平衡来实现容灾，在故障的时候主动切换。Core 节点相似于传统模式下的计算节点，外面部署 DataNode、Nodemanager，在云上的时候能够只用选取很少的 core 节点。Task 节点是弹性节点，它外面只会部署计算过程，基于这种架构能够实现四类大数据根底剖析服务。
第一种是传统模式，传统模式下能够齐全保留 IDC 整个集群下的架构，整个集群不存在弹性节点，通过云上 EMR 提供的疏导程序和集群程序，能够大幅升高应用整个 Hadoop 集群的运维问题，同时云上 EMR 还针对云存储做了大量内核层面的优化，在整个集群存储量不够的时候疾速转移数据到云存储，同时基于云上海量的计算资源能够疾速扩容集群。
第二种模式是计算存储拆散模式，在这种模式下整个数据在云存储，须要计算的时候，能够分钟级拉起一个上千节点的集群进行计算，算完之后开释掉集群，或者说维持集群在较小的规模，须要的时候分钟级扩容到较大的规模。
第三种是混合云计划，在 IDC 集群还没有迁徙到云上的时候，能够通过 VPN 或者专线将 IDC 环境和云环境买通，买通后在云上构建 EMR 集群，通过 EMR 集群辨认 IDC 集群文件系统和元数据形式，疾速扩大 IDC 自建集群的算力，在计算实现之后开释云上 EMR 集群。
第四种形式是混合计算，当初容器集群 TKE 或者 STKE 这种集群里部署的次要是以业务零碎为主，这类零碎有一个特点，它白天的时候负载很高，夜晚的时候负载很低，我的 EMR 有这种能力，在容器集群负载很低的时候能够疾速把容器集群的资源退出到 EMR 集群。
通过这四种计算形式灵便的应用云上存储资源和计算资源，从而大幅升高大数据分析的硬件老本，腾讯云也提供了这种能力。
这就是咱们的数据湖解决方案，咱们实现了依照扫描数据量进行付费的计算优化，剖析零碎比方 BI 或者一些可视化的数据管理工具以及应用程序，它能够通过 JDBC 或者 ODBC 的形式连贯到咱们的服务。在服务层咱们提供对立的认证和受权，同时在查问的时候能够设置每一个 SQL 所应用的资源状况，在这个解决方案中 DLF 治理云上所有的元数据，同时它还负责数据的入库服务，提交的 SQL 会交由 DLC 去执行，能够依据 DLC 数据的资源账单来进行付费。
再看负载自适应，基于 Hadoop 集群如何实现负载自适应。右侧下面这张图是某集群实在的负载图，惯例状况下，集群规模的大小应该是工夫线×峰值的矩形面积，利用云上海量的计算资源实现负载自适应，让整个集群规模的大小随着负载的变动而变动。目前 EMR 反对两种模式的伸缩，第一个是依照负载伸缩，第二个是依照工夫伸缩，依照负载伸缩的模式，能够依据资源调度组件 YARN 上 vocre 和 vmem 阻塞状况实现主动扩容或者缩容；依照时间段的模式，让理论使用者能够依据本人的业务状况，在顶峰时段扩容，在低峰时段缩容。
咱们在实现负载自适应的时候，还要保障整个业务的 SLA，也就是在缩容的时候要做到对业务无感知，要管制利用失败率。假如有一个流式场景，一旦 AM 节点调配在了弹性节点，那么在缩容这个弹性节点的时候肯定会导致流式工作的失败。同理，对于 YARN 里失败次数超过 2 次的 Container，下一次调配在弹性节点上时，如果再下线这个弹性节点，同样会导致这个利用的失败，所以咱们做负载自适应的时候在内核层面做了大量的优化，来躲避这种状况。理解老本量化、负载自适应之后，咱们接下来看如何实现面向数据。
我以一个数据 1 转换到数据 2 来阐明面向数据的问题。在数据处理畛域咱们能够将问题形象为如何高效地将一个数据集无效转化为另外一个数据集，随着这个数据规模越来越大，应用的工具或者技术也会越来越简单，在 GB 的时候咱们可能须要数据库或者一些其余单机零碎就能够实现，在 TB 的时候可能须要 MPP 或者并行计算能力实现，当回升到 PB 的时候可能须要分布式存储以及分布式计算能力实现，随着零碎越来越简单，数据问题就缓缓演变成技术问题、资源问题和运维问题。还是举方才那个例子，假如我做物流，当我的物流就在一个区域内的时候，我可能须要一个三轮车就能够解决问题，当我的业务倒退到跨城域的时候，可能须要汽车，倒退到跨省或者跨国内的时候，我可能须要飞机或者火车，然而在数据处理畛域现实情况是很多企业为了解决这些数据问题，不得不去解决解决这些数据问题的火车和飞机，从而偏离了数据作为企业最重要资产之一的指标。整个社会生产力进化的方向肯定是分工更加细化，因而我了解的面向数据是要充分利用云基础设施去解决数据分析问题，那么咱们接下来看面向数据如何落地。
还是以理论的数据处理流为例，比方利用零碎输入数据到数据库或是日志，这些数据库或者日志外面的数据通过数据同步工具会进入到云存储或者音讯管道。增量的数据，比方 CDC 外面的数据，它会进入音讯管道或者进入流批处理引擎，解决实现之后，会进入实时数仓或者云存储。在这张图里每一根线是解决这个数据自动化的生产线，每一个节点相当于是解决这个数据的引擎，对于企业和开发者来说，云上提供的每一个引擎之间无缝对接，对于企业来讲只须要关注整个数据流动自身即可，而不须要去关注数据处理技术自身。在解决了面向数据的同时，还必须要保障整个大数据分析的高性能，咱们接下来看腾讯云大数据分析根底性能这一层是如何保障的。
为了保障云上大数据处理的性能，腾讯云大数据提供从基础设施硬件层到组件内核以及到架构的多方面优化，如果你抉择的是传统模式来构建大数据利用，云主机提供了多种多样的硬件供选择。举个例子，比方一个 NoSQL HBase 利用，对 RT 要求在毫秒以内，那么你能够应用 IT 系列的集群来构建集群。在这里我重点介绍计算存储拆散场景下的性能保障，在传统模式下，计算过程和存储过程是部署在一起的，特地是在离线计算的场景下，为什么要这么做？起因是计算程序的体积远远小于数据的体积，所以当初支流的像 YARN 这种调度器在调度的时候都会充分考虑数据的亲和性，它在做计算工作切片和调度的时候会思考整个计算工作的数据分布状况，并把这些计算任务调度到数据所在的节点，在这些节点上构建计算程序并执行，以取得良好的性能；然而在计算存储拆散这种场景下，状况刚好反过来，整个数据在云存储，数据量特地大的时候会有肯定的性能损耗，因而咱们引入了 CacheService，同时革新了内核，做到对计算引擎通明，下层整个利用无需感知到 CacheService 的存在，同时咱们能够依据数据的元数据信息，比方表或者分区的访问信息，智能地从云存储里加载数据到 CacheService 里，以晋升性能。接下来咱们看腾讯云大数据云原生解决方案。
三、腾讯云大数据根底云原生解决方案
腾讯云大数据在大数据处理根底的各个环节，都提供了欠缺的产品能力反对。在存量数据导入方面，能够间接通过对象存储提供的工具，让数据导入到对象存储，增量数据的解决能够通过流计算的 CDC 能力，也能够间接写入 kafka，或者通过 EMR 集群外面的 sqoop 或者 Spark 导入到集群。数据进入云上后，依照流批两种场景，在批处理场景咱们提供了 EMR 或者 DLC 进行解决，流解决场景则提供了全托管的服务 Oceanus。同时在数据服务层，咱们提供了搜寻解决方案 ES、实时数仓 GP 和 ClickHouse，EMR 也提供了基于 Hadoop 全生态的服务层组件，能够满足数据服务层的一些需要，同时这些产品提供了欠缺的监控、API、决策权限以及 SDK，能够大幅简化大数据分析的代价，以此实现大数据畛域外面常见的点查、adhoc、olap 或者 Nosql 等利用。
在大数据处理畛域，计算引擎次要分批流两种，批以 Spark 为主，流以 Flink 为主，目前也有交融的趋势，各有各的生态，谁能胜出还不肯定。而为了解决简单的数据服务层问题，目前也呈现了 delta 相干的数据湖技术以及一些闭源的我的项目来尝试对立数据服务层。接下来是我对数据服务层的一些思考。
无论数据服务层怎么变，商业上必须要实现以最低老本和高性能实现数据分析。举个例子，现阶段在以 Hive 来构建数仓的状况下，更新某个分区表上面一小部分数据的时候，要进行大量的有效计算，进而节约大量的 IO 和 CPU 资源，导致老本居高不下。当初 Hadoop 生态畛域没有一个组件可能解决掉所有的数据问题，随着场景越来越简单，引入的组件会越来越多，这会导致数据大量冗余，进而造成老本升高。同时对于一个分布式系统而言，数据结构、算法和数据分区是保障高性能的前提，但当初每个计算引擎都有上百个参数，而且还不蕴含 JVM 或者是操作系统内核自身的参数。把这些参数裸露给开发者或是使用者，对于使用者来说是相当迷茫的。从另外一个层面来说，对于一个单节点的性能，其实是机器硬件能力的衍生，在现阶段状况下你写的代码是否可能真正把这个机器正当的硬件施展到极致，要打一个很大的问号，因而我感觉下一代大数据根底解决引擎有可能是这样的：
受限于硬件体系结构限度，当初单核 CPU 的频率曾经到下限，针对单机扩大它的性能，肯定是 numa 架构的多 CPU 模式，而在这种模式下，代码执行只有跨了 numanode，性能就会呈现成倍的抖动。在分布式场景下，数据跨节点之间的 Shuffle 是不可避免的，当初 Linux 内核对大量的数据包进行封包和解包，也会节约大量贵重的 CPU 资源，同时在编程模型上很难有编程框架可能做到对单个函数调用扩充资源限度，即便是 cgroup 也只能做到过程或者线程级，同样对于 io 也很难做到针对每个 io 设置 quote。特地是在存储层面，可能须要依据存储数据的重要水平以及老本，提供不同的存储老本。在数据组织层，须要提供对立的 DataFormat，然而当初 Hadoop 生态里有各种各样的数据格式。因而我感觉下一代计算引擎有可能是这样：首先在接入层，基于 SQL 提供对立的认证，同时还能够基于 SQL 设置这个 SQL 执行的资源组。在计算调度层，依据 SQL 设置的资源组准确管制每个算子的资源开销，以及每个算子的 IO 根本单位，这个算子在底层理论执行的时候，通过编程框架来保障每次函数执行都不会呈现跨 Node 的状况，同时在持续做 shuffle 的时候能够通过 RDMA 或者 DPDK 技术来进一步晋升性能，从而简化整个数据服务层架构并取得良好的性能。
讲师简介
陈龙
腾讯云专家工程师
腾讯云 EMR 技术负责人，专家工程师，2011 年退出腾讯，先后主导开发了腾讯云 Redis，负责腾讯云云数据库 HBase 以及 EMR 等多款云产品的技术工作，Apache Hbase Contributor，向 Apache Hive 等多个开源我的项目奉献过代码，目前专一于腾讯云 EMR 技术建设工作。