2017-08-02 17:30:41 Full_Stack_delp 阅读数 4716
  • 数据中台架构详解

    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,企业普遍遇到“独-数据烟囱林立”、 “断-数据理解与分析断层”、“缺-缺数据、缺标准、缺治理”、“难-知数据难、懂数据难、要数据难”四大难题。因此,越来越多企业希望构建数据中台,通过数据中台来用好数据。 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。

    2972 人正在学习 去看看 CSDN讲师

目录:

  • 什么是大数据
  • Hadoop介绍-HDFS、MR、Hbase
  • 大数据平台应用举例-腾讯
  • 公司的大数据平台架构

“就像望远镜让我们能够感受宇宙,显微镜让我们能够观测微生物一样,大数据正在改变我们的生活以及理解世界的方式……”。

大数据的4V特征-来源

大数据

公司的“大数据”

随着公司业务的增长,大量和流程、规则相关的非结构化数据也爆发式增长。比如:

1、业务系统现在平均每天存储20万张图片,磁盘空间每天消耗100G;

2、平均每天产生签约视频文件6000个,每个平均250M,磁盘空间每天消耗1T;

……

三国里的“大数据”

“草船借箭”和大数据有什么关系呢?对天象的观察是基于一种对风、云、温度、湿度、光照和所处节气的综合分析这些数据来源于多元化的“非结构”类型,并且数据量较大,只不过这些数据输入到的不是电脑,而是人脑并最终通过计算分析得出结论。

草船借箭

Google分布式计算的三驾马车

  • Google File System用来解决数据存储的问题,采用N多台廉价的电脑,使用冗余(也就是一份文件保存多份在不同的电脑之上)的方式,来取得读写速度与数据安全并存的结果。
  • Map-Reduce说穿了就是函数式编程,把所有的操作都分成两类,map与reduce,map用来将数据分成多份,分开处理,reduce将处理后的结果进行归并,得到最终的结果。
  • BigTable是在分布式系统上存储结构化数据的一个解决方案,解决了巨大的Table的管理、负载均衡的问题。

Hadoop体系架构

Hadoop

 

hadoop核心设计

Hadoop

 

HDFS介绍-文件读流程

Hadoop

 

Client向NameNode发起文件读取的请求。
NameNode返回文件存储的DataNode的信息。
Client读取文件信息。
HDFS介绍-文件写流程
HDFS
Client向NameNode发起文件写入的请求。
NameNode根据文件大小和文件块配置情况,返回给Client它所管理部分DataNode的信息。
Client将文件划分为多个Block,根据DataNode的地址信息,按顺序写入到每一个DataNode块中。

MapReduce——映射、化简编程模型

输入数据->Map分解任务->执行并返回结果->Reduce汇总结果->输出结果

HDFS

 

Hbase——分布式数据存储系统

HDFS

 

Client:使用hbase RPC机制与HMaster和HRegionServer进行通信

Zookeeper:协同服务管理,HMaster通过Zookeepe可以随时感知各个HRegionServer的健康状况

HMaster: 管理用户对表的增删改查操作

HRegionServer:HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据

HRegion:Hbase中分布式存储的最小单元,可以理解成一个Table

HStore:HBase存储的核心。由MemStore和StoreFile组成。

HLog:每次用户操作写入Memstore的同时,也会写一份数据到HLog文件

还有哪些NoSQL产品?

NoSQL

 

为什么要使用NoSQL?

一个高并发网站的DB进化史

NoSQL

关系模型>聚合数据模型的转换-基本变换

NoSQL

 

关系模型>聚合数据模型的转换-内嵌变换

NoSQL

 

关系模型>聚合数据模型的转换-分割变换

NoSQL

 

关系模型>聚合数据模型的转换-内联变换

 

36大数据

Hadoop2.0

MapReduce:
JobTracker:协调作业的运行。
TaskTracker:运行作业划分后的任务。

Hadoop2.0
大数据的技术领域
Hadoop2.0
腾讯大数据现状(资料来自2014.4.11 腾讯分享日大会)
Hadoop2.0
 腾讯大数据
腾讯大数据平台产品架构
Hadoop2.0
腾讯大数据平台与业务平台的关系
Hadoop2.0
公司数据处理平台的基础架构
大数据
公司大数据平台架构图
大数据
应用一数据分析
大数据
应用二视频存储
 大数据
应用三离线日志分析
大数据
应用五在线数据分析
参考资料:京东基于Samza的流式计算实践
大数据
2017-09-08 23:55:16 wang7807564 阅读数 3963
  • 数据中台架构详解

    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,企业普遍遇到“独-数据烟囱林立”、 “断-数据理解与分析断层”、“缺-缺数据、缺标准、缺治理”、“难-知数据难、懂数据难、要数据难”四大难题。因此,越来越多企业希望构建数据中台,通过数据中台来用好数据。 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。

    2972 人正在学习 去看看 CSDN讲师

