2018-03-22 14:12:14 bingdata123 阅读数 1744

1、金融企业大数据平台架构设计的关键点有哪些?

架构设计的关键首要是要满足业务需求,提炼业务需求的非功能特性,提出针对性的架构设计方案。作业自主研发能力有限的企业,在大数据系统建设中首要是合理的选择技术组件,如果科技力量更强可以考虑参与开源社区对组件的优化完善等工作中。

2、针对结构化、半结构化和非结构化的数据,在设计大数据平台中分别有哪些要点?

大数据平台最好存储与计算相关的数据,非结构化数据如果不能利用分布式计算能力就不建议在hadoop这类平台上存储,可以考虑其他的分布式存储方案。结构化和半结构化差别不多,考虑具体应用场景和数据使用模式来制定方案。

3、大数据平台如何对大规模流数据加工封装,以及实现内容分发?

流计算框架主流的是SparkStreaming/Storm两种,其他的还有Heron/Flink等等。流数据加工通常涉及到数据的分发订阅,Kafak是目前比较流行的分布式消息系统。

4、大数据平台可以做到对客联机的联机高可用查询要求吗?

基于HBase可以满足联机交易的查询请求,Impala也可以满足一定程度上的联机查询对接BI报表工具。不过还要看具体场景的要求详细分析。

5、应该怎么规划数据库架构?多大的数据量用什么样的架构,有没有一个比较好的规划策略。

1、小规模的使用,可以分散建设应用集群,灵活度高。

2、没有发展自身技术团队打算的,可以找靠谱的集成商。

3、有长远打算的,建议做平台的整体规划。

数据量的问题,通常超过TB级别可以考虑大数据技术或其他MPP,低于这个数量级RDB完全可以搞定。

6、大数据平台元数据管理问题有哪些考量点?

元数据管理还不是开源社区的重点发展方向,在一些商业版中有部分功能支持,如果想要一个更完善的方案还需要基于自身情况来定制。

很多企业只关注大数据,对元数据的管理方面很不到位,同样指标几十个不同名称,带来数据质量问题跟沟通问题。简单的管理可以基于业务,纬度方面给表字段命名,

7、非结构化数据,如语音,视频 在大数据环境下怎样才能合理存放,以利于数据的调取使用?

语音与视频数据的问题,要结合该类数据的使用方式来判断。具备计算能力的存储其成本要更高,如果仅仅为了存储可以先考虑其他分布式存储方案如CEPH等。

语音和视频涉及到语音识别和计算机视觉等技术领域,如语音识别文字等处理目前尚未了解到其是否能够基于Hadoop等并行处理框架实现,如果存在类似方案则可以考虑在Hadoop上集中存储。

8、如果没有从来源上保障数据质量,后续的利用和挖掘也就步履维艰,有哪些保障大数据的数据质量的方法?

实践中,数据质量始终是一个不容易解决的问题,这是因为良好的数据质量必然依赖于一个技术与管理相互结合的方案,要在企业范围内有统一的制度和充分落地的执行。大数据技术被没有提供更好的解决方案,因为开源社区似乎没有将其作为重点的关注方向,甚至在配套的元数据管理等方面还稍逊于传统的商业产品。目前阶段,大数据应用还处于一个离散化的状态,完全现面向应用建设,没有像传统EDW那样形成完整的企业数据模型体系。毕竟大数据的应用模式还在不断探索的阶段,谈论这类强约束的模型还为时过早,个人认为这种状态估计还会持续相当长的一段时间。此外大量外部数据的引入,也对传统的基于封闭体系、强调源头管理的数据质量管理理论提出了挑战,降低噪音提取有价值的信息,会成为大数据应用的一个常态,不再是辅助流程,要在系统设计过程中予以考虑。最后,如何控制数据质量,还要平衡其成本和收益。

9、拟计划将不同物理地的数据进行物理集中,面对海量数据如何进行数据迁移和集中,且不影响应用正常使用?

基于Hadoop搭建的大数据系统,要做到大量数据迁移,过程中不影响正常使用是非常困难的。

