前言

从 2018 年起，整个汽车行业处于相对低迷的状态，无论是政策导向或是外资引入的放宽，这些都在无形中加速国内车企的转型步伐。除此之外，互联网新势力不断加码入场、消费者依赖并追求更高效的智慧互联，这些都让传统车企感到“力不从心”。

如何在接下来的竞赛中一马当先，或是反超为王？车企又该如何利用好大数据这把利剑帮助企业实现数字化转型？在上月 Kyligence 举办的云系列活动中，我司高级解决方案架构师 张佑铖 结合在车企行业的多年实践经验为大家带来了如何从 0-1 搭建云上数据湖的方案解读。

汽车行业数字化转型的趋势

传统车企面临的挑战越大意味着有更多的机遇，在应对以下新的变化趋势时能快速适应变化就能在新的市场格局下占有一席之地，甚至成为行业新的领军者。

• 移动端广泛使用的新趋势，收集更多车辆信息可以更好的提升用户服务。
• 新能源汽车的普及，电动发动机需要实时掌控电池优化信息。
• 新型技术的发展如云计算、5G时代的到来，让数据传输变得更快，让企业可以对未来的驾驶技术提供更多的数据保障。

但在应对上述数字化转型趋势过程中众多企业也经历过以下数据挑战：

• 数据来源广
• 数据类型多
• 数据量大
• 数据增长快
• 分析时效性强
• 分析性能要求高

针对上述数据特征，许多企业的架构还是停留在传统数仓的架构体系中，无法做到快速灵活分析；其次数据接入端和数据消费端的技术也在发生变更，传统数仓架构必须要面临着架构升级的趋势。而数据湖技术可以很好得帮助车企解决上述转型中遇到的问题。

车企数字化转型的核心——数据湖技术

数据湖是企业新型数据生态的核心枢纽，负责收集全渠道的数据，确保数据能够落地。相比于传统数仓来说，数据湖没有一个结构化的准入要求，能够接入上游各种类型的数据，可以是结构化、半结构化，也可以是完全无结构的日志、音频、视频文件等，确保数据的统一汇聚，打破数据孤岛，对资源的集中化管理，形成数据资产中心。下游多元化的应用也可以直接对接数据湖，实现实时或者离线的数据分析，给业务系统提供数据服务，最终实现数据服务化，资产化。

对于车企来说，如果想要寻找经济适用型的数据湖方案，又能高效支撑业务的灵活发展与分析需求，并且能做到快速上线，相对于传统的本地数据湖而言，云上数据湖架构是不错的选择。

本地数据湖 VS 云上数据湖

云上数据湖的优势

1） 低成本实现单一可信的数据源

• 集中把所有非结构化、结构化的数据能够统一的落地
• 近乎无限的存储能力，无需担忧存储扩容的问题
• 成本非常低廉，数据从热到冷有对应的存储方案

2） 近乎无限的计算和扩展能力

• 计算和存储是分离的
• 计算资源按需申请使用，理想状态是可以近乎无限扩展的
• 有丰富的应用组件，可以满足各应用场景的需求

3） 完备的数据安全策略

• 完善的资源访问策略及权限精细化控制能力
• 虚拟网络及管理网络安全策略确保数据不会被随意访问
• 数据容灾备份
• 监控资源和服务情况

数据湖的挑战

在现实情况中，企业想要做好数据湖的架构搭建却不是一件容易的事情，对于企业 IT 人员来说会面临以下挑战：

1）海量数据的存储开销大

车联网可以产生大量的电气设备、驾驶过程、人机交互、地理位置数据。企业积累的原始数据集包含的数据种类丰富度（数据广度）、数据积累的时间长度（数据深度）、数据细粒度和产生频率（数据密度）决定其可能具有的价值高低。

现在很多企业会追求积累更加广泛、深厚、密集的原始数据集。但由于起初利用数据的能力非常有限，原始数据转换成高价值数据的速度相比数据产生的速度是非常缓慢的，导致原始数据越积越多。

高价值数据由热转冷：从原始数据抽丝剥茧得到的高价值数据随着时间流逝，其数据价值对当前和未来的业务贡献度普遍会降低，且越来越少。因此数据被提及或使用的频率会逐渐降低，数据由热转冷，偶尔会被用到的冷数据越积越多，新的高价值数据还在不断涌入，存储开销越来越大。

2）多源集成能力要求高

