Hello World – 大数据实践之路

随着近两年大数据技术的蓬勃发展，很多新的发展趋势、研究热点层出不穷。因为这个专题主要是基于Hadoop生态组件的生产线实践，所以谈几个关于Hadoop生态以及大数据发展趋势的个人观点。

1. 以hadoop组件为核心的大数据生态目前仍然是大多数公司构建传统数仓的选择。细说的话，可以分三个层面来讲。

• 国内一二线互联网公司大多数都基于社区hadoop生态维护有内部分支。比如腾讯、美团、快手、京东、网易、滴滴等等，集群规模都在几千上万台，甚至十几万台。字节内部也是基于hadoop分支，不过据说使用C++重构了HDFS。阿里是个例外，数仓都跑在云上，可能有EMR、MaxCompute以及ADB。
• 国内大多数稍具规模的传统行业以及中型互联网公司很多都基于CDH、HDP、FusionInsight HD等发行版Hadoop组件，通常来说集群规模在几十台到几百台之间。还有很多公司基于硬件成本以及运维成本的考虑，会将运维复杂、风险较大的HDFS替换成云对象存储服务，比如阿里OSS、华为OBS等。在和很多业界小伙伴聊天发现，会有很多公司会将热数据放到HDFS，历史数据归档到对象存储服务。随着近几年数据中台架构的出现以及落地，很多大数据基础软件提供商开始给传统行业公司进行数据中台建设，目前来看这些新增的数据中台建设大多数都是基于私有化的hadoop底座。
• 初创公司考虑到数据规模、运维成本、机器成本等因素一般不会自己搭建运维hadoop集群。这种情况通常两种选择，一种是自己搭一套简单的GreenPlum、ClickHouse就基本可以满足需求，另一种就是直接使用各种云上提供的EMR服务等。

另外再啰嗦一句，目前数仓建设依然是大多数公司在做的事情，而不是其他。

2. 传统离线数仓构建所需的各种技术相对而言发展已经比较成熟。但随着近几年大数据业务的不断普及，数据规模越来越大，使用大数据的业务场景越来越多，数据使用者以及管理者在数据实时性、查询高效、降低成本等方面有了更多要求。于是相应地出现了如下几个研究热点：

• 实时数仓与流批一体。实时数仓是这两年大家落地比较多的方向，主要解决之前实时计算任务混乱不成体系的问题。实时数仓出现之后就要考虑和原有离线数仓的融合，不融合就会出现两套数仓运维成本高、离线\实时指标口径不一致等各种问题，于是出现了基于iceberg/hudi等技术的存储层批流一体技术方案，试图将实时、离线数仓从存储层面进行融合。当然，现在很多公司使用iceberg\hudi是想着能将数据库中的数据准实时地导入数仓系统进行分析。目前流批一体整体还处于初级阶段，各家公司都还处于调研以及小范围业务试用阶段。
• 高效OLAP引擎。数仓构建好之后最重要的任务就是如何让数据使用者稳定高效地完成自助分析、自助取数、报表分析。OLAP引擎的高效与否、稳定与否直接决定着数据使用者的直观体验，所以大数据管理者对OLAP引擎的选择都非常关注，这个也是当前国内很多创新公司角逐的领域，比如StarRocks、Doris、Presto、ClickHouse、Impala等。
• 云原生数仓。云原生数仓一方面通过计算存储分离直接提升计算\存储资源利用率，按需扩展，降低使用成本；另一方面通过端到端全链路打通各个环节，开箱即用，不需要用户调优、设计就可以获得极致的功能体验和高效地性能体验。从技术的层面讲，因为使用了对象存储，叠加计算存储分离，性能上可能并不会体现太大优势，其他诸如CBO优化、索引优化、向量化这些技术都比较成熟，应该也体现不出来特别大的差异。所以云原生数仓更多地赢在易用、低成本、高扩展上，性能也许并不是最大的优势。目前云原生数仓在国外已经比较流行，但在国内可能还需要很长一段路，这里面不仅仅是技术的问题。
• 数据湖与湖仓一体。数据湖这个概念在国内有点乱，这里引用我们杭研院院长的定义：数据湖是一个存储各类结构化、半结构化甚至非结构化原始数据，提供标准接口支持各类数据源和分析工具，成本超低的存储系统。所以S3、OSS这类对象存储看起来更像是数据湖，它们100%满足上面的定义，反倒是HDFS因为成本问题可能更多的用于数据仓库场景。数据湖兴起之后湖仓一体的概念就出现了，数据湖存储的更多是原始数据，在上面既可以建设数据仓库，也可以建设机器学习平台，也可以建设物联网平台。湖仓一体更多地体现在于底层存储基于类S3对象存储，基于此进行高效数据仓库建设。目前数据仓库比较成熟，不过基于数据湖的分析场景还没有那么成熟丰富，所以湖仓一体现在还是聚焦于数据仓库这个方向，但是LakeHouse这个理念慢慢大家都已经开始在思考，有不少创业公司已经聚焦于这块。

介绍完大数据”天下大势”之后，还是回到这个主题来，这节主要说说”大数据实践之路”这个专题主要写些什么内容。经过一段时间的梳理，笔者将整个专题分成三个大的模块，分别是大数据组件异常诊断、大数据组件优化以及离线任务诊断。

1. 大数据组件异常诊断：记录部分Hadoop生态核心组件（HDFS/YARN/HIVE/HBASE等）在生产线运维过程中遇到的真实问题案例、分析排查过程以及解决方案。这些组件可以认为是当前Hadoop大数据平台的基座，一旦出现服务异常，必然会导致上层大数据平台长时间不可用，甚至造成严重的生产线事故。比起一旦HDFS出现长时间卡顿的话，所有上层离线任务、实时任务都会出现延迟甚至失败。再比如HBase集群中一个RegionServer发生宕机的话，依赖HBase的在线服务就会出现异常。笔者就亲历过一次因为HDFS组件存在的功能风险导致上层用户误删部分数据仓库数据的事故，最终导致业务花费了大半年时间修复相关数据。

2. 大数据组件优化：记录部分Hadoop生态核心组件（HDFS/YARN/HIVE/HBASE等）在生产线上的功能、性能优化实践案例。原生社区组件在集群规模比较小的情况下工作都是比较顺畅的，但是一旦集群规模上去之后，就需要结合社区的演进进行功能或者性能的优化，这个优化可能是合并社区的一些Patch，或者是直接升级到社区高版本，或者是参数调优，或者是业务使用方式调整，或者是架构调整，或者是自研部分功能。所有这些优化的目标是支撑集群规模可以做的更大，访问的请求量可以更大，存储的数据规模可以做的更大，任务的执行效率更高。在这个专题中，所有这些优化手段都会有相应的案例和大家进行交流。

3. 离线任务诊断：记录Spark任务/Hive任务执行过程中比较典型的一些真实问题案例，有可能是任务失败案例，也有可能是任务执行慢案例。离线任务执行过程是蛮复杂的，它的复杂性一方面体现在整个执行过程中会与多个组件进行交互，比如申请资源会与YARN交互，上传jar包/读写文件/移动文件会与HDFS交互，driver分布式提交会与Metastore交互，所以这些组件的稳定性对离线任务的正常执行影响就比较大。另一方面体现在执行引擎结合数据源的处理上比较复杂，比如数据是否有倾斜、用户设置的内存大小是否合适，shuffle数据量是否很大等等。