因为HDFS作为底层存储是要将数据分块而后尽量均匀的分布在集群的各个节点上,默认三副本策略是如果远端调用接口则第1份部分可保存任意节点,第2份保存在同一机架的节点上,第3份则在不同机架上节点。

短时间内持续的大量写入数据会对集群中众多节点产生影响,占用磁盘IO和网络IO。此时如果集群同时支持HBase这样的联机查询或写入服务,则会产生较大的影响。即使是批量数据处理操作,也同样存在竞争影响其服务处理时间。

如果确实无法停止服务,建议选择系统服务压力较小的特定时间窗口完成迁移数据的加载。

10、依托hadoop等多个开源框架可以搭建并使用大数据库平台,但是由于各个应用系统的数据量等实际情况,如何实现不同应用之间的租户管理,并实现资源的合理控制呢?

多租户管理是目前大数据技术发展中不断强化的一个重要特性,主要落脚点在安全管理和资源管理上。Hadoop1.0到2.0引入的Yarn就是解决资源管理问题,改变1.0下简单的资源竞争模式。此外一些技术组件如HBase/Kafka都在丰富其安全和资源管理方面的能力。

Bingdata优网助帮汇聚多平台采集的海量数据,通过大数据技术的分析及预测能力为企业提供智能化的数据分析、运营优化、投放决策、精准营销、竞品分析等整合营销服务。

北京优网助帮信息技术有限公司(简称优网助帮)是以大数据为基础,并智能应用于整合营销的大数据公司,隶属于亨通集团。Bingdata是其旗下品牌。优网助帮团队主要来自阿里、腾讯、百度、金山、搜狐及移动、电信、联通、华为、爱立信等著名企业的技术大咖,兼有互联网与通信运营商两种基因,为大数据的算法分析提供强大的技术支撑。

 

 

 

2019-12-23 10:24:38 vivo_tech 阅读数 79

本文首发于 vivo互联网技术 微信公众号 
链接:https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA
作者:刘延江

近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据,大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题,本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。

本文主要包括以下几个章节:

  1. 本文第一部分介绍一下大数据基础组件和相关知识。

  2. 第二部分会介绍lambda架构和kappa架构。

  3. 第三部分会介绍lambda和kappa架构模式下的一般大数据架构

  4. 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。

  5. 第五部分介绍优秀的大数据架构整体设计

  6. 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能,让业务开发不在畏惧复杂的数据开发组件,无需关注底层实现,只需要会使用SQL就可以完成一站式开发,完成数据回流,让大数据不再是数据工程师才有的技能。

一、大数据技术栈

大数据整体流程涉及很多模块,每一个模块都比较复杂,下图列出这些模块和组件以及他们的功能特性,后续会有专题去详细介绍相关模块领域知识,例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。

二、lambda架构和kappa架构

目前基本上所有的大数据架构都是基于lambda和kappa架构,不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性,也对硬件故障和人为失误有很好的容错性,关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系,从而带来的各种成本问题,这也是目前流批一体化研究方向,很多企业已经开始使用这种更为先进的架构。

Lambda架构

Kappa架构

三、kappa架构和lambda架构下的大数据架构

目前各大公司基本上都是使用kappa架构或者lambda架构模式,这两种模式下大数据整体架构在早期发展阶段可能是下面这样的:

四、数据端到端痛点

虽然上述架构看起来将多种大数据组件串联起来实行了一体化管理,但是接触过数据开发的人会感受比较强烈,这样的裸露架构业务数据开发需要关注很多基础工具的使用,实际数据开发中存在很多痛点与难点,具体表现在下面一些方面。

  1. 缺乏一套数据开发IDE来管理整个数据开发环节,长远的流程无法管理起来。

  2. 没有产生标准数据建模体系,导致不同数据工程师对指标理解不同计算口径有误。

  3. 大数据组件开发要求高,普通业务去直接使用Hbase、ES等技术组件会产生各种问题。

  4. 基本上每个公司大数据团队都会很复杂,涉及到很多环节,遇到问题难以定位难以找到对应负责人。

  5. 难以打破数据孤岛,跨团队跨部门数据难以共享,互相不清楚对方有什么数据。

  6. 需要维护两套计算模型批计算和流计算,难以上手开发,需要提供一套流批统一的SQL。

  7. 缺乏公司层面的元数据体系规划,同一条数据实时和离线难以复用计算,每次开发任务都要各种梳理。

