从技术视角看大数据行业的发展趋势

Posted 2021-09-03 michaelli916

前言

大家好，我是明哥！

正所谓 “抬头看天，低头走路”，大数据从业者既要脚踏实地立足当前技术栈做出高效易用的大数据产品，又要仰望星空顺应大数据的发展趋势，做出有技术前瞻性能适应未来变化的大数据产品。

明哥前期发布了一篇名为 “从历年 Gartner hype cycle 看大数据行业的发展历史和趋势” 的博文，在那篇博文中，明哥梳理了下历年 Gartner hype cycle 中关于大数据的部分，并据此总结了大数据行业的发展历史和趋势，该篇博文可以算是从面到点从上到下的视角推论的大数据的发展趋势。该博文链接如下：

从历年 Gartner hype cycle 看大数据行业的发展历史和趋势

在这篇博文中，明哥将依托自己十四年 IT 从业经验和六年大数据行业从业经验的经历，从自身的感触和技术的视角，总结下大数据行业的发展趋势，可以算是以从点到面从下到上的视角，对上文的一个呼应。

需要声明下，明哥自身能力有限经历有限，所以这里总结的行业趋势仅仅是管中窥豹，远远达不到大而全，话说回来，能让大家看后有所悟有所感，明哥就觉得可以了。

以下是正文。

趋势一：大数据和云计算进一步深度融合，大数据拥抱云计算走向云原生化

关于该趋势，明哥在前期发布过一篇博文，“大数据与云计算深度融合的趋势体现在哪些方面?” 对该趋势做了自己的解读，这里再次简要描述下。该博文链接如下:

大数据与云计算深度融合的趋势体现在哪些方面?

云原生（Cloud Native）理念，本质上是一套“利用云计算技术为用户降本增效”的最佳实践与方法论。大数据拥抱云计算走向云原生化，体现在一下四个方面：

• 一是应用方的大数据平台主动上云：使用大数据技术的业务应用建设方，不再自建数据中心，而是将大数据平台搬到了云上，有的是在云厂商的 IaaS 层上自建大数据平台（现在以这种方式在云上使用大数据的案例已经比较少了），有的直接使用云厂商提供的 PaaS 层大数据相关产品（aws 的 emr，阿里云的 e-MapReduce等），有的甚至直接使用云厂商推出的 SaaS层大数据相关产品（aws的redshift, 阿里云的maxcompute等），而且在上云的过程中，大家都很重视混合云和多云部署，避免 vendor-lockin；

• 二是云计算厂商在不断推出云上托管的各种基于大数据服务，以吸引更多业务方上云：各大云厂商为了提高自己的市场竞争力，从而进一步巩固和拓宽自己的市场地位，都在积极推出各种托管的大数据相关产品，有 s3/oss, emr/e-mapreduce，有 aws redshift, 有阿里云 maxcompute，还有各种云上数据库，云上 serverless 形态的各种大数据服务等等，该名单还在不断增长中。

• 三是各传统大数据厂商已经转向依托云来提供自己的产品和服务，如 elastic 很早就开始基于云交付自己的elk 技术栈了，如 spark 背后的商业公司 databricks 的大数据平台和产品一直都是基于云来向客户提供服务的（可以对接aws, gcp, azure等云平台），如 cloudera 不断探索改变自己的商业模式（从大数据三驾马车的辉煌期，到业绩下滑下的和 hortorworks的合并，再到主动改变商业模式基于云来交付自己的产品和服务，甚至数据中心版的大数据平台都改名为了 cdp private cloud base)，如 kafka 背后的商业公司 Confluent 也在基于云推广自己的 Confluent Platform.

confluent platform and confluent cloud

• 四是各个具体的大数据组件都在主动改变自身架构，积极向云原生靠拢以“云化”：从理念层面讲，大数据已经从最早的强调“数据本地性”和“移动数据不如移动计算”的理念，演进到了现在的强调“存储计算分离”的理念。各个新推出的组件和框架主动拥抱云原生，如 pulsa，TiDB 等都是依托于存储计算分离的云原生架构; 各个传统的组件虽然有历史包袱，也在不断求新求变，如 flink/spark 都深度整合支持了 kubernetes 集群模式；如 kafka也在不断探索如花云化：包括完全去掉zookeeper依赖，包括 Rebalance Protocol 的 Static Membership 等；正如古语所言，“顺则昌不顺则亡”，一些不适应云原生架构的技术组件，其市场正在不断萎缩，如很多场景下，kubernetes 都替代了yarn, 对象存储 oss/s3 等也在替代 hdfs （我们也注意到了apache 社区推出的 Ozone，该组件在对象存储的基础上，也融合推出了文件系统api，该组件的背后有很多原 hdfs 社区的 committer在贡献代码，在 cloudera 的 cdp 平台中也内嵌支持了该组件）。下图展示了 flink/spark跟 kubernetes 的深度整合：（注意不是简单的使用 k8s operator 将 spark/flink 作业运行在 k8s 集群中，而是 native 的深度的整合）

