现实汽车在 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 阶段。数据湖次要三个特点，首先是对立、开放式的存储，其次是开放式的格局，以及丰盛的计算引擎。
整体的倒退过程中，大数据次要是有几个特点，就是大家常说的四个“V”：规模性（Volume）、高速性（Velocity）、多样性（Variety）、价值性（Value）。当初还有第五个“V”（Veracity），数据的准确性和可信赖度。数据的品质是始终被人诟病的，心愿行业里能有一套规范把数据湖的品质去做晋升，这个可能是数据湖 2.0 呈现的规范，因为呈现了 Hudi、Iceberg 这些我的项目，都是想把整个数据湖的治理做好。
集体感觉 Hadoop 是大数据的一个代名词，然而大数据并不只有 Hadoop。大数据是在倒退过程中由多个组件整合之后造成的一套解决大量数据加工解决和应用的解决方案。这几年，大家基本上认为 Hadoop 是在走下坡路的，首先是 Hadoop 商业化公司 Cloudera 和 Hortonworks 的合并和退市，原来的商业模式无奈连续；也面临着快速增长的云供应商在老本和易用性上的挑战，以及 Hadoop 自身生态系统的日益简单。
现实汽车大数据平台以后架构
在这个阶段，现实汽车的大数据平台如上图所示。现实汽车用了很多开源的组件。
- 传输层：Kafka 和 Pulsar。平台构建初期整体都用的 Kafka，Kafka 的云原生能力比拟差，Pulsar 在设计之初就是依照云原生架构设计的，并且有一些非常适合 IoT 场景的能力，和咱们的业务场景也比拟匹配，所以咱们近期引进了 Pulsar。
- 存储层是 HDFS + JuiceFS。
- 计算层目前的次要的计算引擎是 Spark 和 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 策略的形式来满足，造成很多数据孤岛和保护老本。
现实汽车云原生的演进与思考
首先，先简略分享一下我集体了解的云原生：
第一，云原生是在云计算的根底上衍生进去的。当初大家用的如阿里云、AWS、腾讯云、百度云等云厂商，最开始提供的都是 IaaS 层的技术服务，帮企业把存储、计算、网络这些这些最根底的货色封装好对立治理，企业只须要在下面申请服务器就能够了。申请了服务器之后，这些服务器还是由云厂商来治理的，也就是大家传统的上云操作。
云原生离不开云计算，抽象地说，云原生属于云计算的 PaaS 层服务，次要是面向开发者的一类利用。云原生必须在云上装置，是一种基于云计算的软件开发利用形式。云 + 原生，云即云计算，原生则是摒弃传统的运维开发框架，通过容器化、DevOps，还有微服务架构实现利用弹性伸缩和自动化部署，充分利用云计算资源实现在起码的空间里做最大的事。也能解决咱们目前大数据系统的一些痛点，比方扩展性和维护性都比拟差，须要大量人力与工夫等。
上图简略列了一下云原生的几个工夫点
- 第一个阶段，AWS 提出了云原生的概念，并且在 2006 年推出了 EC2，这个阶段是服务器阶段，上文提到的云计算阶段。
- 第二个阶段，云化阶段，主是在开源 Docker 公布和谷歌开源了 Kuberneters 之后。Kubernetes 是一个轻便的和可扩大的开源平台，用于治理容器化利用和服务。通过 Kubernetes 可能进行利用的自动化部署和扩缩容。
- 第三个阶段，2015 年的时候成立了 CNCF 基金会，在主推云原生概念，帮忙云原生整体倒退的更好。最初是 Knative 的开源，Knative 一个很重要的指标就是制订云原生、跨平台的 Serverless 编排规范。衍生到当初，曾经是云原生 2.0 阶段，即 Serverless 这个阶段。我集体了解大数据的倒退应该也是朝着 Serverless 的方向去倒退。比方当初 AWS 整个在线的服务基本上都做到了 Serverless。
大数据云原生架构
接下来介绍一下现实汽车大数据平台在云原生化之后组件产生的变动：
- 存储层，云原生化之后所有的存储基本上都是对象存储了。下面的架构图引出了 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 能力看齐，把整个的品质老本效率和平安全副都封在综合运维能力里边，这样就能够把整个的云原生治理起来。
- 可观测性，云原生畛域最近比拟热门的概念。当初大家做的组件，有一些是在有热度之后，才开始倒退云原生的，它并不是一开始生在云上，它只是前面心愿长在云上。这种状况下它会遇到一些问题，第一个问题，就是没有全面的可见性的监控。咱们思考后续如何把这些组件整体的出一个计划，在所有组件上到云原生后能够无效的监控。
总结一下，我集体感觉大数据将来的云原生基本上就是：
- 对立应用云原生的存储作为所有组件（包含数据库）的底层存储
- 所有组件都运行在容器中
- 应用 Serverless 架构服务下层利用
然而这样也给目前的数据平台产品带来挑战，就是如何设计具备 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 等数据密集型利用在计算运行效率、数据抽象治理方面的需要。
JuiceFS 在大数据云原生计划的摸索和落地
在 JuiceFS 开源之前咱们就曾经关注并做了一些落地的测试，开源版上线之后，咱们就马上上线应用了。上线的时候也遇到了一些权限的问题和几个小的 bug，社区十分给力，疾速地帮咱们都解决了。
要下线 HDFS 是因为它的扩展性差，同时咱们的数据量比拟大，HDFS 的存储老本比拟高。在存储了几批数据后，物理机的空间就不够了，而且须要的计算十分多。过后咱们的业务倒退还在初期，为了尽可能从数据中取得价值，咱们要保留尽可能多的数据。而且 HDFS 须要三正本，咱们起初改成两正本，然而两正本还是有危险的。
在这个根底上，咱们深度测试了 JuiceFS，测试实现之后，咱们很快就把 JuiceFS 引到咱们的线上环境。把一些比拟大的表从 HDFS 迁徙到 JuiceFS 里，缓解了咱们的当务之急。
咱们对 JuiceFS 比拟看重的三点：
- 第一，JuiceFS 是多协定兼容。齐全兼容 POSIX、HDFS 和 S3 协定，目前用下来都是百分百兼容的，没有遇到任何问题。
- 第二，跨云的能力。当企业有肯定规模之后，为了防止系统性危险，都不会只应用一个云服务商。不会绑在一个云上，都会是多云操作的。这种状况下，JuiceFS 的跨云数据同步的能力就起到了作用。
- 第三，云原生的场景。JuiceFS 反对 CSI，目前 CSI 这个场景咱们还没有用，咱们基本上都是用 POSIX 去挂载的，然而应用 CSI 的形式会更简略更兼容，咱们当初也正在往云原生下来倒退，但整个的组件还没有真正上到 Kubernetes。
JuiceFS 在现实汽车的利用
从 HDFS 将数据长久化到对象存储
JuiceFS 开源之后，咱们就开始尝试把 HDFS 上的数据同步到 JuiceFS。开始同步的时候是应用 DistCp，联合 JuiceFS 的 Hadoop SDK 同步十分不便，整体迁徙比较顺利。之所以要把数据从 HDFS 迁徙到 JuiceFS 上，是因为遇到了一些问题。
第一就是 HDFS 的存算耦合设计扩展性差，这个是没有方法解决的。我集体从一开始接触大数据的认知就是大数据是必须要部署在物理机上的，而不是在云主机。包含起初云厂商推出的各类 EMR 零碎，其实是在对 Hadoop 进行封装，最近一两年这些 EMR 零碎都在逐步去 Hadoop 化。
第二是 HDFS 难以适配云原生化。当初的 HDFS 很难适配云原生，因为它比拟重，尽管社区始终在着重发力去做云原生，然而我集体认为 Hadoop 的发展趋势在走下坡路，将来应该以对象存储为主。
第三，对象存储也有一些弊病，它不能很好的适配 HDFS API，因为网络等起因性能跟本地盘比也相差很多，另外 list 目录等元数据操作也很慢。咱们通过 JuiceFS 做一些减速，测下来性能十分可观，在有缓存的状况下基本上能够媲美本地盘，基于此咱们疾速地将以后的场景间接切换到 JuiceFS 上。
平台级别的文件共享
第二个场景平台级别的文件共享。咱们目前的整个调度零碎、实时零碎、开发平台的共享文件的数据全部都是存在 HDFS 上的，后续如果要是停止使用 HDFS，须要把这些数据迁徙走。目前的计划是用 JuiceFS 对接对象存储，通过应用层的服务，全副以 POSIX 的形式挂载下来，大家就能够无感地去申请 JuiceFS 里的文件。
JuiceFS 在这个场景满足了咱们大部分的利用需要，但还有些小场景存在问题。最后的构想是会把 Python 环境之类的都放进去，起初发现实操难度太大，因为 Python 环境里边有大量的小文件，加载的时候还是会有问题。相似 Python 环境这种蕴含大量碎文件的场景还是须要存储在本地盘来操作。后续咱们筹备挂一块块存储，专门来做这件事。
分享几个咱们之前应用 HDFS 遇到的问题：
第一个，当 NameNode 压力大或 Full GC 时会有下载失败的状况，目前临时没有一个完满的计划解决。咱们的计划是尽量加内存，或者在下载包的时候加一些重试，避一避它的高峰期，然而这种状况下很难齐全解决 HDFS 的问题，因为它究竟是 Java 写的，GC 的场景是没有方法防止的。
第二个，在跨零碎外面去应用 HDFS 的时候，比方咱们有两个集群，当初要用一个集群去共享文件，基本上是不事实的，因为须要开明网络，来把两个集群之间买通或者利用上买通，这样安全性是没有方法保障的。目前咱们基本上就是两个集群是独立各自保护本人的共享文件。当初实时平台（如 Flink 平台）曾经切换到 JuiceFS 上了，目前还是十分顺利，没有遇到什么问题。
第三个，目前咱们有大量的物理机部署，物理机部署都是单集群的，没有容灾的策略，如果哪天机房出了一些灾难性的问题，咱们整个服务就不可用了。然而对象存储它自身是跨机房，是同一个 region 外面，应该都是有起码三个正本，云厂商帮咱们做到了备份。后续，咱们可能会倒退多云，心愿通过 JuiceFS 去共享一些高级别的文件、外围的数据库，包含一些外围的备份文件，在多云外面去做备份。这样就实现了多云、多 region、多地区，就能够解决当初单点容灾的问题。
海量数据跨平台应用
另外一个场景，平台和平台之间全部都是通过 JuiceFS 去共享海量数据。咱们这边的共享的数据中第一类是路试车的数据，路试车会有大量的视频语音图像数据上传，这些数据上传了之后会间接进到 JuiceFS 里，不便上游去做一些同步和共享，包含一些数据的筛查，再拿到 PFS 就是并行文件系统，其上面挂载的是 SSD。这样能够让 GPU 利用率更高一些，因为对象存储的能力是绝对比拟弱的，不然 GPU 的能力就会有大量节约。
剩下的数据类型包含车辆上报的一些用于剖析的日志，埋点数据，还有一些国家平台须要的车辆相干的信号数据，这些数据都会进到数仓外面去做一些剖析。也会对这些数据做一些特色数据提取，给算法团队去做模型训练，或者做一些 NLP 的检索和其余的更多场景。
云原生存储减速 – Lustre 作为读缓存（测试中）
当初咱们正在测的是另外一个场景是在对象存储层挂一个 Lustre 去给 JuiceFS 去做读缓存，通过 Lustre 的缓存来帮忙 JuiceFS 来进步读取速度和缓存命中率。
这样能够有一个益处是咱们当初用的都是物理机，它是有物理盘的，物理盘能够用来缓存数据。然而因为计算工作在多个节点执行，缓存的命中率不太高。这是因为社区版 JuiceFS 目前还不反对 P2P 的分布式缓存，只反对单节点的本地缓存，每一个节点可能会读很多数据。这种状况下也给计算节点造成了一些磁盘的压力，因为缓存会占用肯定的磁盘空间。
目前咱们的计划是通过 Lustre 来作为 JuiceFS 的读缓存。具体来说是依据须要缓存的数据大小，将一个容量大略是 20~30TB 的 Lustre 文件系统挂载到计算节点本地，而后将这个 Lustre 挂载点作为 JuiceFS 的缓存目录。这种状况下 JuiceFS 读完数据之后，能够异步缓存到 Lustre 里。这个计划能够无效解决缓存命中率不高的问题，大幅度提高读取性能。
如果咱们在 Spark 场景往对象存储里间接写数据的时候，会有带宽和 QPS 的限度，如果写入得太慢，上游的工作可能会产生抖动，在这种状况下能够通过 JuiceFS 的写缓存性能把数据先写到 Lustre 里，再异步写到对象存储，这个计划在某些场景下是实用的。然而有一个问题是 Lustre 并不是一个云原生的计划，它对于用户来说是有感知的，用户在启动 pod 的时候须要显式写一个命令把它挂载下来。因而前面咱们也心愿对 JuiceFS 做一些革新，主动去辨认对象存储和 Lustre，而后主动实现一些缓存的机制，这样就不须要用户来感知 Lustre 的存在。
目前这个计划的 PoC 曾经实现，通过了根底测试，接下来咱们会在生产环境做大量的压测，预计往年 Q3 应该能够正式上线笼罩一些边缘业务。
JuiceFS 在大数据云原生的整体计划
从整体计划的架构图能够看到，目前 JuiceFS 客户端提供的三种形式咱们都有用到。
如上图左半局部所示，咱们会有独立的 Spark、Flink 集群，咱们通过 CSI Driver 的形式将 JuiceFS 间接挂载到整个集群上，这样用户启动 Spark 和 Flink 的时候，就齐全感知不到 JuiceFS 到存在了，计算工作的读写都是通过对象存储来实现。
这部分目前有一个无关 shuffle 的问题。因为 Spark 工作在计算过程中的 shuffle 阶段须要大量的数据落盘，这其间产生的大量文件读写申请对于底层存储的性能要求较高。Flink 相对来说好一些，因为它是流式的，不须要大量的落盘。将来咱们心愿 JuiceFS 能够间接写到 Lustre 里，然而这样就须要在 JuiceFS 里做一些革新，通过客户端集成的形式，让 JuiceFS 间接读写 Lustre，这对于用户来说就无感知了，也能晋升 shuffle 阶段的读写性能。
上图右半局部的利用有两个场景。一个是简略查问一下 JuiceFS 的数据，例如通过 HiveJDBC 来进行数据预览，这个场景能够通过 S3 网关拜访 JuiceFS。
第二个是大数据平台和 AI 平台联动的场景。比方说 AI 平台的共事在日常工作中须要常常读取样本数据、特色数据等，而这些数据通常是由大数据平台上的 Spark 或者 Flink 工作产生的，并且曾经存储到了 JuiceFS 里。为了不同的平台之间可能共享数据，在 AI 平台的 pod 启动时，会通过 FUSE 的形式将 JuiceFS 间接挂载到 pod 里，这样 AI 平台的共事就能够通过 Jupyter 间接拜访 JuiceFS 里的数据做一些模型的训练，而不必像传统的架构那样在不同平台之间反复拷贝数据，进步了跨团队的合作效率。
因为 JuiceFS 应用 POSIX 规范的用户、用户组进行权限管制，同时容器启动默认是 root 用户，导致权限不好管控。因而咱们对 JuiceFS 做了一个革新，通过一个认证 token 来挂载文件系统，这个 token 外面蕴含元数据引擎的连贯信息和其余一些权限管制信息。
在某些须要同时拜访多个 JuiceFS 文件系统的场景，咱们应用 JuiceFS S3 网关并联合 IAM 策略做对立的权限治理。
目前应用 JuiceFS 遇到的一些难题
第一点，基于用户和用户组的权限治理性能比较简单，在某些场景容器启动默认为 root 用户，权限不好管控。
第二点，对于 JuiceFS Hadoop SDK 的配置优化。目前咱们对 JuiceFS Hadoop SDK 进行优化的伎俩次要有三个配置：juicefs.prefetch、juicefs.max-uploads 和 juicefs.memory-size。其中在调优 juicefs.memory-size 配置的过程中遇到了一些问题，这个配置的默认值是 300MB，官网的倡议是
设置默认值 4 倍大小的堆外内存，也就是 1.2GB。目前咱们大部分工作都是配置到 2GB 的堆外内存，然而有些工作即便配置了超过 2GB 的内存也偶然会写入失败（HDFS 能够稳固写入）。不过这个并不一定是 JuiceFS 的问题，也有可能是 Spark 或者对象存储的起因导致。因而目前咱们也在打算把 Spark 和 JuiceFS 深度适配当前，再一步一步来找起因，争取把这些坑都趟过来，在保障工作稳固的状况下把内存降下来。
第三点，因为整体架构（JuiceFS + 对象存储 + Lustre）变得复杂，可能的故障点变多，工作的稳定性可能会有一些降落，须要其它容错机制保障。例如 Spark 工作在 shuffle write 阶段可能会有相似「lost task」这样的报错，目前还没有定位到具体的谬误起因。
后面提到的 JuiceFS + 对象存储 + Lustre 的架构组合肯定水平上晋升了读写性能，但同时也使得架构更加简单，相应地减少了一些可能的故障点。比如说 Lustre 没有很强的容灾正本能力，如果 Lustre 忽然挂了一个节点，正在运行的工作到底能不能稳固地持续读写 Lustre 外面的数据，或者 Lustre 里的数据意外失落了，是否还能稳固的去 JuiceFS 里通过对象存储从新拉进去，这个目前是不确定的，目前咱们在也在做这种灾难性的测试。
将来和瞻望
基于 Flink + Hudi + JuiceFS 的实时数据湖计划
近期咱们要做的一个是 Flink+ Hudi + JuiceFS 的实时数据湖计划。上图中右边是数据源，通过 Flink、Kafka/Pulsar，把数据实时地写到 Hudi 里，同时 Hudi 的数据会落到 JuiceFS 里替换咱们目前的实时数仓。
大数据云原生的远期布局
最初，介绍一下现实汽车大数据云原生的远期布局，也是一个瞻望。
第一点是对立的数据管理和治理零碎。咱们认为数据湖 2.0 时代，最大的须要解决的问题就是把数据湖 1.0 场景中的数据沼泽的问题解决掉。但当初如同并没有一个比拟好的对立元数据管理、数据目录治理、数据安全管控的开源产品，相似 AWS Glue、AWS Lake Formation。目前咱们在做一个「起源零碎」的我的项目，这个零碎第一步就是把下面的数据库、对象存储里边所有的元数据做对立的目录治理，对立的平安管控，以及对立的数据管理，这块儿咱们正摸索着往前走。
第二点是更快、更稳固、更低成本的底层存储能力。目前所有的场景最大的难点是在对象存储上，对象存储的劣势是稳固、低成本，同时对象存储也在继续迭代。就目前而言我感觉如果大数据云原生要倒退，对象存储必须是要在确保稳固的前提下提供更好的性能。
同时 S3 可能声称反对强一致性了，然而目前我了解基于对象存储的架构设计，可能很难能实现强一致性，或者说它为了实现强一致性，势必要就义一些货色，这可能是一个须要衡量的问题。JuiceFS 原生反对强一致性，这个性能对于大数据平台来说十分敌对。
第三点，更智能、更高效、更易用的查问引擎。引申一下后面提到的对湖仓一体的思考，目前湖仓一体还是在倒退初期，可能还须要经验 5~10 年的倒退过程。Databricks、微软都在尝试做数据湖上的向量化 MPP 引擎，心愿能把湖仓一体架构推起来。这可能是一个将来的倒退方向，然而短时间内如同并没有方法用一个引擎来满足所有场景的需要。
咱们目前的架构基本上是装备了所有的查问引擎，比方 Spark、Flink、关系型数据库（面向 OLTP 的场景）、时序数据库、OLAP 数据库。原则上还是谁优用谁，咱们下层再通过对立的中间件去做治理。再比方 Snowflake，它当初尽管曾经反对了同时查问结构化和半结构化的数据，然而将来像人工智能波及的的非结构化数据（如图片、语音、视频）到底应该怎么反对，目前还是不太分明。不过我认为这必定是当前的一个倒退方向，现实汽车也有相似的人工智能场景，所以咱们会与各个业务方一起去摸索和共建。
最初，整个大数据倒退的最终目标还是要以最低的老本、最高的性能实现数据分析，从而实现真正的商业价值。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)