基本上大多数公司在数据平台治理上和提供开放能力上都存在上述问题和痛点。在复杂的数据架构下,对于数据适用方来说,每一个环节的不清晰或者一个功能的不友好,都会让复杂链路变更更加复杂起来。想要解决这些痛点,就需要精心打磨每一个环节,将上面技术组件无缝衔接起来,让业务从端到端使用数据就像写SQL查询数据库一样简单。

五、优秀的大数据整体架构设计

提供多种平台以及工具来助力数据平台:多种数据源的数据采集平台、一键数据同步平台、数据质量和建模平台、元数据体系、数据统一访问平台、实时和离线计算平台、资源调度平台、一站式开发IDE。

六、元数据-大数据体系基石

元数据是打通数据源、数据仓库、数据应用,记录了数据从产生到消费的完整链路。元数据包含静态的表、列、分区信息(也就是MetaStore)。动态的任务、表依赖映射关系;数据仓库的模型定义、数据生命周期;以及ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据构建任务、表、列、用户之间的数据图谱;构建任务DAG依赖关系,编排任务执行序列;构建任务画像,进行任务质量治理;提供个人或BU的资产管理、计算资源消耗概览等。

可以认为整个大数据数据流动都是依靠元数据来管理的,没有一套完整的元数据设计,就会出现上面的数据难以追踪、权限难以把控、资源难以管理、数据难以共享等等问题。

很多公司都是依靠hive来管理元数据,但是个人认为在发展一定阶段还是需要自己去建设元数据平台来匹配相关的架构。

关于元数据可以参考饿了么一些实战:https://www.jianshu.com/p/f60b2111e414

七、流批一体化计算

如果维护两套计算引擎例如离线计算Spark和实时计算Flink,那么会对使用者造成极大困扰,既需要学习流计算知识也需要批计算领域知识。如果实时用Flink离线用Spark或者Hadoop,可以开发一套自定义的DSL描述语言去匹配不同计算引擎语法,上层使用者无需关注底层具体的执行细节,只需要掌握一门DSL语言,就可以完成Spark和Hadoop以及Flink等等计算引擎的接入。

八、实时与离线ETL平台

ETL 即 Extract-Transform-Load,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL 一词较常用在数据仓库,但其对象并不限于数据仓库。一般而言ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面有很重要作用。作为重要的数据清洗中间层,一般而言ETL最起码要具备下面几个功能:

  1. 支持多种数据源,例如消息系统、文件系统等

  2. 支持多种算子,过滤、分割、转换、输出、查询数据源补全等算子能力

  3. 支持动态变更逻辑,例如上述算子通过动态jar方式提交可以做到不停服发布变更。

九、智能统一查询平台

大多数数据查询都是由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用,这种模式在大数据体系下存在很多问题:

  1. 这种架构简单,但接口粒度很粗,灵活性不高,扩展性差,复用率低.随着业务需求的增加,接口的数量大幅增加,维护成本高企。

  2. 同时,开发效率不高,这对于海量的数据体系显然会造成大量重复开发,难以做到数据和逻辑复用,严重降低业务适用方体验。

  3. 如果没有统一的查询平台直接将Hbase等库暴露给业务,后续的数据权限运维管理也会比较难,接入大数据组件对于业务适用方同样很痛苦,稍有不慎就会出现各种问题。

通过一套智能查询解决上述大数据查询痛点问题

十、数仓建模规范体系

