万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考

?云原生架构下,基于 Hadoop 技术栈搭建数据平台应该如何改造?

理想汽车大数据平台涉及的组件多, 在从 Hadoop 到云原生演进的过程中边探索,边实践,积累了不少一手经验;同时,他们率先在对象存储上使用 JuiceFS,实现平台级文件共享、跨平台使用海量数据等场景。

作者简介:
聂磊,理想汽车大数据架构师, 从事大数据工作 10 年;大数据架构工作 6 年;对主流大数据技术有深入的理解;目前主要在推进大数据云原生和湖仓一体技术方案在理想汽车的落地。

01

理想汽车在Hadoop时代的技术架构

首先简单回顾下大数据技术的发展,基于我个人的理解,将大数据的发展分了4个时期:
第一个时期:2006 年到 2008 年。2008 年左右,Hadoop 成为了 Apache 顶级项目,并正式发布了 1.0 版本,它的基础主要是基于谷歌的三驾马车,GFS、MapReduce、BigTable 去定义的。
第二个时期:2009 年到 2013 年阶段。雅虎、阿里、Facebook 等企业对大数据的应用越来越多。2013 年底 Hadoop 正式发布 2.0 版本。我有幸在 2012 年的时候开始接触大数据,用 Hadoop 1.0 加 Hive 的模式体验了下,当时感觉很神奇的,大数据用几台机器就可以快速解决原来用 SQL Server 或者 MySQL 解决不了的问题。
第三阶段:2014 年到 2019 年,这段时间发展的非常快,期间 Spark、Flink 都成为了 Apache 顶级项目。在这个快速爬升期的过程中,我们还尝试用过 Storm,后来 Storm 就被 Flink 所替代了。
第四阶段:从 2020 年至今,2020 年 Hudi 从 Apache 毕业成为顶级项目之后,我个人理解数据湖进入到整个发展的成熟期,到了大数据的数据湖 2.0 阶段。数据湖主要三个特点,首先是统一、开放式的存储,其次是开放式的格式,以及丰富的计算引擎。
万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
整体的发展过程中,大数据主要是有几个特点,就是大家常说的四个“V”:规模性(Volume)、高速性(Velocity)、多样性(Variety)、价值性(Value)。现在还有第五个“V”(Veracity),数据的准确性和可信赖度。数据的质量是一直被人诟病的,希望行业里能有一套标准把数据湖的质量去做提升,这个可能是数据湖 2.0 出现的标准,因为出现了 Hudi、Iceberg 这些项目,都是想把整个数据湖的管理做好。
个人觉得 Hadoop 是大数据的一个代名词,但是大数据并不只有 Hadoop。大数据是在发展过程中由多个组件整合之后形成的一套解决大量数据加工处理和使用的解决方案。这几年,大家基本上认为 Hadoop 是在走下坡路的,首先是 Hadoop 商业化公司 Cloudera 和 Hortonworks 的合并和退市,原来的商业模式无法延续;也面临着快速增长的云供应商在成本和易用性上的挑战,以及 Hadoop 本身生态系统的日益复杂。

理想汽车大数据平台当前架构

万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
在这个阶段,理想汽车的大数据平台如上图所示。理想汽车用了很多开源的组件。
  • • 传输层:Kafka 和 Pulsar 。平台构建初期整体都用的 Kafka,Kafka 的云原生能力比较差,Pulsar 在设计之初就是按照云原生架构设计的,并且有一些非常适合 IoT 场景的能力,和我们的业务场景也比较匹配,所以我们近期引进了 Pulsar;

  • • 存储层是 HDFS + JuiceFS;

  • • 计算层目前的主要的计算引擎是 Spark 、Hive 和 Flink,这些计算引都是跑在现在的 Yarn 上。三个计算引擎是通过 Apache Linkis 去管理的,Linkis 是微众银行开源的,目前我们对 Linkis 用的也是比较重的;

  • • 图片的右侧数据库,第一个 MatrixDB ,它是一个商业版的时序数据库,TiDB 主打做 OLTP 和 OLAP 的混合场景,目前我们主要用它来做 TP 的场景。StarRocks 负责 OLAP 的场景;

  • • ShardingSphere,是想要用它的 Database Plus 的概念去把底下的数据库统一的去做一个网关层的管理。目前还在探索阶段,有很多新增特性我们都很感兴趣;

  • • Thanos 是一个云原生的监控方案,我们已经将组件、引擎和机器的监控都整合到 Thanos 方案里;

  • • 应用层是四个主要的中台产品,包括数据应用、数据开发、数据集成和数据治理。

特点

