数据湖 VS 传统数据仓库→ 基于 Spark 的数据湖项目实践

Posted 2021-04-24 twt企业IT社区

原题：《基于Spark的数据湖项目初步实践》

由于历史原因，基于传统的数据仓库的建设思路的架构，现在带来了很大的问题和挑战。采用Spark/Hadoop架构，改造成数据湖的处理模式，将ETL过程改造成为利用MR的处理方式进行优化，是直观的选择。那么该项目的好处有哪些，可预测的风险是什么，关键技术路线如何选型？

一、数据湖技术

大数据的出现，以及大数据处理平台Hadoop架构的出现，催生了数据湖的产生。最初数据湖的概念是2011年首先出现的，可以说，就像数据仓库是处理结构化数据的过程一样，数据湖是Hadoop用于处理大数据，包含结构化数据，非结构化数据的过程。虽然使用的技术和平台不同，但是在数据的处理过程上来讲，数据湖和数据仓库要完成的使命是类似的，不过，虽然数据湖在业界还没有明确的定义，但是在多个方面，被认为比数据仓库更有优势。

下图是基于数据湖的技术架构示意图：

从中可以发现，从架构上看，数据湖就是建立在比较成熟的Hadoop技术体系之上、满足数据存储、数据集成、数据计算和数据查询功能的一个平台。和数据仓库的目的一样，它也是为了数据的OLAP、BI分析、数据挖掘、展现等需求而存在的。

二、数据/信息服务业的需求

数据/信息服务业的数据湖项目，是为了解决几个内部大数据处理的需求而提出的。

首先是数据的存储，或者叫数据的容纳，一，是将来自各个方面的数据源的流入数据，以便于访问的方式存储起来；二，也要是存储数据加工工艺流程中的中间数据的平台，三，也要存储数据处理的最终产品-数据资产的存储平台；

其次，数据湖也应是一个数据处理、数据计算的平台，可以将流入的数据，根据业务分析的需求进行清洗、补缺、关联、衍生计算等操作，生成满足业务需求的基准要求的生产原料数据，也就是说，数据湖的平台要具有强大的数据处理和数据计算能力；

第三，数据湖产生的数据资产，是为业务，比如大数据分析、AI量化交易、机器人写稿等使用的，存在对数据的多租户、多颗粒度的访问需求，以及面临失窃、受损等风险，需要安全系统的保护和访问的控制；也就是数据湖应该有一个安全访问的体系架构和目标；

三、面临的挑战

由于历史原因，原有的数据架构是基于数据仓库的思路建设的，由多个数据源，形式上有oracle、mysql、db2，甚至是text文件、excel文件等，通过ETL系统，将这些系统的数据抽取、转换并汇集到核心的oracle数据库中。中间经过了大量的映射、关联、合并以及分析计算等操作过程形成了所谓的“中心数据库”，由于“中心数据库”中的数据，并非应用可以直接访问和直接引用的数据，又使用大量的批处理脚本（简称为二次计算过程），将中心数据库中的大量数据定期或者触发的方式，再进行加工、计算处理成终端可访问的数据，支持应用的访问。

这种架构是传统的数据仓库的建设思路的结果，也给我们带来了很大的问题和挑战。

挑战之一就是，ETL过程和二次计算过程对数据库带来了很大的数据库压力，导致系统运行速度非常慢，举例来说最大的一个处理脚本，处理异常要8000秒以上。当前数据量还不算很大，这个问题可以通过数据库优化加以调整，但是今后如果流入的数据量骤增，这种问题依然会出现，因为这是RDBMS系统的技术基因所决定的。

挑战之二是，这种基于传统数据库的架构，非常难以拓展处理能力，并且形成了整个数据处理流程中的瓶颈和单点，经常发生应用访问数据为空、机器人写稿没有数据的现象发生；

挑战之三就是，这种静态计算的模式，带来了应用开发的前后耦合非常大，一个前端界面的开发，需要后端数据两个处理过程编制大量的大型SQL处理脚本，同时由于开发团队对业务的理解不够，导致研发非常耗时耗力，进度非常缓慢。

基于对以上几个现实的问题，直接的想法就是分析现有处理过程的实现方式，有针对性地设计解决方案。