• 大数据云与计算的深度融合是大势所趋，其主要体现在以上四个方面，需要强调的是，这四个方面是相辅相成，互相促进的。

  • 如应用方的大数据平台上云的需求，促使了云计算厂商推出更好的托管的大数据增值服务；

  • 而云计算厂商推出的更多更好的大数据增值服务，也反过来促使了更多的应用方大数据平台上云；

  • 如基础设施上云的大趋势，促使了具体的大数据组件调整自身架构从而云化（因为顺则昌不顺则亡）；

  • 而大数据具体组件云原生化的架构调整，也反过来促使了云计算厂商和大数据厂商能够基于云基础设施推出更多更好的大数据服务。

趋势二：大数据与数据库日益融合的趋势

• 大数据与数据库日益融合的趋势，首先体现在大数据与数据库的边界本身就比较模糊：

  • 如具有大数据基因的各种 NoSql 数据库 MongoDB, es, Hbase 等也是数据库生态的一部分；

  • 如 greenPlum, Vertica 等 mpp 数据库本身就是大数据生态的一部分；

  • 如新型 NewSql 数据库 TiDB, CockroachDB, OceanBase 更是横跨数据库生态与大数据生态。

• 大数据与数据库日益融合的趋势，也体现在大数据组件本身在技术上借用和参考了很多传统数据库的理念和技术，使得大数据组件越来越像存储与计算分离的数据库：

  • 如各种大数据处理引擎都提供了对 sql 语法的支持：hive/spark/flink/presto sql；

  • 如各种大数据处理引擎本身在对 sql 的解析和优化上经常使用的框架 calcite/antlr4 在实现细节上就参考了数据库的实现；

  • 如大数据参考数据库对元数据的管理，抽象出了 catalog 的概念，各大数据处理引擎如 spark/flink 都有自己的各种 catalog 的实现；

  • 如大数据处理引擎参考数据库实现了对事务 acid 特性的支持，参考数据库的 mvcc 机制实现了对并发读写和多版本控制的支持，具体的有 hive acid事务表，还有数据湖框架 delta lake/hudi/iceberg等。

• 大数据与数据库日益融合的趋势，还体现在数据库也在不断演变以适应大数据场景：数据库从技术架构上来讲，经历了从早期的关系型数据库 sql，到大数据初生时代的各种 Nosql，再到现在的各种 NewSql, 也经历了从单机到读写分离再到集群化部署的趋势；

最后有必要说明下，由于大数据和数据库日益融合，依托数据库的传统数据仓库 Data Warehouse 和依托大数据的数据湖 Data Lake，二者之间的界限也越来越模糊并日益融合了，有的厂商还特地引进了新的术语来描述这种新型架构并得到了业界更广泛的认可和支持，该术语就是业界常说的湖仓一体的概念，即 Lake House。

趋势三：大数据更加青睐存储计算分离的架构

存储与计算是对物理资源不同纬度的需求，存储和计算分离的架构更加灵活，方便对存储和计算独立进行扩缩容，成本更优更具性价比。

• 大数据更加青睐存储计算分离的架构，体现在大数据生态更加丰富，由不同的框架解决不同的问题：计算层面有 spark/flink/presto， 存储层面有 hdfs/ozone/s3，数据管理层面有元数据管理的 hive catalog, 文件格式有 orc/parquet, 表格式 table format 有 hudi/iceberg/delta lake, 资源管理有 yarn/mesos/k8s等等；

• 大数据更加青睐存储计算分离的架构，也体现在一些传统的存储引擎也在进一步细化架构，支持存储与计算分离：如 NewSQL 数据库 TidB,在底层分为计算层 TiDB/TiSpark,存储层 TiKV/TiFlash,元数据层 PD; 如云原生消息系统 pulsa，在底层分为计算层 broker 和存储层 bookkeeper; 如 hdfs 的进化版 Ozone在底层支持对象存储；如消息系统 Kafka 也通过 tiered storage 支持本地存储和远端云端对象存储；