随着业务复杂度和数据规模上升,混乱的数据调用和拷贝,重复建设带来的资源浪费,数据指标定义不同而带来的歧义、数据使用门槛越来越高。以笔者见证实际业务埋点和数仓使用为例,同一个商品名称有些表字段是good_id,有些叫spu_id,还有很多其他命名,对于想利用这些数据人会造成极大困扰。因此没有一套完整的大数据建模体系,会给数据治理带来极大困难,具体表现在下面几个方面:

  1. 数据标准不一致,即使是同样的命名,但定义口径却不一致。例如,仅uv这样一个指标,就有十几种定义。带来的问题是:都是uv,我要用哪个?都是uv,为什么数据却不一样?

  2. 造成巨大研发成本,每个工程师都需要从头到尾了解研发流程的每个细节,对同样的“坑”每个人都会重新踩一遍,对研发人员的时间和精力成本造成浪费。这也是目标笔者遇到的困扰,想去实际开发提取数据太难。

  3. 没有统一的规范标准管理,造成了重复计算等资源浪费。而数据表的层次、粒度不清晰,也使得重复存储严重。

因此大数据开发和数仓表设计必须要坚持设计原则,数据平台可以开发平台来约束不合理的设计,例如阿里巴巴的OneData体。一般而言,数据开发要经过按照下面的指导方针进行:

有兴趣的可以参考阿里巴巴的OneData设计体系。

十一、一键集成平台

很简单的就能将各种各式数据一键采集到数据平台,通过数据传输平台将数据无缝衔接到ETL平台。ETL通过和元数据平台打通,规范Schema定义,然后将数据转换、分流流入到实时与离线计算平台,后续任何针对该数据离线和实时处理,只需要申请元数据表权限就可以开发任务完成计算。数据采集支持多种各式数据来源,例如binlog、日志采集、前端埋点、kafka消息队列等

十二、数据开发IDE-高效的端到端工具

高效的数据开发一站式解决工具,通过IDE可以完成实时计算与离线计算任务开发,将上述平台全部打通提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务,一站式开发管理的界面,通过数据IDE完成对数据进行传输、转换和集成等操作。从不同的数据存储引入数据,并进行转化和开发,最后将处理好的数据同步至其他数据系统。通过高效率的大数据开发IDE,基本上让大数据工程师可以屏蔽掉各种痛点,将上述多种平台能力结合起来,让大数据开发可以向写SQL一样简单。

关于数据开发工具可以参考阿里云的DataWorks

解决端到端难点还需要其他若干能力辅助,这里就不再叙述,有兴趣的同学可以自行研究。

十三、其他

完整的数据体系研发还包括告警与监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据加工体系,这里就不再继续讨论了。

更多内容敬请关注 vivo 互联网技术 微信公众号

注:转载文章请先与微信号:labs2020 联系。

2016-08-11 10:37:07 fengshulin_0521 阅读数 271

1. 软件架构设计

 

软件架构图

 

大数据平台架构设计沿袭了分层设计的思想,将平台所需提供的服务按照功能划分成不同的模块层次,每一模块层次只与上层或下层的模块层次进行交互(通过层次边界的接口),避免跨层的交互,这种设计的好处是:各功能模块的内部是高内聚的,而模块与模块之间是松耦合的。这种架构有利于实现平台的高可靠性,高扩展性以及易维护性。比如,当我们需要扩容Hadoop集群时,只需要在基础设施层添加一台新的Hadoop节点服务器即可,而对其他模块层无需做任何的变动,且对用户也是完全透明的。

整个拉卡拉大数据平台按其职能划分为五个模块层次,从下到上依次为:

运行环境层:

运行环境层为基础设施层提供运行时环境,它由2部分构成,即操作系统和运行时环境。

(1)操作系统我们推荐安装REHL5.0以上版本(64位)。此外为了提高磁盘的IO吞吐量,避免安装RAID驱动,而是将分布式文件系统的数据目录分布在不同的磁盘分区上,以此提高磁盘的IO性能。

(2)运行时环境的具体要求如下表:

 

名称 版本 说明

JDK

1.6或以上版本

Hadoop需要Java运行时环境,必须安装JDK

gcc/g++

3.x或以上版本

当使用Hadoop Pipes运行MapReduce任务时,需要gcc编译器,可选。

python

2.x或以上版本

当使用Hadoop Streaming运行MapReduce任务时,需要python运行时,可选。

 

 

基础设施层:

