近几年，汽车行业全面拥抱电气化和数字化，一方面有行业先行者和政策法规的激励作用，另外一方面随着无线网络升级换代以及云计算技术越发成熟，车机端到企业端能够更加实时稳定传输丰富数据。如何利用好这些数据，为生产、营销决策提供支持是各大车企都迫切关心的问题。大数据分析对于车企的价值也更加凸显。
对企业来说如何搭建一个可应对未来数据量几何级增长的数据分析平台？是选在在本地搭建还是云上？在数据湖上如何构建？Kyligence 团队很幸运参与到一家世界领先的车企数字化转型的实际项目中，今天特别邀请到这个项目的负责同事与大家分享 Kyligence 在数据湖上搭建大数据分析平台方面的一些思考。
背景
过去几年，汽车行业在排放法规、激励政策、行业竞争等内外压力驱动下实施了电气化战略、进行数字化转型。产业链借助云计算、IoT、边缘计算、微服务、反应式架构等技术手段完成V2X（Vehicle-to-everything）的建设，已经建立了对车辆电气数据和用车数据全面、准确、实时的收集的能力。
图1：车联网数据链路：车-企业-公共平台
人们对汽车的定位也逐步从机械产品向电子信息系统控制的智能产品转变，由单纯的交通运输工具逐渐转变为智能移动空间和应用终端，有网联能力的新能源汽车保有量也越来越高，行业向纵深发展越来越依赖对数据的应用。
在不久前，中国发改委印发《智能汽车创新发展战略》中提出“加强智能汽车复杂使用场景的大数据应用，重点在数据增值、出行服务、金融保险等领域，培育新商业模式”。这标志着行业在投入了诸多精力打通了车辆端到企业端的数据链路后，整个行业必须尽快驶入挖掘数据更高附加价值的快车道中，深耕数据实在推动业务发展。
以汽车行业电气化和数字战略先行者Tesla公司为例，自2012年起累计生产交付了100万辆电动车，所有这些车辆都可以持续不断上传三电系统、车载雷达、摄像机、车主用车行为和全球主要城市的交通信息数据。若一辆车平均每天行驶2小时，行驶中每秒上传10kb压缩数据，100万辆车每天产生的数据量大约为 70tb。Tesla借助云计算、大数据技术能够处理利用这些数据，用来提升电池安全与性能、提高汽车自动驾驶能力以及为车主提供个性化的用车体验。
Kyligence 服务的这家客户今年将在中国推出第一款纯电动跑车，加上存量车型，到2021 年大约会有 10 多万台具有智联模块的车辆行驶在道路上。虽然车辆端到企业端数据链路建设的十分成熟，但因为还没有数据平台的支持，只能采用低频策略收集有限的数据满足安全监控等基础应用场景，也无法积累更久远的数据，这些导致数据价值得不到很好的发挥，无法满足行业对车辆智能化发展、数据创新型应用的要求。这家企业于去年下半年启动了中国区数据平台建设计划，希望能够借助平台基础能力，将核心经营数据、合作伙伴数据、互联网开放数据、车联网实时数据做综合运用，使数据为业务创造更多价值。考虑到企业级数据平台建设是一个持续迭代的过程，结合客户方中短期内业务部门、IT团队对平台能力的要求，我们确定了首期建设目标是打造企业级数据湖。
架构挑战
数据湖（Data Lake）概念自2011年被推出后，其概念定位、架构设计和相关技术都得到了飞速发展和众多实践，数据湖也从单一数据存储池概念演进为支撑高效、安全、稳定企业级数据应用的下一代基础数据平台，也是客户进行数据平台建设的核心诉求。
基于上述业务背景和客户需求，我们在进行数据湖的方案选择和架构设计时，需要解决的核心挑战主要有以下四个方面：
1. 良好经济的存储方案，平台经济性的要求主要为了应对以下两个问题：
原始数据被大量存储：车联网可以产生大量的电气设备、驾驶过程、人机交互、地理位置数据。企业积累的原始数据集包含的数据种类丰富度（数据广度）、数据积累的时间长度（数据深度）、数据细粒度和产生频率（数据密度）决定其可能具有的价值高低。很多企业会追求积累更加广泛、深厚、密集的原始数据集。但由于起初利用数据的能力非常有限，原始数据转换成高价值数据的速度相比数据产生的速度是非常缓慢的，导致原始数据越积越多。
高价值数据由热转冷：从原始数据抽丝剥茧得到的高价值数据随着时间流逝产生的问题是，其数据价值对当前和未来的业务贡献度普遍会降低，且越来越少。因此数据被提及或使用的频率会逐渐降低，数据由热转冷，偶尔会被用到的冷数据越积越多，新的高价值数据还在不断涌入，存储开销越来越大。
2. 多源集成能力，平台需要能够集成和存储多种来源、多种形式的数据。融合的分析和应用要求企业将车联网数据、互联网数据、企业内部数据和外部供应商数据一起结合，这要求平台不仅需要兼容关系型数据库数据源，还要具有集成文件、媒体数据、流数据、接口来源数据的能力。另外对于数据源的变化，平台也要有实时的感知能力，能够及时更新与之相关的分析结果。
3. 弹性扩展能力，平台需要能应对数据接入和数据计算压力的大范围波动。数据系统在高峰期同时要接受来自前端的查询计算压力，以及来自后端的数据接入、校验、离线或实时仓库数据计算和存储压力，此时需要大量硬件资源来完成工作。但在平峰期系统所需的计算、网络、存储又趋于稳定，可以释放空闲的资源。IT基础设施如果有足够弹性的能力来适应这种大动态的变化，既能显著降低业务高峰期由于IT设施导致的效率瓶颈，又能在业务平峰期减少系统空转带来的资源浪费。
4. 全面安全性保障，平台需要自身以及数据资产的安全得到完善的保障。
首先，原始数据集所具有的业务含义会导致不同数据集需要采用的安全保护策略有显著差异；
其次，原始数据来源和其结构的多样化产生了对原始数据存储、处理方式的多样化要求。数据系统会对结构化、半结构化和非结构化数据采用不同的存储形式，而且在对这些数据进行离线或实时处理使用的技术栈也多有不同；
另外，数据系统作为一个形式上的整体，实际由数据采集、存储计算、模型构建、数据展现这些基本能力组成，更进一步还要具有数据治理、任务调度监控、资源动态分配、服务组件运行状态监控和告警等保障平台运营的能力。
因此数据系统在提供众多复杂能力的同时，为了其每一项服务或功能能够应对来自不同场景、不同角色用户对其接入安全性、数据安全性的考验，平台需要在所有层面实行安全机制，有严格的身份验证机制，能够对用户行为进行追溯审计，对数据的访问范围进行安全管控。
解决方案
数据湖早期的落地案例与Hadoop技术生态的发展息息相关，可以说是共生共存，因此大量的数据湖实践方案都是基于本地的Hadoop集群。而近几年，随着云计算的普及和飞速发展，各家云厂商的云上数据湖方案也逐渐成熟。
两种方案的优缺点对比大致如下：
在方案选择过程中，除上述客观存在的挑战外，客户对平台还有以下几个方面的期待：
1. 较高的敏捷性：平台可以快速响应业务的变化，如新增一个项目或添加一个新的数据格式，在整体架构不进行大的变化下，能满足既定和突发的需求。
2. 良好的灵活性：能够尽可能的用自动化的方式快速部署系统，所需的测试环境能够根据实际需要任意扩大或缩小，按需计费，避免资源和成本的浪费。
考虑到客户的车联网系统和车机数据已经在公有云平台上运行和存储，公有云的安全性及其优势也被企业所熟知。结合客户对数据湖平台架构的期望和需求，项目最终选择基于AWS公有云来构建云上数据湖平台。
云上数据湖在IaaS方面的优势：
近乎无限的数据存储能力和强大的容灾能力：虽然本地部署集群利用HDFS能够做到近乎无限的且较为可靠的数据存储，但云存储在可靠和无限存储的同时能够提供强大的同城、异地容灾能力
较低的存储成本：对数据进行冷热度划分，将冷数据置于归档存储中，而高度结构化且经常访问的数据存放在高性能对象存储中
计算与存储分离：通过避免计算和存储资源高耦合部署的方式来避免一旦扩展存储就必须扩展计算资源，造成资源的浪费
按需使用资源：通过实时监控数据平台对底层存储和计算资源的需求情况，为其动态申请或释放存储和计算资源，降低成本，提高IT基础设施投资回报率
云上数据湖在PaaS和SaaS方面的优势：
托管的大数据基础服务能力：例如，通过使用托管的（Managed Bigdata Platform Service）Hadoop、Spark、Hive、Flink、HBase、Kafka等开源生态存储和计算服务，能够使云数据湖快速并持续稳定地支持离线批处理、在线流处理、机器学习等场景，具备构建数据仓库的能力。
丰富的数据应用能力：例如，分别一键部署Marketplace中的Kyligence Cloud和Tableau Server服务，通过二者的能力结合使企业快速在数据湖之上获得数据仓库多维分析及数据可视化展现能力。
云上数据湖利用云平台管理套件中的监控工具、网络管理、安全管理等服务的优势：
资源快速安装和变更能力：能够对基础设施、应用程序进行代码化，对平台快速创建或编辑，使IT基础设施能够快速响应业务实际需求
完善的资源访问策略及权限精细化控制能力：能够对IaaS、PaaS、SaaS资源访问策略和资源间共享策略进行精细化权限控制
创建或修改虚拟网络及管理网络安全策略的能力：通过配置子网、路由表、安全组及其规则、VPN等来实现安全且灵活的网络策略
监控资源和服务情况：通过在云监控模块中配置策略来对运行中的资源和服务异常情况进行记录或告警
最佳实践
Kyligence 团队在一线长期服务客户过程中较为了解客户对数据的实际需求和使用场景，将积累的交付经验与公司在大数据产品、云计算产品研发过程中的积累相结合，以标准化方案和服务作为基础，结合每一个客户的实际需求和条件做出定制，最终帮助客户达成项目期望。
总体架构
分层介绍
1.数据集成
我们为客户采用数据集成工具集（Data Integration Toolkit）+专项定制方案的形式进行源数据的发现和集成，支持主要Raw Data类型有：
关系型数据库的镜像库：包括带时间戳、有主键不带时间戳、无主键不带时间戳的数据。
在关系数据库对接过程中，会根据数据库类型、数据源质量、数据实时性要求、数据总量和变化情况等要素来形成专项的技术方案。一些特殊场景需要客户购买额外的专项定制服务或者直接采购商业化工具。此外，对于AWS RDS的MySQL实例，Maxwell’s daemon这样的同步工具也很适用。
源系统导出的文件形式的离线数据：比如预先定义交换协议的文件（包含数据内容和描述信息）、Parquet格式的文件、系统生成的CSV格式文件等。
Toolkit在这里会创建一个Spark运行环境，根据预先定义的规则校验数据。校验通过后将数据内容转换成Parquet格式文件，生成的元数据的可以转换成Hive元数据并自动注册。
源系统通过消息队列提供的实时数据：包括Kafka、Kinesis数据源等。对外部系统提供的Kafka数据集成方法是，将消费者程序注册运行在AWS ECS中，消费程序解析后的数据立即写入Kinesis，通过Kinesis Firehose把数据给到S3存储归档。此时EMR中运行的Spark Streaming或者Flink程序可以直接读取Kinesis Stream中的数据进行流处理。
这样设计的好处在于，当外部系统提供的某一类型数据的源头是多个Kafka集群时，由ECS中的consumer程序作为缓冲统一收集数据，会减少后端侧重业务逻辑处理的实时程序实现和运维的复杂度。
API数据源：通过AWS Lambda实现对API的调用，将获取到的数据按照规则组装并形成Parquet格式文件写入S3中存储。
2. 数据存储
使用AWS S3将数据分层存储，是为了更好的组织、管理我们的数据资产，让我们的数据体系更有序，使得数据有清晰的结构、减少重复的开发、提供统一的数据口径，复杂的问题简单化（拆解任务，每一层处理特定的问题）：
原始数据集（Raw Data）：所有对象数据，包括视频、音频等二进制数据
有业务价值的数据（Golden Warehouse Data）：离线或实时计算结果集
直接面向分析的数据（OLAP Cube Data）：Kyligence Enterprise维度建模结果集
针对部分业务价值高、或者重要度高的数据采用了版本控制进行保护。
使用AWS S3 Glacier，存储价值密度低和Golden Data中的冷数据，相当一部分Raw Data和历史久远的Golden Warehouse Data中的明细数据通过数据生命周期管理机制会被识别成冷数据，将冷数据归档可以显著降低数据存储的成本。
使用AWS RDS，存储应用程序的元数据（metadata）
3. 数据计算
Kyligence 团队使用AWS EMR作为数据处理的计算平台，由于加工前的数据和加工后数据结果集都保存在S3存储中，所以平台很自然的做到了计算与存储分离。
平台大部分时间是依赖EMR自身的监控和策略实现集群规模的Auto-Scaling，而当这些策略无法满足实际需要时，我们采用自定义策略进行Scale Out或Scale In。而能够做到这些的基础是，我们在云上数据湖用到的云资源以及定制化服务，无论是创建、启停、配置、相互集成，都是通过Terraform进行了脚本化实现。
针对离线批和实时流两类场景，目前有多套数据处理Pipeline和运用过程中需要遵循的标准与规范：
批量数据处理
使用Kettle作为ETL工具，使用Hive SQL，以Hive Job的形式提交到EMR中进行计算
直接向EMR集群提交Spark Job。其中对于Spark SQL类型的任务，通过定制Toolkit支持申请一次资源执行一套脚本
流式数据处理
可以将Spark Streaming或Flink作为流处理的实现框架，建议所有外部流统一进入Kinesis，流处理程序会直接消费Kinesis Stream中的数据
4.平台安全
围绕平台安全的建设是持续且多方面的，在我们方案中，保障平台安全可以拆分成五个维度来实施，包括：
保障网络的安全
保障云资源的安全
保障PaaS服务的安全（例如保障EMR中众多应用）
保障有Web服务的应用的安全
保障数据的安全
针对上述每一个维度，我们又再次进行了拆分。以保障数据安全为例，我们进一步将其拆分成保障下列过程的安全：
数据在集成过程中的安全
数据存储后日常运维过程中的安全
发现数据和探索数据时的安全
数据在开发和建模过程的安全
数据被下游系统或业务用户使用时的安全
在实施过程中，我们主要通过以下手段来完成上述工作：1. 为将云数据湖运营中相关的安全流程与客户现有流程、规定、IT系统相结合，我们进行：
熟悉客户现有的信息安全尤其是数据安全相关规定和流程
熟悉客户现有的IT流程系统中有关数据安全相关的功能
2. 按照四大属性十二个角色，将与数据湖有关的实体对号入座：
3. 根据客户实际情况，制定平台安全运营核心章程，例如：
数据集成、数据治理、权限管理、数据开发评审是数据湖良好运营的基础
平台外部人员仅可以通过外部程序、工具以及特定的通道访问数据湖的功能及数据
平台外部程序或者工具通过双重验证的方式、经加密协议的方式、跳板的方式访问数据湖平台的功能数据
数据开发团队作为平台外部人员能够将数据湖作为数据基础设施使用，可以进行数据处理、建模，但开发方式及过程管理必须遵循数据湖规定和标准
平台外部产生的程序在平台中安装部署需要遵循DevOps流程
4. 按照我们从实际经验中总结的经验和公有云厂商的最佳实践指导，借助标准的云资源安全组件和我们标准化方案中提供的产品或组件来进一步完善安全配置：
在基于AWS构建云数据湖过程中，我们在VPC、Subnet总体框架下，按照角色划分时得到的实体关系，配置Security Group、ACL规则控制网络策略，并使用IAM管理对云资源的访问。
使用AD进行用户和角色管理。打通外部AD和内部AD，按照角色划分得到的实体关系，在内部AD中划分角色和组，作为管理应用权限和数据权限的基础。
启用安全模式机制管理PaaS服务的安全，例如启用EMR的Kerberos模式
使用Ranger等三方工具，通过Ranger来进行Hive、S3访问时的数据权限控制
其他方面
采用资源编排工具Terraform，将基础设施所有的操作和配置脚本化，使得复杂的云基础设施部署简单化
良好的平台运营监控，通过AWS提供的监控组件、客户购买的第三方工具以及任务调度工具，我们能够实现对以下资源的监控和告警：
基础资源的运营监控
数据应用的运营监控
日常数据处理程序的运营监控
协助客户将云上数据湖运营融入日常IT流程并符合相关规范，包括敏捷开发和DevOps自动化流程
项目价值
云数据湖平台的成功搭建和运营，帮助客户进一步强化了端到端利用大数据价值的能力，让数据变现有了更强的技术平台支撑。其最大价值在于可以帮助用户明确数据接入、存储到汇聚的全过程，更加清晰地了解数据的全生命周期，有效的进行数据拉通，解决数据孤岛问题，有利于数据价值的探索发现，结合着云数据湖平台的技术架构和运营方式能够随需求实时的做出调整和优化，这也鼓励了客户业务部门积极利用平台建设创新型业务场景。
目前项目团队和客户信息部门一起，逐步完成车联网数据的积累并完善平台+数据一体化运营流程，在流程合规、数据安全的前提下，将车联网数据与业务系统中数据相结合，支撑业务部门探索更多场景。不久前，业务部门已完成首例实践，通过车机端用户行为相关数据与内部客户关系数据集结合建模，辅助售后服务部门更有效触达车主需求，提高车主对随车服务的粘性。
随着数据类型及数据量的几何式增长，数据湖很容易变成一个缓慢、僵化的数据沼泽，这在数据质量和治理方面发出危险的信号。我们需要持续优化数据，确保数据得到治理，不会任由数据处于最原始状态，将数据在语义层上保持一致，并且能够满足用户分析需求。数据治理的同时我们也要保障数据的质量及数据的安全，这也是今后我们在云上数据湖的应用中需要侧重探索的方向。让平台更加智能，激活数据资源价值，提升数据应用能力。
网友评论