大家通过大数据平台的现状可以发现一些特点:
  • • 第一,整个方案的组件是比较多的,用户对这些组件的依赖性强,且组件之间互相的依赖性也比较强。建议大家在未来组件选型的时候尽量选择云原生化比较成熟的组件;

  • • 第二,我们的数据是有明确的波峰波谷。出行场景一般都是早高峰晚高峰,周六周日人数会比较多;

  • • 第三个特点,我们数据的热度基本上都是最热的,一般只访问最近几天或者最近一周的数据。但是产生了大量的数据,有的时候可能需要大量回溯,因而数据也需要长久的保存,这样对数据的利用率就差了很多。最后,整个数据体系目前从文件层面看缺少一些有效的管理手段。从建设至今,基本上还是以 HDFS 为主,有大量的无用数据存在,造成了资源的浪费,这是我们亟待解决的问题。

大数据平台的痛点

  • • 第一,组件多,部署难度高、效率低。围绕 Hadoop 的大数据组件有 30 多个,常用的也有 10 几个之多。有些组件之间有强依赖和弱依赖,统一的配置和管理变得非常复杂。

  • • 第二,机器成本和维护成本比较高。为了业务的稳定运行,离线和实时集群进行了分开部署。但上面提到的业务特点,我们业务波峰波谷现象明显,整体利用率不高。集群组件繁多需要专门人员管理和维护。

  • • 第三,跨平台数据共享能力。目前跨集群共享数据只能通过 DistCp 方式同步到其他 Hadoop 集群。无法方便快捷的同步到其他平台和服务器上。

  • • 第四,数据的安全和隐私合规。基于不同的数据安全需求,普通用户通过 Ranger 进行管理,特殊安全需求只能通过构建不同集群并设置单独 VPC 策略的方式来满足,造成很多数据孤岛和维护成本。

02

理想汽车云原生的演进与思考

万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
首先,先简单分享一下我个人理解的云原生:
第一,云原生是在云计算的基础上衍生出来的。现在大家用的如阿里云、 AWS、腾讯云、百度云等云厂商,最开始提供的都是 IaaS 层的技术服务,帮企业把存储、计算、网络这些这些最基础的东西封装好统一管理,企业只需要在上面申请服务器就可以了。申请了服务器之后,这些服务器还是由云厂商来管理的,也就是大家传统的上云操作。
云原生离不开云计算,笼统地说,云原生属于云计算的 PaaS 层服务,主要是面向开发者的一类应用。云原生必须在云上安装,是一种基于云计算的软件开发应用方式。云+原生,云即云计算,原生则是摒弃传统的运维开发框架,通过容器化、DevOps,还有微服务架构实现应用弹性伸缩和自动化部署,充分利用云计算资源实现在最少的空间里做最大的事。也能解决我们目前大数据系统的一些痛点,比如扩展性和维护性都比较差,需要大量人力与时间等。
万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
上图简单列了一下云原生的几个时间点
  • • 第一个阶段, AWS 提出了云原生的概念,并且在 2006 年推出了 EC2,这个阶段是服务器阶段,上文提到的云计算阶段;

  • • 第二个阶段,云化阶段,主是在开源 Docker 发布和谷歌开源了 Kuberneters 之后。Kubernetes 是一个轻便的和可扩展的开源平台,用于管理容器化应用和服务。通过 Kubernetes 能够进行应用的自动化部署和扩缩容;

  • • 第三个阶段,2015 年的时候成立了 CNCF 基金会,在主推云原生概念,帮助云原生整体发展的更好。最后是 Knative 的开源,Knative 一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。衍生到现在,已经是云原生 2.0 阶段,即 Serverless 这个阶段。我个人理解大数据的发展应该也是朝着 Serverless 的方向去发展。比如现在 AWS 整个在线的服务基本上都做到了 Serverless。

大数据云原生架构

万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
接下来介绍一下理想汽车大数据平台在云原生化之后组件发生的变化:
  • • 存储层,云原生化之后所有的存储基本上都是对象存储了上面的架构图引出了 Lustre,下文会详细介绍。大家可以理解为「云存储」这一层主要是以 JuiceFS 来管理对象存储和 Lustre 并行分布式文件系统(注:由于 Lustre 的单副本问题,我们目前也在考虑使用云服务商提供的并行文件系统产品);

  • • 容器层,主要是在计算、存储、网络之上,全部都用 Kubernetes 加 Docker 来替代,所有的组件都是在这上面生长出来的;

  • • 组件部分,首先是大数据计算框架,我们可能会废弃掉 Hive,直接沿用 Spark 和 Flink,通过 Hudi 去做数据湖 2.0 的底层能力支撑并逐步替换HDFS;

  • • 中间件部分,除了 Pulsar 以外还有 Kafka,目前 Kafka 的云原生化做的并不是特别好,我个人更倾向于用 Pulsar 去替换 Kafka。目前线上已经使用Linkis适配了所有Spark引擎,后面会进行Flink的适配和整合。ShardingSphere 在 5.1.2 版本刚刚支持云原生,我们会按计划进行场景验证和能力探索;

  • • 数据库层,还是 TiDB、StarRocks、MatrixDB,目前这三个数据库已经有云原生的能力,它们都支持对象存储。但这一块还没有单独去测过,我们目前用的还都是物理机。因为对于数据库来说,当前对象存储提供的IO能力还无法满足数据库的性能要求,会使得数据库的整体性能大打折扣;

  • • 运维方面,由 Thanos 方案多加了一个 Loki,主要是做云原生的日志收集。但是 Loki 和 Thanos 只是其中两个,未来我理解应该会朝着阿里开源的SREWorks能力看齐,把整个的质量成本效率和安全全部都封在综合运维能力里边,这样就可以把整个的云原生管理起来;

  • • 可观测性,云原生领域最近比较热门的概念。现在大家做的组件,有一些是在有热度之后,才开始发展云原生的,它并不是一开始生在云上,它只是后面希望长在云上。这种情况下它会遇到一些问题,第一个问题,就是没有全面的可见性的监控。我们考虑后续如何把这些组件整体的出一个方案,在所有组件上到云原生后可以有效的监控。