首先，ETL过程和二次计算过程都是大规模的SQL语句处理。规模最大的SQL在1000行左右，关联表的行数在3亿500万500万的规模，执行方式都是定时、或者触发制性的批处理；由于SQL是业务部门通过ETL界面设计的，存在大量的字段级子查询、分析计算和聚合计算等嵌套计算；

其次、性能慢的主要原因是oracle处理以上模式的计算的能力不住，需要大量的调优工作。由于脚本数量很大，在数千个以上，逐个进行SQL级别的调优是不现实的。

第三、单点问题和提升计算能力问题，需要集群模式解决；

根据以上分析，采用Spark/Hadoop架构，改造成数据湖的处理模式，将ETL过程改造成为利用MR的处理方式进行优化，是直观的选择。

四、数据湖带来的好处

根据综合的分析，数据湖的项目可以为我们带来以下几个好处：

首先，解决面临的性能问题和瓶颈；

其次，将核心数据库转化成为集群化的架构，提高可用性和扩展性；

第三，有机会解决前端应用和后端开发的紧密耦合模式，可以以Spark的高速计算能力，前端改造成为灵活查询模式，取代前端、ETL过程、二次处理过程的三段式开发模式。

由于技术团队是源自数据库和数据仓库的，对Spark的应用经验不足，缺乏认识，可能后期还存在其他好处，需要我们在应用中尝试和探索。

同时，这个项目对于公司的价值是不言而喻的。数据是我们的业务的核心产品，也是我们传递价值的载体，数据的及时性、完整性和全面性，都有赖于这个处理平台的能力的提高，可以说，数据湖的项目会帮助企业提升数据的质量和价值，也提升企业的价值。

比如说，数据的准确率，是数据的核心价值之一。数据源的数据质量一般是较差的，是存在各种各样的问题，需要数十个、上百个脚本的处理，今后可能还会更多，可能由几千个脚本的处理，也就是通过上千个规则的约束，才能达到错误率的标准。

提高数据平台的处理能力，确保这么多的规则的定时完成和实现。对于客户而言，及时地提供这些正确的数据无比重要，面对大型的投资机构，这个问题无比重要。

从IT部门的角度来说，可以带来以下几个方面的好处：

第一、将单点、双机模式改成集群模式，提高了可用性和扩展性；

第二、以开源架构取代商业架构，为节约成本铺平道路；

第三、Spark集群的扩展性，以及在各种业务上的适应性，可以为今后其他业务的建设提供平台，或者参照系；

第四、对于IT运维人员来说，Spark集群的容错能力、扩展性，毫无疑问是最大的价值，降低运维的压力，提高可用性，都是最好的帮助。

另外，对于IT团队来说，也可以让IT运维人员有机会接触最新的技术和应用，对于团队的能力提高也是有益的。

当然，对于他们而言，Spark是个新鲜事物，需要他们从头学习，在这方面是由压力的，但是技术团队有很高的积极性，这方面不是太大的问题。

五、项目风险预测和规避措施

由于没有太多的行业经验可以借鉴，可以预料的风险可能是以下几个方面：

1.对原有系统的研发成果的衔接，也就是说Spark对原有的复杂SQL语句的兼容性，是否可以解决性能问题；

2.Spark平台对数据的管理能力，是否满足业务方可以直接查找数据、在线设计SQL查询、提交查询的功能；是否支持前端应用的动态查询开发模式；

3.数据开发团队需要由ETL、定制开发的数据处理界面转向Spark平台开发的问题，是否会产生太大的再学习成本

4.市场技术供应问题，是否存在合适的大数据技术公司满足我方的需求；

5.IT团队对Spark技术不了解，处于表面的程度，没有建设经验和管理经验；

这些风险如果不加以避免，可能会给我们带来项目上的损失：

1.如果Spark中的Spark SQL组件不能很好兼容现有的大量SQL处理脚本，或者对这些SQL的处理性能提升不够，将直接导致这个项目的失败；

2.如果Spark中不能提供元数据管理功能，以及用户在线分析查询处理的界面，导致数据湖对开发部门和数据业务部门成为一个黑箱，无法利用，项目也会失败；