基础设施层由2部分组成:Zookeeper集群和Hadoop集群。它为基础平台层提供基础设施服务,比如命名服务、分布式文件系统、MapReduce等。

(1)ZooKeeper集群用于命名映射,做为Hadoop集群的命名服务器,基础平台层的任务调度控制台可以通过命名服务器访问Hadoop集群中的NameNode,同时具备failover的功能。

(2)Hadoop集群是大数据平台的核心,是基础平台层的基础设施。它提供了HDFS、MapReduce、JobTracker和TaskTracker等服务。目前我们采用双主节点模式,以此避免Hadoop集群的单点故障问题。

基础平台层:

基础平台层由3个部分组成:任务调度控制台、HBase和Hive。它为用户网关层提供基础服务调用接口。

(1)任务调度控制台是MapReduce任务的调度中心,分配各种任务执行的顺序和优先级。用户通过调度控制台提交作业任务,并通过用户网关层的Hadoop客户端返回其任务执行的结果。其具体执行步骤如下:

  • 任务调度控制台接收到用户提交的作业后,匹配其调度算法;
  • 请求ZooKeeper返回可用的Hadoop集群的JobTracker节点地址;
  • 提交MapReduce作业任务;
  • 轮询作业任务是否完成;
  • 如果作业完成发送消息并调用回调函数;
  • 继续执行下一个作业任务。

 

作为一个完善的Hadoop集群实现,任务调度控制台尽量自己开发实现,这样灵活性和控制力会更加的强。

(2)HBase是基于Hadoop的列数据库,为用户提供基于表的数据访问服务。

(3)Hive是在Hadoop上的一个查询服务,用户通过用户网关层的Hive客户端提交类SQL的查询请求,并通过客户端的UI查看返回的查询结果,该接口可提供数据部门准即时的数据查询统计服务。

用户网关层:

用户网关层用于为终端客户提供个性化的调用接口以及用户的身份认证,是用户唯一可见的大数据平台操作入口。终端用户只有通过用户网关层提供的接口才可以与大数据平台进行交互。目前网关层提供了3个个性化调用接口:

(1)Hadoop客户端是用户提交MapReduce作业的入口,并可从其UI界面查看返回的处理结果。

(2)Hive客户端是用户提交HQL查询服务的入口,并可从其UI界面查看查询结果。

(3)Sqoop是关系型数据库与HBase或Hive交互数据的接口。可以将关系型数据库中的数据按照要求导入到HBase或Hive中,以提供用户可通过HQL进行查询。同时HBase或Hive或HDFS也可以将数据导回到关系型数据库中,以便其他的分析系统进行进一步的数据分析。

用户网关层可以根据实际的需求无限的扩展,以满足不同用户的需求。

客户应用层:

客户应用层是各种不同的终端应用程序,可以包括:各种关系型数据库,报表,交易行为分析,对账单,清结算等。

目前我能想到的可以落地到大数据平台的应用有:

1.行为分析:将交易数据从关系型数据库导入到Hadoop集群中,然后根据数据挖掘算法编写MapReduce作业任务并提交到JobTracker中进行分布式计算,然后将其计算结果放入Hive中。终端用户通过Hive客户端提交HQL查询统计分析的结果。

2.对账单:将交易数据从关系型数据库导入到Hadoop集群,然后根据业务规则编写MapReduce作业任务并提交到JobTracker中进行分布式计算,终端用户通过Hadoop客户端提取对账单结果文件(Hadoop本身也是一个分布式文件系统,具备通常的文件存取能力)。

3.清结算:将银联文件导入HDFS中,然后将之前从关系型数据库中导入的POSP交易数据进行MapReduce计算(即对账操作),然后将计算结果连接到另外一个MapReduce作业中进行费率及分润的计算(即结算操作),最后将计算结果导回到关系型数据库中由用户触发商户划款(即划款操作)。

部署架构设计

部署架构图

 

关键点说明:

1.目前整个Hadoop集群均放置在银联机房中。