平台需要能够集成和存储多种来源、多种形式的数据。融合的分析和应用要求企业将车联网数据、互联网数据、企业内部数据和外部供应商数据一起结合，这要求平台不仅需要兼容关系型数据库数据源，还要具有集成文件、媒体数据、流数据、接口来源数据的能力。另外对于数据源的变化，平台也要有实时的感知能力，能够及时更新与之相关的分析结果。

3）弹性扩展能力要适应动态变化

平台需要能应对数据接入和数据计算压力的大范围波动。数据系统在高峰期同时要接受来自前端的查询计算压力，以及来自后端的数据接入、校验、离线或实时仓库数据计算和存储压力，此时需要大量硬件资源来完成工作。但在平峰期系统所需的计算、网络、存储又趋于稳定，可以释放空闲的资源。

IT 基础设施如果有足够弹性的能力来适应这种大动态的变化，既能显著降低业务高峰期由于 IT 设施导致的效率瓶颈，又能在业务平峰期减少系统空转带来的资源浪费。

4）100% 安全保障

平台需要自身以及数据资产的安全得到完善的保障。

首先，原始数据集所具有的业务含义会导致不同数据集需要采用的安全保护策略有显著差异。

其次，原始数据来源和其结构的多样化产生了对原始数据存储、处理方式的多样化要求。数据系统会对结构化、半结构化和非结构化数据采用不同的存储形式，而且在对这些数据进行离线或实时处理使用的技术栈也多有不同。

第三，数据系统作为一个形式上的整体，实际由数据采集、存储计算、模型构建、数据展现这些基本能力组成，更进一步还要具有数据治理、任务调度监控、资源动态分配、服务组件运行状态监控和告警等保障平台运营的能力。

因此数据系统在提供众多复杂能力的同时，为了其每一项服务或功能能够应对来自不同场景、不同角色用户对其接入安全性、数据安全性的考验，平台需要在所有层面实行安全机制，有严格的身份验证机制，能够对用户行为进行追溯审计，对数据的访问范围进行安全管控。

企业如何找到省心、安全、同时又能保证高效性能的云端数据管理工具，关键还有真实的车企应用案例，帮助用户做好架构搭建，可以接着看下 Kyligence Cloud 是如何助力企业完成云端“蓝图”的构建。

Kyligence Cloud，一站式云端数据管理和分析服务

Kyligence Cloud 利用云原生的计算和存储，帮助企业在任意数据湖上构建快速、弹性、成本高效的创新型大数据分析应用。Kyligence Cloud可以有效提高数据分析的时效性、节省IT总成本、通过统一数据服务赋能跨部门协作，并灵活应对未来数据量和业务发展可能带来的挑战。

1) AI增强的分析引擎：自主研发的创新型AI增强引擎，可智能发现高价值数据，并通过自动预计算加速关键业务分析，提供海量数据下的高并发、高性能的分析能力，不仅有效提高数据分析的时效性，又能极大地节省总体成本。

2) 统一语义层：面向业务的统一语义层，对数据模型、维度、指标等实现统一定义和管理，帮助企业实现统一的数据中台，为业务应用提供单一数据囗径，打破数据孤岛，提高跨部门共享、协作的整体效率。

3) 云原生架构：基于云原生架构设计，支持云原生数据源例如AWS的S3、Azure的Blob，利用云原生的计算与存储资源，提供一键部署、按需启停、动态伸缩等自动化运维能力。降低运维管理的复杂度的同时降低运维成本。通过容器化部署，提供高容错能力，保障系统的稳定性。

4) 全面集成 Apache Spark 生态：与主流大数据技术生态集成，为企业提供各行业的的端到端方案，既实现数据分析应用落地, 又为上线机器学习、人工智能应用做好了准备。

总的来说，通过 Kyligence Cloud 在云上搭建数据湖平台能够通过低成本，更高效的去访问海量的数据，并且能够应对高并发的场景，应对这样高并发场景之后能够使用相对来说更加低廉的成本。结合过往积累了大数据平台相关的最佳实践，帮助客户快速落地IT底层的架构。

案例：某汽车品牌企业级数据湖建设

该车企原本的 IT 架构是本地部署，受限于本地架构的限制， 每天落地处理的数量非常大，会被迫丢弃一些有价值的数据。结合企业自身发展方向的调整，新能源动力车的发布，采集更多数据，从车企角度来看，为了更好适应企业未来长期发展目前，传统本地的 IT 架构需要快速的替代升级。

整个项目的一期是搭建统一的云上数据湖，从开始设计架构制定 SOW 到最终项目落地一共就花了 3 个月的时间，非常快速的完成了从传统本地部署到云上数据湖架构的升级。