大数据技术这几年来被炒得火热,一方面也真的是数据量越来越大,传统的海量数据处理技术已经不能够满足当前的业务场景;另一反面,也是由于蕴藏在大量数据中的价值越来越引起人们的重视。

大数据技术的兴起,与人工智能技术的兴起是相辅相成的。大数据处理技术的及时、高效,更方便人工智能的网格计算,越来越多的中小型创业公司也加入了大数据圈。可能一个比较有趣的问题就是,中小型公司哪里能够获取到数据?更何谈大数据?现在的中小型企业比较热衷的方向是BI,也就是商业智能,商业智能、精准广告投递这方面中小型企业、创业公司做的还是不错的,主要是提供某种解决方案,而不是直接拿数据来解决问题。

那么,我们姑且来看看,大公司是怎么高效利用这些海量数据的,也从中,窥探一下大数据技术的“钱沿”:

1.斗鱼大数据架构

我们先来看一张,斗鱼大数据架构图:

这张图是斗鱼官方提供的,不是我自己想象着画的,斗鱼数据平台部总监吴锐成曾经在文章中详细谈到过斗鱼的大数据解决方案。

我们姑且从这张图中照猫画虎,尝试着强行分析一波:

  1. 斗鱼的数据来源是多样的,都送到统一数据平台进行收集、分析,这些数据包括了服务器日志,MySQL的二进制日志,用户行为等,来源还是很丰富的。
  2. 在数据处理平台和数据源中,增加一个消息中间件,对于这种大吞吐量的场景,大数据环境用的最多的消息中间件就是kafka了,kafka的特点就是吞吐量很大,这种
  3. 消息队列本身就是Hadoop生态系统中的一员,在这种业务场景下,其他的诸如RM,AM这种,相对得用的要少很多。
  4. kafka这种消息中间件是基于zookeeper的,主要利用的就是zookeeper的一致配置等一致性特性,也就是说,kafka是一个分布式的集群,这种集群本身就自带着Zookeeper高可用的光环,在面对海量数据的业务压力时,能够从容应对。原先很多场合,都是flume+kafka这种架构模式,由flume进行数据采集,kafka承担消费者,这里面的数据源必然是一个生产者,但是具体的生产过程是怎样的在这张图中没有体现出来,可能是flume,也可能是自己开发的JAVA处理程序,也可能是其他的什么途径,这里就不猜测了。
  5. 在往上,就是对来自Kafka的数据进行一个数据清理,这当然是用ETL经典的解决方案,没有问题。
  6. 斗鱼的数据处理层还是很经典的:离线计算,流式计算,归档和MySQL持久化数据。
  7. 在离线处理这部分,就是使用经久不衰的Hadoop解决方案,HDFS+YARN+spark这种,然后,就可以对数据进行一个离线的数据挖掘。
  8. 在流式数据处理中,斗鱼的技术栈将Storm和Spark streaming都用上了,可能也是跟自己的业务场景比较复杂有关,对于一般的公司,业务场景也比较简单,Storm还是
  9. Spark streaming很容易就可以选择出来了,其实,在很多情境下,大部分的中小型公司这两个方案差别不是很大。
  10. 在这个比较经典的数据平台上,在搭建一个运维系统,这个运维系统应该是自行研制的,大家可以在左侧看到这个运维系统。
  11. 就这个大数据处理平台来看,还是中规中矩的,同时,也看到了斗鱼的技术栈确实比较全面,也从侧面看到了斗鱼的业务场景确实不是单一的,还是比较复杂的。

应用这些大数据的能够解决的问题当然也很多了:

斗鱼房间观众这么多,键盘侠这么多,不监控一下怎么能行;主播不老实,表演一下黄鳝还得了?监控下黑卡刷鱼丸神马的~
斗鱼在这个技术栈里面,可能还会包含一些图计算之类的小众应用场景,但是,对外并没有过明确的公布,这里我们也不去妄加推测。


2019-04-03 13:18:28 dream_an 阅读数 680
  • 数据中台架构详解

    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,企业普遍遇到“独-数据烟囱林立”、 “断-数据理解与分析断层”、“缺-缺数据、缺标准、缺治理”、“难-知数据难、懂数据难、要数据难”四大难题。因此,越来越多企业希望构建数据中台,通过数据中台来用好数据。 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。

    2972 人正在学习 去看看 CSDN讲师