infinite storage with confluent cloud

大数据更加青睐存储计算分离的架构，还体现在大数据集群整体在架构上也更灵活更适应存储与计算分离，比如星环的大数据平台 tdh 底层的 tos 云操作系统是基于k8s和docker的；再比如 Cloudear 的大数据平台 dcp 的公有云版 cdp public cloud 和私有云版 cdp private cloud，两者都是集群模式+容器模式，存储依赖集群模式中的集群，而计算依赖容器模式中的容器，存储有计算解耦可以独自进行扩缩容。（私有云版在底层分为 cdp private cloud base 和 cdp private cloud plus，其中base是集群模式，和原来 cdh/hdp 的架构相同；plus是容器模式，底层依托 openShift （底层是k8s）实现跨云多云环境中的容器管理；）!

趋势四：大数据更加青睐对象存储

大数据为了进一步适应云原生化的大方向，在存储上相比文件系统，更加青睐对象存储。

对象存储在性能上比不上文件系统，尤其是对文件和目录的重命名 rename 操作上，以及对目录的 list 操作上，（对象存储没有目录树的概念，所谓的目录是抽象出来的；很多云厂商会限制对目录的 list 操作的次数），但是对象存储相比文件系统，在成本和扩展性上更有优势，所以云厂商更青睐对象存储。

当然了，大数据为适应对象存储，自身在架构和技术上也在不断演进，比如大数据的数据仓库框架 hive 在扩展性上受到不少诟病，而其扩展性问题的一个原因，就是在对元数据的管理上只做到了目录粒度而不是文件粒度，即 hive 在管理表和分区的元数据时，只记录了表和分区对应的目录，至于该目录底层有哪些文件，是在计算时通过 list 扫描得到的，由于在对象存储系统中 list 是比较昂贵的操作，所以在对接对象存储时，hive 这样处理显然是不合适的。事实上，更适应云原生和对象存储的框架如 Iceberg/Delta lake等，在元数据中都做到了文件的粒度而不是目录的粒度。

关于文件系统和对象存储的详细对比，有兴趣的小伙伴可以自行 google,明哥在这里不再赘述。

趋势五：大数据和机器学习/人工智能日益融合

大数据和机器学习/人工智能日益融合的趋势，体现在大数据需要AI上，也体现在AI需要大数据上。

• 一方面，大数据需要AI:

  • 大数据的元数据管理需要AI: 当企业面对数据量大且种类繁多的数据资产时（大数据的 5V 包括 volume 和 variety），如何有效管理和使用这些数据以挖掘更大商业价值，就尤其需要数据治理和元数据管理了。元数据的范畴和概念在扩大化，元数据不再仅仅是数据管理人员事先提供的静态的元数据，还包括利用机器学习可推导得出的动态发现的元数据。Gartner 推崇 Data Fabric 数据经纬的概念, 该概念尤其强调元数据管理和增强型数据管理，即主动利用机器学习驱动的元数据，快速提供来自于不同数据源的数据并自动化数据管理。这其中会更多地用到图计算和知识图谱，“Graphs form the foundation of data fabrics and knowledge graphs“，来帮助我们发现数据之间潜在的关联关系。

  • 大数据将我们从从BI时代带到了AI时代, 对数据的分析也不再是BI时代简单的统计分析和提供各种报表，而是AI时代更强调的综合使用各种算法做 Augmented analytics 提供 data story等商业洞察；

  • 在物联网的各种边缘设备 edge 上也更加提倡通过边缘计算内嵌各种 ML 和 AI 模型，将基于AI的计算推到更靠近数据产生的地方，以提供更高的数据时效性，以减少数据传输，以挖掘更多应用场景等等。