3.数据处理开发方式如果差异很大，将带来很长的学习和适应时间，严重影响研发进度，项目也会失败；

4.如果没有合适的大数据技术公司供应，项目无法进行下去；

5.IT运维团队能力不足，如果Spark平台难以管理，或者需要大量的人力投入，也会造成平台的故障频发而影响使用，直接影响应用开发和业务上线。

对于这些风险的存在，我们能想到的最好的管理应对措施，就是拿出一条实际的业务应用，邀请大数据技术公司进行PoC，将这些重大风险一一进行测试和检验，同时由IT运维团队抽调人员主持，学习和实践，积累知识和经验。

对于后期管理的问题和风险，可以在立项采购时，规划充分的培训、专业实施服务、维保服务以及定制开发服务等等加以避免。

六、项目预算

根据初步的策划，项目的全部成本由如下几个部分构成：

1.硬件成本，包括X86服务器、交换机、安全设备等等。

2.软件成本，Spark/hadoop软件，如果采用商业版的话，需要成本支出；

3.培训成本

4.专业服务成本（包括数据迁移、现有的处理脚本系统的迁移、新业务上线的数据开发传帮带服务等等）

5.维保服务成本

设备规划10-20台X86服务器以及配套的交换机、安全设备等，总的资源成本估算约200~300万，运维成本估算约为15~20%。

为了控制项目预算，我们采用了先PoC再编制预算的方法。在PoC中要充分、完整，把风险点都测试到位，可以先用PC机搭建测试系统，进行采购前上业务运行。同时项目预算的方式要着眼于小规模起步建设、成功后再立项采购的路子，同时，积极为多个厂商创造公平竞争的环境，设计公平技术指标，方便他们发挥各种的技术和价格优势。此外，严格控制采购的规模，采购最小功能子集，严格把关，杜绝华而不实的软件模块需求。

在PoC的过程中，团队中培养2个技术负责人、从前到后掌握技术、建设和运维工作要点。

七、关键技术路线选型

从本质上讲，所属企业建设数据湖的目的在于提供数据的存储平台、加工处理平台、数据挖掘、分析处理平台。

其他的技术路线包括构建数据仓库。但是数据仓库的缺点在于，数据模型的构建是数据处理工作流的瓶颈。很多数据仓库项目失败于构建数据模型的时间太长、效率太低，当数据模型建设好了，前端的数据分析很可能已经发生了改变，上游的数据生产系统也发生了改变，导致数据模型永远落后于数据分析化为数据挖掘业务的需要。

另外一个常见的问题是，数据仓库的运行效率差，报表生产的时间过程实际时间比预测时间普遍要长。

由于非结构化数据的爆炸式增长，而且越来越多的原始数据根植于非结构化的各种文件、图片、音频、视频文件中，数据仓库作为结构化的数据分析处理平台，在数据的获取这个阶段，就面临越来越大的困难，为数据集成带来很大的难度。

以Spark/Hadoop集群作为平台，天然可以接纳各种各样的数据源的格式，不仅结构化数据、非结构化数据也可以直接载入。通过各种数据的处理程序，可以处理几乎各种数据的集成问题，也可以避免不必要的数据从非结构化到结构化的转换需要，只要具备处理的数据接口即可处理海量的数据，对数据格式的要求降低；

同时，由于Spark/Hadoop对海量数据的处理能力的提升，加之集群处理能力和节点个数的线性关系，可以以计算能力取代建模，做到查询中建模，或者叫临时自动化建模，改变了原有的先建模后查询的模式，变成了可以实现随时查询、按需建模的模式，可以避免数据仓库项目周期长、见效慢、需求变化快导致脱节的诸多问题。

也就是说，数据湖的平台具备强大的、可弹性扩展的计算力，是一个成功的关键，因此，放弃传统的单数据库或者单数据仓库架构，放弃单机系统、一体机系统，转向Hadoop/Spark平台，是一个自然的选择。

在Spark技术方面，国内外都有成熟的技术。在本次项目中，我们邀请了中兴飞流、星环以及Cloudra都进行了PoC，都取得了比较好的效果。

更多相关内容，请点击阅读原文