1.Pipeline大数据架构

pipeline大数据架构
(create by 王小雷)

Pipeline大数据架构,面向大数据仓库和大数据处理平台。是基于lambda的大数据架构的变种,增加了企业级服务,而并非只是大数据组件的对切,是一种更落地的方案。
如同骨架之间使用软骨连接起来一样,是一个完整可执行的架构设计。形成Pipeline架构。

Pipeline大数据架构由一个源、四个层(1+4)组成。

2.数据源

数据源是泛指需要大数据平台处理的所有数据源。大多时候是企业的业务系统产生的,这部分一般都是在大数据平台之外,而且关系型数据为主。

2.1.关系型数据源

如MySQL、PostgreSQL中的业务数据,这部分是绝多大企业要处理的数据。

2.2.非关系型数据源

如MongoDB数据、日志数据等。

3.基础调度层

大数据处理是集群执行的。那么就需要大数据应用的任务调度、资源调度。

其中有很多大数据组件具有调度能力。称为基础调度层。

3.1.Zookeeper

3.2.YARN

3.3.Azkaban

4.大数据平台管控层

管控层在基础调度层之上,上文是数仓/数据处理层,下文是基础调度层。旨在让集群资源、任务调度机制更加定制、自动、智能化。

比如一个很大的数据处理,需要两种通道Hive ETL或者Spark SQL都可以处理,但是根据文件大小和结构,百分之三十用Hive ETL,70%用Spark SQL处理。
让处理时间和资源占用达到整体较优。

4.1.智能调度决策流服务

数据处理是多种通道的,如Spark处理、Flink处理,但是根据数据的特点和业务要求,需要通过不同策略调用不同处理方式来处理数据。

4.2.任务状态监控服务

整个Pipeline任务执行时间、状态、结果都是需要监控服务来记录和报警的。

4.3.任务重试/数据回溯服务

某个单元数据处理出现问题、未通过数据校验等需要这部分数据重新计算或者回溯原始数据。

4.4.管控通信服务

集群管控信息收集后发送给大数据对应模块负责人。邮件为主,紧急可以短信。

4.5.并行调度服务

为了充分利用资源和任务特性,有些数据处理任务需要并行调度。

5.数据仓库/数据处理(离线处理/实时处理)层

Pipeline大数据架构核心层,数仓、数据湖泊、实时处理、批处理,也是lambda核心的变种,同样增了企业级可行性服务。

如字典服务,规则生成引擎等。

5.1.pipeline数据摄取/缓存

大数据系统外/内的待处理数据或者输出数据的大通道,一切数据的在大数据平台的进出由该模块负责。

如果细胞的细胞壁。也如同屠夫的钩子(按Q)。

5.1.1.Flume数据缓存服务

大多时候是接入Log日志,如数据库的write-ahead logging (WAL)、系统埋点日志数据等等,无侵入接入数据。

5.1.2.Kafka数据缓存服务

通常是来对接Flume,用Topic等连接,并分发到计算引擎或者沉淀到存储系统,或者暂时缓存数据。

5.1.3.引擎数据直连服务

引擎直连服务可能对业务系统有害,因为是侵入式直连,数据的抽取或者写入会对业务系统有很大影响。

但是,敏捷开发,或者刚开始建立大数据平台,这种方式来的最快。不需要更多大数据链路,抽过来数据直接处理。这先落地再优化的方法,何乐而不为呢(减少加班吧)。

5.2.Pipeline数据处理 core

5.2.1.在线处理引擎

Flink

5.2.2.离线处理引擎

Spark SQL

5.2.3.字典服务

业务系统有多个产品,多个库,它们根据业务不同,库、表、字段各不相同,需要大数据这边有一个字典服务,记录、汇总、跟踪业务系统数据字典。

为SQL自动拆箱/装箱引擎、数据层设计/规则生成引擎提供原料。

5.2.4.SQL自动化拆箱/装箱引擎

配合计算引擎,达到批量计算,如有1万张表需要抽取到大数据仓库,用Spark SQL实现,其中包括数据的特殊更改、全量、增量、流水、拉链等操作。

5.2.5.同步记录服务

多业务多库多表同步到数仓或者处理时候,增量同步记录服务。

5.2.6.数据层设计/规则生成引擎

业务分析师将业务数据与大数据开发团队对接。

将业务数据规则设计为大数据数据,偏向业务对接、分析。

5.2.7.Hive数据ETL服务

作为数据处理的工具,可做简单的ETL工作。

5.3.Pipeline数据存储

数仓存储根据层次、业务的不同可存储不同。原始数据,非规则化数据,超大文件可存储在HDFS上,冷数据做压缩处理。