总结一下,我个人觉得大数据未来的云原生基本上就是:
  1. 1. 统一使用云原生的存储作为所有组件(包括数据库)的底层存储;

  2. 2. 所有组件都运行在容器中;

  3. 3. 使用 Serverless 架构服务上层应用。

  4. 但是这样也给目前的数据平台产品带来挑战,就是如何设计具备 Serverless

    能力的产品来给用户使用。

大数据云原生的优势

第一点,存算分离,弹性伸缩。使用物理机部署 Hadoop 之后,如果需要扩容缩容还需要去联系运营商,并且可能会有很长的周期,存算分离很好地解决了这个问题。其次是按需付费,不用购买闲置资源,目前我们整个的业务场景的数据是有波峰波谷的,波峰的时候需要准备机器,波谷的时候需要撤机器,但现在是做不到的。现在我们基本上是把所有的机器都堆到波峰,波峰的时候能满足需求,稳定不失败,但它在波谷的时候最少 12 个小时左右是闲置的,这种情况下资源也是要付费的。云原生之后我们就可以不用再为此买单了。
第二点,自动化部署和可运维性。Kubernetes 是支持 DevOps 集成化的部署方案的。这样我们的组件整体可以实现快速的部署(比如通过 Helm chart),把组件运维的能力下沉到云原生平台上,这样大数据就不需要考虑组件运维场景了。
第三点,对象存储。对象存储是云计算推出的最核心最主要的产品。对象存储的好处不言而喻了,易扩展,存储空间无上下限,单价比较低,而且对象存储还分为低频存储、归档存储等多种存储类型,进一步降低存储成本,数据就可以存更长时间。同时成本可控,高可靠,操作复杂性低也都是对象存储的优势。
第四点,安全和合规性。云原生之后可以实现专用命名空间,多租户隔离,远程认证。目前我们做到的基本上都是网络层面上的隔离,HDFS的文件管理大家公认的方案是Ranger。通过 Ranger 去管理 HDFS 的目录权限,也能管理如 Hive server、HBase、Kafka 的一些权限,但是相对而言这些权限都会偏弱一些。
还有一个方案是 Kerberos,整个大数据组件的安全性会提高很多,但是它有很多的成本,它任何一个请求都要去验证。这个方案目前我们没有使用过,和我们的集群环境和场景有关系,我们基本上都是内网的,并不对外提供服务。如果大家做的大数据项目需要对外网提供一些服务,还是需要有强认证,不然数据很容易泄露。

大数据云原生的难点

大数据云原生的难点同样也是存在的。
第一,大数据相关的组件是比较多的,同时 Kubernetes 的更新比较快,组件和组件之间交叉之后,兼容性、复杂性和扩展性,都会存在问题。
第二,资源的分配和再分配。Kubernetes 是通用的容器资源调度工具,很难满足不同大数据组件的资源使用场景。大数据场景下资源使用会比较大,请求频率高,每次启动的 pod 的数又会比较多,这种情况下,目前没有什么好的方案。目前我们正在看 Fluid 这个方案,Fluid 也实现了 JuiceFS 的 runtime,这个也是我们后边要去深入调研的,Fluid 目前宣称是可以支持大数据和 AI 的,并不是只有 AI 的场景,因为大数据和 AI 的场景是比较像的,都是数据密集型的操作,Fluid 在计算效率和数据抽象管理方面是有了一些突破性的进展。
第三点,对象存储也是有一些劣势的。对象存储的劣势是元数据操作性能低、和大数据组件兼容性差、最终一致性等问题。
最后一点,就是数据密集型应用。存算分离模式无法满足大数据、AI 等数据密集型应用在计算运行效率、数据抽象管理方面的需求。

03

JuiceFS在云原生方案的探索和落地



在 JuiceFS 开源之前我们就已经关注并做了一些落地的测试,开源版上线之后,我们就马上上线使用了。上线的时候也遇到了一些权限的问题和几个小的 bug,社区非常给力,快速地帮我们都解决了。

万字长文 | 理想汽车从 Hadoop 到云原生的演进与思考
要下线 HDFS 是因为它的扩展性差,同时我们的数据量比较大,HDFS 的存储成本比较高。在存储了几批数据后,物理机的空间就不够了,而且需要的计算非常多。当时我们的业