1）企业设计目标：

从设计的目标来看，为了能支持各种数据资产的集成，设计了一层数据网格，能支持各种数据的自动集成，也便于进行数据管理和编目数据资产。通过数据网格，数据收集落地到云上的数据湖中。对于数据访问需要做到统一的身份认证和访问管理，以单点真相提供与市场相关的数据资产。在数据湖之上有很多的数据出口，为了统一管控需要封装统一数据API层，屏蔽底层数据的复杂度，确保上层的不同应用通过统一的方式进行连接。

2）基于 AWS 数据湖的架构设计

基于这样的设计目标，最终实现了实时、离线两条数据流处理的分支。实时的数据流，统一接入 AWS 的 Kinesis 在做数据分发，一部分通过数据消费直接落地，另外一部分通过 Spark streaming消费后流入 DynamoDB; 离线的数据通过一系列的文件校验、文件检索等步骤处理完落地到AWS S3 上，后面就是 ETL 和数据分析。数据 API 封装在统一的数据服务 Data Services 里。

数据都接入 S3 后，如果没有分层，数据会比较凌乱不好维护。从逻辑上主要分了三层（如下图所示），首先是Raw Data(原生数据)，通过各种方式去接入，有不同的格式，有SVS，有 XML，有 JSON 格式，还有一些非结构化的数据，都会落地到这个 Raw Data 里，然后会通过一些 ETL 的处理以及 Catalog 的定义，把有价值的数据进行提炼，生成 Golden Data (黄金数据)，在 Golden Data 之上是OLAP Cube (预计算结果数据)，最终是通过 OLAP Cube 提供高效的数据服务。这样的分层其实能够统一进行一个数据的管理，然后减少一些重复的数据开发。

3）云上数据湖平台安全设计

云上的数据安全是非常重要的，Kyligence Cloud提供安全可靠的云上数据管理和分析服务。一方面利用云平台本身的服务可靠性和安全性可以有效保障基础设施的安全性；另一方面，Kyligence Cloud本身在数据交换、数据存储、数据访问等方面采用业界标准的安全策略，以保障数据安全。

• 网络安全：所有的部署在用户自己的私有网络中，通过配置私有网络的防火墙，可以将Kyligence Cloud服务与外网隔离，阻断外网对数据服务的访问。
• 存储安全：依托云存储提供的安全特性，可以对工作目录内的数据进行加密存储。使用云平台托管的密钥或者通过自己的密钥进行加密管理，满足组织的安全性和合规性承诺。
• 数据交换安全：默认使用SSL加密所有对外数据交换，并使用云平台原生的数据访问方式（如AccessKey，IAMRole等）访问数据源，以满足数据传输过程中的安全要求。
• 身份认证与鉴权：提供身份认证与鉴权功能，支持与第三方LDAP服务集成（如OpenLDAPNActive Directory)。支持为不同用户设置不同操作权限，实现细粒度用户角色管控，
• 数据访问：提供针对项目级/表级/行列级的细粒度数据访问控制。为不同用户、用户组提供不同的数据视

4）数据湖商业价值-分析场景实践

完成了这个数据湖搭建之后，陆续有不同的应用开始尝试落地数据湖，以下是车联网数据分析的应用场景：

• 第一个场景是车主数据的接入，车主可以通过移动手机App或者是车载一些应用进行数据接入，通过收集车主行为，对把车主进行分群分类，最后实现精准进行服务的推广。
• 第二个场景跟服务相关，车主接入流程有的时候非常长，根据流失率的分析，可以判断车主在接入过程中的哪些步骤是引起车主流失的问题关键，优化用户接入的流程，减少用户的流失率。
• 第三个场景是收集车辆行驶轨迹，行驶轨迹数据作为基础，可以衍生出一些服务，比如说像代驾等等。后期的规划过程当中会上更多的应用场景，数据的维度会更加丰富。甚至可以引入第三方的数据来丰富车联网的应用，例如引入交通系统的数据，为车主推荐更好的出行服务；引入实时停车信息，为车主推荐离目的地不远的廉价停车场。

总结

在这个案例中 Kyligence 帮助客户从业务场景、技术架构、数据安全、项目实施等多角度进行完整规划，用三个月的时间完成云上数据湖平台交付，为车联网场景落地提供了技术基础和数据保障。通过数据的收集和分析，不断优化车辆质量和安全保障，进一步迭代提升用户体验和忠诚度。