HBase直接对接引擎计算后的数据沉淀。

Hive可存储不同层次的数据,但是更多时候是做数仓的管理工具,如外部数据HDFS、Hbase等外部表。

5.3.1.HDFS

5.3.1.HBase

5.3.1.MySQL、Redis

5.3.1.Hive

5.4.Pipeline数据治理

数据治理是在数据接入到大数据平台时做规范,如日期规范、脱敏、字段类型映射等等。

5.4.1.数据规范服务

5.4.2.人工检测

5.4.3.数据校验服务

6.对外业务分析层

6.1.HUE提供SQL查询功能,供业务分析部分使用

1HiveQL SparkSQL Impala

6.2.1.在线业务分析

6.2.1.组成 Restful/web服务


扫码关注

在这里插入图片描述

2019-03-23 15:35:43 weixin_42813814 阅读数 287
  • 数据中台架构详解

    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,企业普遍遇到“独-数据烟囱林立”、 “断-数据理解与分析断层”、“缺-缺数据、缺标准、缺治理”、“难-知数据难、懂数据难、要数据难”四大难题。因此,越来越多企业希望构建数据中台,通过数据中台来用好数据。 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。

    2972 人正在学习 去看看 CSDN讲师

什么是大数据架构

大数据架构是用于摄取和处理大量数据(通常称为“大数据”)的总体系统,因此可以针对业务目的进行分析。该架构可视为基于组织业务需求的大数据解决方案的蓝图。大数据架构旨在处理以下类型的工作:
什么是大数据架构
  批量处理大数据源。

实时处理大数据。

预测分析和机器学习。 精心设计的大数据架构可以节省企业资金,并帮助其预测未来趋势,从而做出明智的业务决策。

大数据架构的好处

可用于分析的数据量每天都在增长。而且,流媒体资源比以往更多,其中包括流量传感器、健康传感器、事务日志和活动日志中提供的数据。但拥有数据只是业务成功的一半。企业还需要能够理解数据,并及时使用它来影响关键决策。使用大数据架构可以帮助企业节省资金并做出关键决策,其中包括:

降低成本。在存储大量数据时,Hadoop和基于云计算的分析等大数据技术可以显著地降低成本。

做出更快、更好的决策。使用大数据架构的流组件,企业可以实时做出决策。

预测未来需求并创建新产品。大数据可以帮助企业衡量客户需求并使用分析预测未来趋势。

大数据架构的挑战

如果做得好,大数据架构可以为企业节省资金,并帮助预测重要的趋势,但它并非没有挑战。在处理大数据时,需要注意以下问题:

(1)数据质量

无论何时使用各种数据源,数据质量都是一项挑战。这意味着企业需要做的工作是确保数据格式匹配,并且没有重复数据或缺少数据将会使分析不可靠。企业需要先分析和准备数据,然后才能将其与其他数据一起进行分析。

(2)扩展

大数据的价值在于其数量。但是,这也可能成为一个重要问题。如果企业尚未设计架构以进行扩展,则可能会很快遇到问题。首先,如果企业不计划支持基础设施,那么支持基础设施的成本就会增加。这可能会给企业的预算带来负担。其次,如果企业不打算进行扩展,那么其性能可能会显著下降。这两个问题都应该在构建大数据架构的规划阶段得到解决。

(3)安全性

虽然大数据可以为企业提供对数据的深入了解,但保护这些数据仍然具有挑战性。欺诈者和黑客可能对企业的数据非常感兴趣,他们可能会尝试添加自己的伪造数据或浏览企业的数据以获取敏感信息。网络犯罪分子可以制作数据并将其引入其数据湖。例如,假设企业跟踪网站点击次数以发现流量中的异常模式,并在其网站上查找犯罪活动,网络犯罪分子可以渗透企业的系统,在企业的大数据中可以找到大量的敏感信息,如果企业没有保护周边环境,加密数据并努力匿名化数据以移除敏感信息的话,网络犯罪分子可能会挖掘其数据以获取这些信息。

大数据架构因公司的基础设施和需求而异,但通常包含以下组件:

数据源。所有大数据架构都从源代码开始。这可以包括来自数据库的数据、来自实时源(如物联网设备)的数据,以及从应用程序(如Windows日志)生成的静态文件。

实时消息接收。如果有实时源,则需要在架构中构建一种机制来摄取数据。

数据存储。企业需要存储将通过大数据架构处理的数据。通常,数据将存储在数据湖中,这是一个可以轻松扩展的大型非结构化数据库。