• 另一方面，AI 也需要大数据：从事人工智能相关工作的小伙伴们，都知道 AI 有个三要素的概念，即：数据，算法，算力，其中数据的质量和数量，决定了模型好坏的上限；而好的算法和足够的算力，可以推动模型的效果更逼近这个上限。

  • 三要素中的数据作为 AI 的原材料，跟大数据有着密不可分的关系，正是大数系统提供了AI的数据原材料。在现阶段，算法同学一般是从大数据系统中提取出来数据，存放在本地文件系统中，再进行模型的训练；不过已经有一些大数据框架，着手于利用大数据系统中的数据直接进行模型训练和模型部署与应用了，比如 spark mllib, koalas, flink ml；我们也看到，alluxio client 通过 fuse api 接口以本地文件的形式，直接提供大数据平台中的数据给算法模型进行训练，起到了数据桥梁的作用，减少了中间数据导出的繁琐过程。

  • 三要素中的算力，也可以依赖大数据的集群资源管理框架来提供，比如 yarn 在对 cpu 和 mem 资源管理的基础上，已经扩展支持了对 gpu 资源的管理；

  • 三要素中的算法，在很多大数据框架也直接提供了对常见算法的实现，比如 spark mllib, flink ml等。

趋势六：大数据日益重视数据安全与数据治理

明哥觉得，现阶段数据安全问题日益凸显，有以下几方面的原因：

• 一方面企业本身仍然面临着传统的各种内外部数据威胁，这点没啥新意，我们就不再赘述；

• 另一方面，国家出台了各种政策和法规需要遵守没有重视数据合规性的企业会面临政府的天价罚单，（我们看到前段时间滴滴上市前临门一脚被叫停，就是处于数据安全）。

• 还有一点，就是在云环境下，安全问题更加凸显。以往大数据都是在数据中心的内网运行，面临的威胁少暴露出来的也不多；而当前随着大数据上云的趋势，大量云计算厂商推出了自己云上托管的大数据服务，云上应用案列越来越多，遭受的攻击尝试也越来越多，相应的被发现和暴露出来的安全漏洞问题也就越来越多。

在应对数据安全问题上，传统的3A 即 authentication, authorization 和 audit 的概念仍然适用，encryption 加密算法也仍然使用，具体使的支撑框架常见的有 Kerberos, ldap, knox, ranger 和 sentry 等。

在数据治理上，前文提到，当企业面对数据量大且种类繁多的数据资产时（大数据的 5V 包括 volume 和 variety），如何有效管理和使用这些数据以挖掘更大商业价值，就尤其需要数据治理和元数据管理了。此时元数据的范畴和概念有扩大化的趋势，元数据不再仅仅是数据管理人员事先提供的静态的元数据，还包括利用机器学习可推导得出的动态发现的元数据。

在数据治理上，Gartner 推崇 Data Fabric 数据经纬的概念, 该概念尤其强调元数据管理和增强型数据管理，即主动利用机器学习驱动的元数据，快速提供来自于不同数据源的数据并自动化数据管理。这其中会更多地用到图计算和知识图谱，“Graphs form the foundation of data fabrics and knowledge graphs“，来帮助我们发现数据之间潜在的关联关系。

数据治理的一些相关概念，包括元数据，主数据，数据血缘等，支撑框架包括 atlas,ranger 等。

趋势七：大数据日益重视数据的时效性

大数据强调数据有热度，数据价值具有时效性且随着时间的推移价值会递减，这是大家的共识，也是实时计算和准实时计算日益受到业界重视的原因，笔者没有太多补充，不过我想指出一点，即实时计算究竟需要做到什么级别的实时，是在业务需求，现有技术能力，和运维复杂性之间的妥协，并不是一定总是要追求毫秒微妙级别的实时，很多时候秒级别分钟级别甚至小时级别的延时，也是可以接受的。

业界这块相关的概念有流批一体，仔细分析又包括存储引擎层面的流批一体，计算框架层面的流批一体，以及业务代码层面的流批一体。

在存储引擎层面，离线批量处理场景一般使用文件系统结合数据库；实时准实时流处理场景一般使用消息队列结合数据库。不过随着数据湖仓概念的崛起，尤其是伴随着 delta lake/hudi/iceberg 的崛起和 hive 实时化的进展，使用这些框架做流批一体的存储的案列将会越来越多（当然对应的场景是分钟级别的准实时的场景）；随着 kafka 支持tiered storage , 使用 kafka结合对象存储并配置合适的 retention period 做流批一体的存储的案例也会越来越多。

在计算框架层面，flink 和 spark 都支持流批一体，即同一个计算框架即支持用户的流处理应用程序，也支持用户的批处理应用程序。

在业务代码层面的流批一体上，即同一套业务代码，不做任何代码层面的改动，仅仅通过配置不同的参数，就能提交做为流处理或批处理应用程序运行，目前看来似乎 FLINK SQL 走得最远做得最好。

欢迎大家关注同名微信公众号，后台留言加群交流！