2.Hadoop集群中有2个Master节点和5个Slave节点,2个Master节点互为备份通过ZooKeeper可实现failover功能。每个Master节点共享所有的Slave节点,保证分布式文件系统的备份存在于所有的DataNode节点之中。Hadoop集群中的所有主机必须使用同一网段并放置在同一机架上,以此保证集群的IO性能。

3.ZooKeeper集群至少配置2台主机,以避免命名服务的单节点故障。通过ZooKeeper我们可以不再需要F5做负载均衡,直接由任务调度控制台通过ZK实现Hadoop名称节点的负载均衡访问。

4.所有服务器之间必须配置为无密钥SSH访问。

5.外部或内部用户均需要通过网关才能访问Hadoop集群,网关在经过一些身份认证之后才能提供服务,以此保证Hadoop集群的访问安全。

2020-03-20 13:41:43 mnbvxiaoxin 阅读数 38

近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据,大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题,本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。

本文主要包括以下几个章节:

  1. 本文第一部分介绍一下大数据基础组件和相关知识。

  2. 第二部分会介绍lambda架构和kappa架构。

  3. 第三部分会介绍lambda和kappa架构模式下的一般大数据架构

  4. 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。

  5. 第五部分介绍优秀的大数据架构整体设计

  6. 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能,让业务开发不在畏惧复杂的数据开发组件,无需关注底层实现,只需要会使用SQL就可以完成一站式开发,完成数据回流,让大数据不再是数据工程师才有的技能。

一、大数据技术栈

大数据整体流程涉及很多模块,每一个模块都比较复杂,下图列出这些模块和组件以及他们的功能特性,后续会有专题去详细介绍相关模块领域知识,例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。

 

 

二、lambda架构和kappa架构

目前基本上所有的大数据架构都是基于lambda和kappa架构,不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性,也对硬件故障和人为失误有很好的容错性,关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系,从而带来的各种成本问题,这也是目前流批一体化研究方向,很多企业已经开始使用这种更为先进的架构。想系统学习大数据的话,可以加入大数据技术学习扣扣君羊:522189307

 

Lambda架构

 

Kappa架构

 

三、kappa架构和lambda架构下的大数据架构

 

目前各大公司基本上都是使用kappa架构或者lambda架构模式,这两种模式下大数据整体架构在早期发展阶段可能是下面这样的:

 

四、数据端到端痛点

 

虽然上述架构看起来将多种大数据组件串联起来实行了一体化管理,但是接触过数据开发的人会感受比较强烈,这样的裸露架构业务数据开发需要关注很多基础工具的使用,实际数据开发中存在很多痛点与难点,具体表现在下面一些方面。

 

  1. 缺乏一套数据开发IDE来管理整个数据开发环节,长远的流程无法管理起来。

  2. 没有产生标准数据建模体系,导致不同数据工程师对指标理解不同计算口径有误。

  3. 大数据组件开发要求高,普通业务去直接使用Hbase、ES等技术组件会产生各种问题。

  4. 基本上每个公司大数据团队都会很复杂,涉及到很多环节,遇到问题难以定位难以找到对应负责人。

  5. 难以打破数据孤岛,跨团队跨部门数据难以共享,互相不清楚对方有什么数据。

  6. 需要维护两套计算模型批计算和流计算,难以上手开发,需要提供一套流批统一的SQL。

  7. 缺乏公司层面的元数据体系规划,同一条数据实时和离线难以复用计算,每次开发任务都要各种梳理。

基本上大多数公司在数据平台治理上和提供开放能力上都存在上述问题和痛点。在复杂的数据架构下,对于数据适用方来说,每一个环节的不清晰或者一个功能的不友好,都会让复杂链路变更更加复杂起来。想要解决这些痛点,就需要精心打磨每一个环节,将上面技术组件无缝衔接起来,让业务从端到端使用数据就像写SQL查询数据库一样简单。

五、优秀的大数据整体架构设计

提供多种平台以及工具来助力数据平台:多种数据源的数据采集平台、一键数据同步平台、数据质量和建模平台、元数据体系、数据统一访问平台、实时和离线计算平台、资源调度平台、一站式开发IDE。

 

六、元数据-大数据体系基石

