专业物联网产品平台——让生活更美好
电话+V： 152079-09430 ，欢迎咨询长安汽车车联网大数据岗位怎么样呀啊，[物联网技术分享]，[物联网场景应用]，[物联网产品推广]，[物联网流量搜索]，[物联网产品创新]，[物联网广告价值]，[助力创造美好生活]
一、大数据运维工程师的基本职责
大数据运维工程师需要处理公司大数据平台各类异常和故障，确保系统平台的稳定运行。下面是我为您精心整理的大数据运维工程师的基本职责。
大数据运维工程师的基本职责1
职责:
1、技术保障各底层支撑系统的可靠性与稳定性;
2、负责车辆网平台的运行监控的解决方案编制、实施与二次功能开发;
3、负责技术文档手册编写，更新，经验总结沉淀，培训分享;
4、负责对新技术和方案进行调研，评估和引进，用技术去提升运维生产效率
任职资格:
1、熟悉常见的应用服务部署和调优(Nginx、MySQL、Redis、MongoDB、ELK，Hadoop等)，熟悉高可用集群、负载均衡集群的规划与搭建;
2、熟练使用Linux、TCP/IP网络协议栈，了解常用的Troubleshooting手段和常见性能指标
3、具有车联网平台运维的经验，精于容量规划、架构设计、性能优化;
4、熟悉主流PaaS云产品的使用，具有运维平台开发经验者、参与过开源产品的开发者优先;
5、优秀的沟通能力，出色的学习与钻研能力，良好的问题分析与解决能力;
6、对行业技术敏感度高且细致，善于思考，乐于发现，对解决具有挑战性问题充满激情。
大数据运维工程师的基本职责2
职责：
1、负责维护服务器的运行，包括巡检、故障排除、数据备份等业务，保证服务器高质量、高效率运行状态;
2、负责服务器漏洞整改及补丁升级;
3、负责hadoop运维相关工作;
4、负责大数据平台的日常部署、升级、扩容、迁移;
5、负责高并发，大存储和实时流的Hadoop/spark大数据平台规划，运维，监控和优化工作。
任职资格：
1、2年左右服务器运维经验;
2、对linux基础运维命令熟悉，shell，python至少精通一种，如会scala语言可优先考虑;
3、熟悉Linux的维护和管理，熟悉bat及Shell脚本开发，能看懂Python/Scala优先;
4、做过大规模hadoop集群优先;
5、大数据项目：包括不限于hadoop、hive、kafka、hbase、spark、Kudu、Impala等大数据生态的平台搭建，监控，运维，调优、生产环境hadoop集群troubleshooting、hadoop版本升级管理及优化支持。
大数据运维工程师的基本职责3
职责:
1、负责Hadoop平台搭建，运维，管理，故障处理。
2、负责保障大数据平台的高效运转、提升系统稳定性和安全性。
3、对平台的Hadoop，Hbase，Kafka，Hive等进行优化。
4、建立Hadoop集群管理和维护规范，包括版本管理和变更记录等。
岗位要求:
1、有丰富的Hadoop生态系统的运维经验，了解Hadoop、Storm、Spark、Kafka这些组件的原理，具备部署、实施、维护hadoop及相关组件的能力;
2、至少精通Perl/Python/Shell脚本语言中的一种;
3、掌握Linux操作系统的配置，管理、优化以及各种常用命令，能够独立排查及解决操作系统层的各类问题;
4、分析问题能力优秀，善于从各种系统、应用日志中寻找出问题的原因。
5、有独立分析问题和解决问题的能力，能出差。
大数据运维工程师的基本职责4
职责：
1.负责Hadoop、spark、hbase、oozie、hive等平台运营和优化工作，保障平台服务运行稳定、高效。
2.负责大数据方案架构及方案落地;
3.开发Hadoop大数据管理平台与监控建设;
3.负责hadoop平台部署、维护;生产问题、告警、故障处理及服务器维护、日常值班;
4.负责集群网络架构、机器管理等。
任职资格：
1.全日制本科以上学历，三年以上后台系统运营工作经验;
2.熟悉hadoop原理，具有Hadoop平台应用及管理经验，熟悉hadoop、hive、spark、hbase、oozie、druid、kylin、flink等开源项目及部署、维护、调优;
3.熟悉linux操作系统及调优;熟悉sql编程，熟悉Shell/Python/Java/Perl语言的一种或多种，有开发经验优先，熟悉nagios，cacti，ganglia，zabbix，zenoss优先;
4.对大数据和自动化运维开发有浓厚兴趣，有大规模hadoop运维经验者优先;有hadoop/hbase/spark/hive开发经验者优先。
大数据运维工程师的基本职责5
职责：
1.负责大数据平台的稳定性和性能优化;
2.负责大数据项目的运维工作;
3.针对业务需求制定统一的运维解决方案;
4.完善自动监控报警系统，对业务层面关键指标进行监控与报警通知;
任职要求：
1、熟练掌握hadoop平台搭建、维护，有平台优化经验;
2、熟悉HDFS、Hive、Spark、HBbase、Kafka、Flume等组件的原理，有阅读源码能力者优先;
3、熟悉腾讯云产品，有腾讯云EMR使用经验者优先考虑;
二、车联网大数据建设中心是干嘛的
数据整合和处理，数据分析和应用。
1、数据整合和处理：车联网大数据建设中心负责收集和整合各种车联网数据源，包括车辆传感器数据、GPS定位数据、交通信号数据、车辆管理系统数据等，通过数据清洗和预处理技术，将数据转化为可用的格式，为后续的分析提供基础。
长安汽车：基于云器Lakehouse的车联网大数据平台建设
原创2024-03-0709:00·DataFunTalk导读近年来随着智能汽车行业的迅速发展，数据也在呈爆炸式增长。长安大数据平台承接了长安在生产上大部分流量应用及日常生产业务应用。本文将分享长安汽车在车联网场景下大数据平台建设面临的一些挑战和具体落地的实践。主要内容如下：
1.背景介绍2.长安汽车面对的挑战3.改造前的架构和挑战4.改造后的架构介绍5.改造后的价值与效果6.总结及后续计划分享嘉宾｜石静猛长安汽车×云器科技联合项目组项目组负责人编辑整理｜刘闰丰内容校对｜李瑶出品社区｜DataFun
01背景介绍“以前人们称汽车为配备电子功能的机械产品，到今天演变为具有机械功能的智能电子产品，这是一个非常大的转变。”——长安云器联合项目组石静猛转变，源自产业的数字化转型。新能源汽车厂商正在用数字化技术打造差异性的竞争优势，关注点由发动机的制造逐渐趋向于基于数字化技术打造丰富的用户体验。中国的汽车产业正在高速发展的过程中完成数字化升级，我国汽车产销总量连续15年稳居全局全球第一。在产销快速增长的同时，车企正在通过数字化提升乘用车产品的竞争力。（图1：汽车产销总量及增长率）数字化关系到车辆如何更好地应用，如何更好地跟人互动，与人们的生活打通，包括更广为人知的智能化自动驾驶、智能座舱等应用场景，以及不为人所知的汽车设计、生产制造过程，数字化正在重构汽车工业。02长安汽车面对的挑战面对超大规模数据量和业务的飞速发展，长安大数据平台面临的挑战可以总结为三大方面，即成本高、用数难、运维烦。1.成本高每天有20+TB的新增数据，一年就会接近9PB的规模。随着新能源车的比例越来越高，并且新能源车的数据要求全生命周期存储，可能要存储十年，整体下来，存储成本是累加的。业务依然在快速增长，第二年数字可能就会翻倍。在这样的数据量下，计算是超大规模的，即使是一个非常简单的场景如一个简单的query，都可能会因为数据量庞大而计算困难。2.用数难首先，查询分析慢，因为数据量大，查一天的数据都很难，更何况在很多场景中需要查多天的数据，比如取一辆车在几个月里的明细数据进行分析，将会是一个非常大的挑战。另外，实时数据加工比例非常低，因为数据量大，如果以传统方式对全量数据进行实时加工，成本会非常高。因此只能采用Lambda架构，其中除了一套t+1的离线链路，还要有一套实时链路处理一些重要数据。这带来的问题是，当业务新增需求时，或者做一个新的数据产品、处理一些新的信号时，需要从头开发整个链路，在实时链路上重新加入这些数据，开发链路会非常复杂，要跨多个组件、多个平台，除了Java，还需要SQL等等，开发门槛高，效率低。3.运维烦Lambda架构下，不同场景用不同的产品，这种多组件的架构非常复杂，运维困难。同时，性能瓶颈难以突破。另外，每年需要对平台链路进行一次优化升级，运维成本持续高涨。还存在存储空间报警，计算资源浪费的情况。03改造前的架构和挑战1.改造前的架构长安汽车大数据平台改造前的整体架构是典型的Lambda架构，分为实时和离线两部分。实时链路使用Flink对数据进行一些简单的加工，加工后的数据写到Doris、ClickHouse或StarRocks等分析型平台上。中间也包括一些HBase的应用。离线链路车上的数据实时接入Kafka，再通过Flink实时消费写到HDFS的某个文件，写完之后，天级别的定时任务将这个文本文件加载成Parquet文件，再建成表，后面做t+1的分析处理，这就是整个离线的链路。2.挑战首先，长安汽车面临着高TPS+大吞吐的挑战，除了每天会有22TB以上的增长，实时吞吐的峰值也超过了每秒500万条，这一数字非常可观，并且数据量仍在快速增长。其次，很多JSON这种半结构化数据，信号列非常多，随着新能源车数据产品应用的场景越来越多，信号列增长非常快。另一方面，Lambda架构下的实时化比例非常小，不到10%，主要是离线加工。04改造后的架构介绍针对上述挑战，我们对大数据平台进行了改造，将数据平台升级到一个更简洁高效的架构。如下图所示，整体上从之前的Lambda架构升级为了一体化的Kappa架构，并且从t+1加工变成了百分百全域数据实时加工。平台的各种组件变成了一个组件，最终是一份资源、一个引擎，一种开发语言SQL，支持不同的workload，包括实时的加工、离线的加工、实时分析、ad-hoc查询等等。05改造后的价值与效果1.解决成本高问题（1）存储成本以某张表一天的数据量为例，将同一份数据（数据条数和内容完全一致）导到两个平台上来进行对比。在旧的平台上，HDFS存储，单副本大约为2.8T，而新平台，COS存储只有831G。等价换算后，每百亿条在旧平台上为373G，而新平台是130G。存储节省了65%。这还只是单副本的对比，如果是两副本，降低的比例就更高了。实现这一改进的关键措施如下：在Parquet存储上自研了更多编码优化，对半结构化数据自研map格式存储，压缩率比JSON更高，查询效率也更高，在存储上对数据进行了行级+信号级的二级去重。车联网信号数据常存在信号跳变的情况，而去重的基本原则就是不丢失任何跳变信息。乘用车进行行级去重之后，存储降低60%左右。新能源车，采用行级+信号级去重，存储降低38%左右。在存储降低之后，下游的计算性能也可以得到极大提升，从而节省计算资源。去重前的原始数据可以归档，进一步降低成本。（2）计算成本计算成本方面，在同样的数据量、同样的加工逻辑、得到同样的结果，并保证结果正确的前提下，从T+1集中时间计算，分摊成近实时增量计算，比如5分钟加工一次，一天共288次，将全天的资源累加起来，与之前天级的计算资源相比较，计算口径为CU时=8core*1hr。可以看到，Spark用了14个CU时，而新平台仅用了3.5个CU时。我们将Spark的资源再增加一倍，把系统负载因子乘以50%，之后与新平台对比，仍然会有50%左右的计算成本降低。说明同样的数据，得到同样的结果，一样的加工逻辑，将离线计算变成实时计算的基础之上，仍可以获得大幅的计算成本降低。这里需要说明的是，以上对比都是基于真实生产的ETL加工任务，这其中用到的核心技术就是增量计算。2.解决用数难问题（1）提升查询性能先从查询性能上来说，之前查询数据非常慢。这里提取了8个子场景，分别代表了不同的业务价值，比如某些签到信号分析的查询、智慧能耗的分析、云云诊断仪、智能诊断等等。还包括一个创新场景，即跨天查询的场景。从上图中可以看到，平均性能有三倍的提升。规模越大，表现越好。尤其是跨天场景，以前跑不出来，而现在5分钟左右就可以跑出来。查询数据量达到每天700亿条，其中跨天查询，三天2000亿条数据。实现这一提升，归功于查询plan的优化，ShareEverything架构下更高效的读写性能，以及算子优化、向量执行、shuffle加速等一系列改进。（2）实现低成本下的100%数据实时用数难中第二个问题是实时的比例低，之前业务想开发一个有实时要求的数据产品，整个过程是非常痛苦的。而现在变成了百分百数据实时，之后要做一个数据产品，只要从这个数仓平台上拿数据、拿结果，直接做开发即可，效率大幅提升。要做到百分百数据实时，低成本是关键，虽然用Flink也可以但成本高昂难以接受。上图展示了全链路实时加工的流程。其中有一个IGS：IngestionService，是读写分离的一个独立的服务，能够支持结构化/半结构化的数据实时写入，数据会落到业务库中对应的分区表里，然后对数据做去重，基于去重后的数据做加工，每条链路都是实时加工，并通过增量计算技术来实现，因此成本比较低。同时对延迟数据也能进行加工，因为能够识别出延迟数据落在哪个业务分区，增量计算只算那个分区相关的结果即可。整个数仓建成了一个实时的数仓，支撑车企的各项业务应用。这里以一个典型的业务场景为例，即车联网数据质量分析。以前的平台实现困难，因为要接入一天上千亿条数据，对里面的信号进行分析，一条数据里面可能有几十上百个信号，要把信号explode出来，等于要面对上千亿条数据再乘以几十倍的一个数据量来进行分析。传统的方式是根本算不出来的，现在变成了近实时的方案，用增量的方案即可实现。上图是增量计算的示意图。每次处理Delta数据，有两种模式，一个是增量计算MV，另一个是tablestream的方式。Tablestream方式也支持多分支，可以在一个表上创建多个，然后做ETL加工、监控等等，并且不会增加存储成本，因为底层都是Meta支持的，只需要做好应用即可。增量计算MV，指的是可以用全量的语义写逻辑，系统内部自动地以增量的方式计算，而且会自动刷新，不需要配置调度系统自动触发，所以整个开发过程非常简单。（3）提升数据开发及协同效率在解决用数难的问题方面，还实现了开发和协同效率的提升。比如以前的开发语言有很多种，包括Java、Python，以及多种SQL，开发门槛高，业务方使用难。新的平台统一成了一种语言，同时支持实时和离线分析。另外，在Lambda架构下，业务逻辑要维护多套代码，基本上所有的厂商都会有面临这样的问题，还可能带来数据不一致的问题。而新的Kappa架构下则只需一套代码。并且，以前一个新的开发，需要打通多组件、多链路、多份数据，效率很低。现在一份数据，一个平台，不再需要导入导出。最后，针对元数据割裂的问题，新的架构下统一了元数据，可以很方便地找到结果表的上游是谁，在数据出问题时也可以进行高效地排查。3.解决运维烦问题（1）架构升级，减轻运维负担针对运维烦的问题，由原来的10+组件，变成了现在的一套SaaS化服务，并且是企业化托管的一套服务，无需投入很大精力，即可轻松完成运维工作。（2）具备线性能力，避免每年一次升级另一个非常关键的问题是平台要具备线性能力，避免每年一次升级。随着业务的增长，处理能力也线性增长，资源成本也以一个可控的方式增长。从上图中可以看出，在新一代数仓中，随着数据量的翻倍，资源成本也只是接近翻倍。观察真实的生产环境，包括一天中的高峰期、低谷期，可以看到，吞吐与资源的增长基本上也是接近1:1的。ETL加工上，我们也对实时的数据吞吐和资源消耗进行了对比，基本上也是接近1:1的关系，证明了其线性的能力。06总结及后续计划我们最终的期望是希望车联网数据的应用可以像使用自来水一样简单，这样我们可以自由地利用数据做一些车辆上的创新，想用什么数据打开水龙头即可用。为了实现这一目标，还有很多方向的工作需要做，除了已经规划的更多业务场景的接入之外，未来还要与AI结合，让业务方更自助地应用。以上就是本次分享的内容，谢谢大家。
【GSFAI BANK FINANCING】尊享直接对接老板
电话+V： 152079-09430
专注于为物联网运营推广及产品打包交易配套流程服务方案。为企业及个人客户提供高性价比的共享解决方案，致力于首个物联网行业的平台搭建与合作
当前位置：新闻详细
友情链接