批处理和实时处理的组合。企业需要同时处理实时数据和静态数据,因此应在大数据架构中内置批量和实时处理的组合。这是因为可以使用批处理有效地处理大量数据,而实时数据需要立即处理才能带来价值。批处理涉及到长时间运行的作业,用于筛选、聚合和准备数据进行分析。

分析数据存储。准备好要分析的数据后,需要将它们放在一个位置,以便对整个数据集进行分析。分析数据存储的重要性在于,企业的所有数据都集中在一个位置,因此其分析将是全面的,并且针对分析而非事务进行了优化。这可能采取基于云计算的数据仓库或关系数据库的形式,具体取决于企业的需求。

分析或报告工具。在摄取和处理各种数据源之后,企业需要包含一个分析数据的工具。通常,企业将使用BI(商业智能)工具来完成这项工作,并且可能需要数据科学家来探索数据。

自动化。通过这些不同的系统移动数据需要通常以某种形式的自动化进行编排。数据的摄取和转换、批量移动和流处理,将其加载到分析数据存储,最后获得洞察力必须在可重复的工作流程中,以便企业可以不断从大数据中获取洞察力。

2019-05-12 13:09:23 bigagag 阅读数 148
  • 数据中台架构详解

    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,企业普遍遇到“独-数据烟囱林立”、 “断-数据理解与分析断层”、“缺-缺数据、缺标准、缺治理”、“难-知数据难、懂数据难、要数据难”四大难题。因此,越来越多企业希望构建数据中台,通过数据中台来用好数据。 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。

    2972 人正在学习 去看看 CSDN讲师

大数据已经成为大多数企业管理者关心的问题。显而易见,数据分析能够在大数据时代打来大机遇。但是,数据集需要如此之大吗?

现在广为接受的大数据的定义是Gartner提出的三个V的概念,即数量大、种类多和变化快(volume、variety、velocity)。本世纪初,大数据开始流行。管理者也在积极寻求发展自己大数据架构的方法。然而管理者忽视的是,大数据分析的难题可能通过内部部署就足以解决,而且比预想的简单的多。

Shaw就是一个例子。它是一家地毯制造商,它没有向很多发展大数据架构的公司一样,重金购买第三方客户数据或手机网站数据,而是在自己的企业资源管理软件、客户关系管理系统和数据仓库上下功夫,也成功地提高了销售业绩。

Shaw商业部门的副总裁Tim Baucom说,“现在正是把这些系统集成在一起的大好机会。”

Baucom 表示,Shaw希望解决的主要问题是价格浮动。通常来讲,Shaw的销售流程要经历6个月甚至更长的时间。这期间原材料的价格会改变,如果承建商超出预算,有可能修改订单。这些都导致Shaw的销售人员很难保证销售利润的持平。

2005年,公司认识到需要通过数据预测价格。Baucom比较了解Zilliant公司,Zilliant公司提供客户和产品数据的预测工具,帮助优化商业价格。Shaw部署了Zilliant MarginMax软件,在整个销售过程跟踪报价,结合具体情况作出调整,衡量销售定价的一致性。该软件中输入了地毯制造商现有数据系统中的所有有用信息。

把这些不同的数据源整合到一起也是一个不小的壮举。Baucom表示,客户服务、销售和网站数据之间没有互渗。所有这些都存储在筒仓系统中。一开始,Shaw依赖于Zilliant的数据科学家的意见配置系统,这样它就可以弄清不同系统数据之间的关系。

但是在一开始的时候,销售团队认为这种新型模式关注的净是一些偶然因素,比如一周价格变化。很多组织在建立分析系统的时候都面临这个问题。很多时候需要数据科学家定义算法,但往往要业务专家判定这种算法是否有效。在这种情况下,Baucom不得不亲自寻找有意义并可行的相互关系,比如项目类型导致的利润变动和应用材料导致的利润变动。通过与供应商的合作,他改良了该系统,使其生成结果更有指导性。

Baucom表示现在Shaw的销售管理者都用数据武装起来了,他们的定价会更有效。自从应用大数据分析,Shaw的销售利润增长了5%.

Baucom也不确定这是不是一个大数据的案例。2005年,很多人都认为这是一个大数据案例,但照几天的标准来看,它又不能算真正的大数据架构案例了。不过对Baucom而言,重要的是基于数据制定价格决策。
在这里我还是要推荐下我自己建的大数据学习交流qq裙:522189307 , 裙 里都是学大数据开发的,如果你正在学习大数据 ,小编欢迎你加入,大家都是软件开发党,不定期分享干货(只有大数据开发相关的),包括我自己整理的一份最新的大数据进阶资料和高级开发教程,欢迎进阶中和进想深入大数据的小伙伴。上述资料加群可以领取

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