元数据是打通数据源、数据仓库、数据应用,记录了数据从产生到消费的完整链路。元数据包含静态的表、列、分区信息(也就是MetaStore)。动态的任务、表依赖映射关系;数据仓库的模型定义、数据生命周期;以及ETL任务调度信息、输入输出等元数据是数据管理、数据内容、数据应用的基础。例如可以利用元数据构建任务、表、列、用户之间的数据图谱;构建任务DAG依赖关系,编排任务执行序列;构建任务画像,进行任务质量治理;提供个人或BU的资产管理、计算资源消耗概览等。

可以认为整个大数据数据流动都是依靠元数据来管理的,没有一套完整的元数据设计,就会出现上面的数据难以追踪、权限难以把控、资源难以管理、数据难以共享等等问题。

很多公司都是依靠hive来管理元数据,但是个人认为在发展一定阶段还是需要自己去建设元数据平台来匹配相关的架构。

七、流批一体化计算

如果维护两套计算引擎例如离线计算Spark和实时计算Flink,那么会对使用者造成极大困扰,既需要学习流计算知识也需要批计算领域知识。如果实时用Flink离线用Spark或者Hadoop,可以开发一套自定义的DSL描述语言去匹配不同计算引擎语法,上层使用者无需关注底层具体的执行细节,只需要掌握一门DSL语言,就可以完成Spark和Hadoop以及Flink等等计算引擎的接入。

八、实时与离线ETL平台

ETL 即 Extract-Transform-Load,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。ETL 一词较常用在数据仓库,但其对象并不限于数据仓库。一般而言ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面有很重要作用。作为重要的数据清洗中间层,一般而言ETL最起码要具备下面几个功能:

  1. 支持多种数据源,例如消息系统、文件系统等

  2. 支持多种算子,过滤、分割、转换、输出、查询数据源补全等算子能力

  3. 支持动态变更逻辑,例如上述算子通过动态jar方式提交可以做到不停服发布变更。

 

 

九、智能统一查询平台

 

大多数数据查询都是由需求驱动,一个需求开发一个或者几个接口,编写接口文档,开放给业务方调用,这种模式在大数据体系下存在很多问题:

  1. 这种架构简单,但接口粒度很粗,灵活性不高,扩展性差,复用率低.随着业务需求的增加,接口的数量大幅增加,维护成本高企。

  2. 同时,开发效率不高,这对于海量的数据体系显然会造成大量重复开发,难以做到数据和逻辑复用,严重降低业务适用方体验。

  3. 如果没有统一的查询平台直接将Hbase等库暴露给业务,后续的数据权限运维管理也会比较难,接入大数据组件对于业务适用方同样很痛苦,稍有不慎就会出现各种问题。

     

通过一套智能查询解决上述大数据查询痛点问题

 

十、数仓建模规范体系

随着业务复杂度和数据规模上升,混乱的数据调用和拷贝,重复建设带来的资源浪费,数据指标定义不同而带来的歧义、数据使用门槛越来越高。以笔者见证实际业务埋点和数仓使用为例,同一个商品名称有些表字段是good_id,有些叫spu_id,还有很多其他命名,对于想利用这些数据人会造成极大困扰。因此没有一套完整的大数据建模体系,会给数据治理带来极大困难,具体表现在下面几个方面:

 

  1. 数据标准不一致,即使是同样的命名,但定义口径却不一致。例如,仅uv这样一个指标,就有十几种定义。带来的问题是:都是uv,我要用哪个?都是uv,为什么数据却不一样?

  2. 造成巨大研发成本,每个工程师都需要从头到尾了解研发流程的每个细节,对同样的“坑”每个人都会重新踩一遍,对研发人员的时间和精力成本造成浪费。这也是目标笔者遇到的困扰,想去实际开发提取数据太难。

  3. 没有统一的规范标准管理,造成了重复计算等资源浪费。而数据表的层次、粒度不清晰,也使得重复存储严重。

 

因此大数据开发和数仓表设计必须要坚持设计原则,数据平台可以开发平台来约束不合理的设计,例如阿里巴巴的OneData体。一般而言,数据开发要经过按照下面的指导方针进行:

 

