cys866
作者cys8662018-05-08 14:56
业务部门经理, 上海优铭云计算有限公司

基于Spark的数据湖项目初步实践

字数 4647阅读 4790评论 1赞 7

数据湖项目的可行性

a)数据湖技术

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

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

图片1.png

图片1.png

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

b)数据/信息服务业的需求

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

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

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

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

c)面临的挑战

由于历史原因,原有的数据架构是基于数据仓库的思路建设的,由多个数据源,形式上有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的处理方式进行优化,是直观的选择。

d)数据湖带来的好处

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

首先,解决面临的性能问题和瓶颈;
其次,将核心数据库转化成为集群化的架构,提高可用性和扩展性;
第三,有机会解决前端应用和后端开发的紧密耦合模式,可以以Spark的高速计算能力,前端改造成为灵活查询模式,取代前端、ETL过程、二次处理过程的三段式开发模式。

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

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

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

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

从IT部门的角度来说,可以带来以下几个方面的好处:
第一、将单点、双机模式改成集群模式,提高了可用性和扩展性;
第二、以开源架构取代商业架构,为节约成本铺平道路;
第三、Spark集群的扩展性,以及在各种业务上的适应性,可以为今后其他业务的建设提供平台,或者参照系;
第四、对于IT运维人员来说,Spark集群的容错能力、扩展性,毫无疑问是最大的价值,降低运维的压力,提高可用性,都是最好的帮助。

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

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

e)项目风险预测和规避措施

由于没有太多的行业经验可以借鉴,可以预料的风险可能是以下几个方面:
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运维团队抽调人员主持,学习和实践,积累知识和经验。

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

f)项目预算

根据初步的策划,项目的全部成本由如下几个部分构成:
1.硬件成本,包括X86服务器、交换机、安全设备等等。
2.软件成本,Spark/hadoop软件,如果采用商业版的话,需要成本支出;
3.培训成本
4.专业服务成本(包括数据迁移、现有的处理脚本系统的迁移、新业务上线的数据开发传帮带服务等等)
5.维保服务成本
设备规划10-20台X86服务器以及配套的交换机、安全设备等,总的资源成本估算约200~300万,运维成本估算约为15~20%。

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

g)关键技术路线选型

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

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

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

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

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

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

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

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

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论1 条评论

#wuwenpin软件开发工程师, 南京
2018-05-08 22:54
感谢分享!
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30