有兴趣的可以参考阿里巴巴的OneData设计体系。

十一、一键集成平台

很简单的就能将各种各式数据一键采集到数据平台,通过数据传输平台将数据无缝衔接到ETL平台。ETL通过和元数据平台打通,规范Schema定义,然后将数据转换、分流流入到实时与离线计算平台,后续任何针对该数据离线和实时处理,只需要申请元数据表权限就可以开发任务完成计算。数据采集支持多种各式数据来源,例如binlog、日志采集、前端埋点、kafka消息队列等

十二、数据开发IDE-高效的端到端工具

高效的数据开发一站式解决工具,通过IDE可以完成实时计算与离线计算任务开发,将上述平台全部打通提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务,一站式开发管理的界面,通过数据IDE完成对数据进行传输、转换和集成等操作。从不同的数据存储引入数据,并进行转化和开发,最后将处理好的数据同步至其他数据系统。通过高效率的大数据开发IDE,基本上让大数据工程师可以屏蔽掉各种痛点,将上述多种平台能力结合起来,让大数据开发可以向写SQL一样简单。

关于数据开发工具可以参考阿里云的DataWorks。

解决端到端难点还需要其他若干能力辅助,这里就不再叙述,有兴趣的同学可以自行研究。

十三、其他

完整的数据体系研发还包括告警与监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据加工体系,这里就不再继续讨论了。

2018-05-15 12:11:43 adnb34g 阅读数 480

大数据作为当下最为热门的事件之一,其实已经不算是很新鲜的事情了。如果是三五年前在讨论大数据,那可能会给人一种很新鲜的感觉。大数据作为当下最为重要的一项战略资源,已经是越来越得到国家和企业的高度重视,我们从大数据被上升到国家战略层面就可窥见一二!

现在关于大数据的知识分享可以说已经是铺天盖地了,作为新手入门想查询的信息基本都可以通过网络查询到一些。我对的大数据的了解其实也不是特别丰富,毕竟学习的时间也不是特别长。仅以我熟悉的DKhadoop为例给大家分享一些小知识,往对初学者有点小帮助就可以了。

大数据平台基础框架是很多初学者必然要掌握的内容,大数据太过抽象,有时候写分享的时候难免感觉写的很多困难。还是通过具体的案例来写会比较好理解。关于大数据平台基础框架我还是用自己熟悉的DKhadoop为例。

在此之前还是对DKhadoop做一个简单的说明:DKhadoop大快大数据平台,由大快搜索开发的为了打通大数据生态系统与传统非大数据公司之间的通道而设计的一站式搜索引擎级大数据通用计算平台(写的这么专业,肯定是我从大快宣传册上搬运过来的啦)。对于有大量数据需要处理的传统型企业而言,通过DKhadoop这样的大数据处理平台可以很轻松的跨越大数据技术鸿沟,实现搜索引擎级的大数据平台性能。既然有如此大的优势,那么样的大数据平台的基础框架又是如何的呢?

我们先来看一张图片:这张图是DKH标准平台技术架构图

 DKhadoop大数据基础架构设计方案

DKhadoop大数据平台基础框架设计方案概述:

1、如果你对原生hadoop较为熟悉的,你就会发现dkhadoop是集成了整个hadoop生态系统的全部组建,当然不仅仅是集成这么简单,而是做了深度的优化,重新编写成的一个完整的更高性能的大数据通过计算平台。这一点跟其他国产发行本大数据平台还是有着非常的区别的,DKH是做的原生态开发,其他的国产发行版仅仅是简单的二次开发。

2、DKhadoop通过中间件技术,将复杂的大数据集群配置简化至三种节点(主节点、管理节点、计算节点),很大程度上简化了集群的管理运维,增强了集群的高可用性、高可维护性、高稳定性。(数据中间件是大快DKH数据交换层的核心)

3DKH在原生态的基础上开发,并且保持了开源系统的全部优点,与开源系统100%兼容。这样,那些基于开源平台开发的大数据应用就不要经过任何改动,就可以在DKH上高效运行了。

 

没有更多推荐了,返回首页