五个篇章讲明白如何从0到1搭建大数据平台.docx

五个篇章讲明白如何从。到工搭建大数据平台01如何从。到1搭建大数据平台
大数据时代这个词被提出已有10年了吧，越来越多的企业已经完成了大数据平 台的搭建。随着移动互联网和物联网的爆发，大数据价值在越来越多的场景中被 挖掘，随着大家都在使用欧冠大数据，大数据平台的搭建门槛也越来越低。借助 开源的力量，任何有基础研发能力的组织完全可以搭建自己的大数据平台。但是 对于没有了解过大数据平台、数据仓库、数据挖掘概念的同学可能还是无法顺利 完成搭建，因为你去百度查的时候会发现太多的东西，和架构，你不知道如何去 选择。今天给大家提供下大数据平台是怎么玩的。
00架构总览务用 台算 ，据集储 戈应 不计 於彖4

务用 台算 ，据集储 戈应 不计 於彖4
指林 报袅! 1颈警系统 用户画像 智能分析］
_」T 一 」I 二 T 二 I 一 」
二陵处理
Hadoop&& Yarn
HDFS
业务数据闺
kafka Flink
Streaming
L —— j i
HBase
AI
外部数据
.装据
分析
数据
仓庠
通常大数据平台的架构如上，从外部采集数据到数据处理，数据显现，应用等模 块。
01数据采集外部访问，将数据块映射到数据节点。还会备份元数据从命名节点，它只与命名 节点通信。
数据在多个数据节点备份。
通常关系型数据库存储的都是结构化的数据，我们抽取后会直接放到HDFS上作 为离线分析的数据源。
HBase在实际应用中，我们有很多数据可能不需要复杂的分析，只需要我们能存储，并 且提供快速查询的功能。HBase在HDFS基础上提供了 Bigtable的能力；并且基 于列的模式进行存储底列存储设计的优势是减少不必要的字段占用存储，同时查 询的时候也可以只对查询的指定列有10操作。HBase可以存储海量的数据，并 且可以根据rowkey提供快速的查询性能，是非常好的明细数据存储方案，比方电 商的订单数据就可以放入HBase提供高效的查询。
当然还有其他的存储引擎，比方ES适合文本搜索查询等。
04总结了解了上面的技术栈后，在实际数据接入中，你还会面临各种问题，比方如何考 虑确保数据一致性，保障数据不能丧失，数据采集存储的效率，不能产生数据积 压等，这些都需要对每个组件进行研究，适配适合你自己业务系统的参数，用最 少的资源，到达最好的结果。
03调度系统目前大数据平台经常会用来跑一些批任务，跑批处理当然就离不开定时任务。比 如定时抽取业务数据库的数据，定时跑hive/spark任务，定时推送日报、月报指 标数据。任务调度系统已经俨然成为了大数据处理平台不可或缺的一局部，可以 说是ETL任务的灵魂。
01原始任务调度记得第一次参与大数据平台从无到有的搭建，最开始任务调度就是用的Crontab, 分时日月周，各种任务脚本配置在一台主机上。Crontab使用非常方便，配置也 很简单。刚开始任务很少，用着还可以，每天起床巡检一下日志。随着任务越来 越多，出现了任务不能在原来计划的时间完成，出现了上级任务跑完前，后面依 赖的任务已经起来了，这时候没有数据，任务就会报错，或者两个任务并行跑了， 出现了错误的结果。排查任务错误原因越来麻烦，各种任务的依赖关系越来越复 杂，最后排查任务问题就行从一团乱麻中，一根一根梳理出每天麻绳。crontab虽 然简单，稳定，但是随着任务的增加和依赖关系越来越复杂，已经完全不能满足 我们的需求了，这时候就需要建设自己的调度系统了。
02调度系统调度系统，关注的首要重点是在正确的时间点启动正确的作业，确保作业按照正 确的依赖关系及时准确的执行。资源的利用率通常不是第一关注要点，业务流程 的正确性才是最重要的。（但是到随着业务的开展，ETL任务越来越多，你会发 现经常有任务因为资源问题没有按时启动！）
实际调度中，多个任务单元之间往往有着强依赖关系，上游任务执行并成功，下 游任务才可以执行。比方上游任务1结束后拿到结果，下游任务2、任务3需结 合任务1的结果才能执行，因此下游任务的开始一定是在上游任务成功运行拿到 结果之后才可以开始。而为了保证数据处理结果的准确性，就必须要求这些任务 按照上下游依赖关系有序、高效的执行，最终确保能按时正常生成业务指标。
一款成熟易用，便于管理和维护的作业调度系统，需要和大量的周边组件对接， 要处理或使用到包括：血缘管理，权限控制，负载流控，监控报警，质量分析等 各种服务或事务。
03调度系统分类调度系统一般分为两类：定时分片类作业调度系统和DAG工作流类作业调度系统
定时分片类作业调度系统这种功能定位的作业调度系统，其最早的需要来源和出发点往往是做一个分布式 的 Crontabo
核心： 将一个大的任务拆成多个小任务分配到不同的服务器上执行，难点在于要做到不 漏，不重，保证负载平衡，节点崩溃时自动进行任务迁移等。
保证任务触发的强实时和可靠性 所以，负载均衡，弹性扩容，状态同步和失效转移通常是这类调度系统在架构设 计时重点考虑的特性。
DGA工作流调度系统
这一类系统的方向，重点定位于任务的调度依赖关系的正确处理，分片执行的逻 辑通常不是系统关注的核心，或者不是系统核心流程的关键组成局部。
核心：
足够丰富和灵活的依赖触发机制：比方时间触发任务，依赖触发任务，混合触发 任务
作业的计划，变更和执行流水的管理和同步
任务的优先级管理，业务隔离，权限管理等
各种特殊流程的处理，比方暂停任务，重刷历史数据，人工标注失败/成功，临 时任务和周期任务的协同等
完备的监控报警通知机制
04几个调度系统
Airflow
Apache Airflow是一种功能强大的工具，可作为任务的有向无环图（DAG）编排、 任务调度和任务监控的工作流工具。Airflow在DAG中管理作业之间的执行依赖， 并可以处理作业失败，重试和警报。开发人员可以编写Python代码以将数据转换 为工作流中的操作。
主要有如下几种组件构成:
web server:主要包括工作流配置，监控，管理等操作
scheduler:工作流调度进程，触发工作流执行，状态更新等操作
消息队列：存放任务执行命令和任务执行状态报告
worker:执行任务和汇报状态
mysql:存放工作流，任务元数据信息
具体执行流程：
1.
scheduler扫描dag文件存入数据库，判断是否触发执行
2.
到达触发执行时间的dag,生成dag」un, taskjnstance存入数据库
3.
发送执行任务命令到消息队列
4.
worker从队列获取任务执行命令执行任务
5.
w o r k e r汇报任务执行状态到消息队列
6.
schduler获取任务执行状态，并做下一步操作
7.
schduler根据状态更新数据库
Kettle将各个任务操作组件拖放到工作区，kettle支持各种常见的数据转换。此外，用户 可以将Python, Java, JavaScript和SQL中的自定义脚本拖放到画布上。kettle 可以接受许多文件类型作为输入，还可以通过JDBC, ODBC连接到40多个数据 库，作为源或目标。社区版本是免费的，但提供的功能比付费版本少。
XXL-JOBXXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、 轻量级、易扩展。将调度行为抽象形成“调度中心”公共平台，而平台自身并不承当 业务逻辑，“调度中心”负责发起调度请求；将任务抽象成分散的JobHandler,交 由“执行器”统一管理，“执行器”负责接收调度请求并执行对应的JobHandler中业
务逻辑；因此，“调度”和“任务”两局部可以相互解耦，提高系统整体稳定性和扩展 性。（后来才知道XXL是作者名字拼音首字母缩写）
调度系统开源工具有很多，可以结合自己公司人员的熟悉程度和需求选择合适的 进行改进。
海豚调度
Apache DolphinScheduler是一个分布式去中心化，易扩展的可视化DAG工作 流任务调度平台。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统 在数据处理流程中开箱即用。
高可靠性
去中心化的多Master和多Worker服务对等架构，防止单Master压力过大，另外 采用任务缓冲队列来防止过载
简单易用
DAG监控界面，所有流程定义都是可视化，通过拖拽任务完成定制DAG,通过 API方式与第三方系统集成，一键部署
丰富的使用场景
支持多租户，支持暂停恢复操作.紧密贴合大数据生态，提供Spark, Hive, M/R, Python, Sub_process, Shell 等近 20 种任务类型
高扩展性
支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master 和Worker支持动态上下线
05如何自己开发一个调度系统
调度平台其实需要解决三个问题：任务编排、任务执行和任务监控。
任务编排，采用调用外部编排服务的方式，主要考虑的是编排需要根据业务的一 些属性进行实现，所以将易变的业务局部从作业调度平台别离出去。如果后续有 对编排逻辑进行调整和修改，都无需操作业务作业调度平台。
任务排队，支持多队列排队配置，后期根据不同类型的开发人员可以配置不同的 队列和资源，比方面向不同的开发人员需要有不同的服务队列，面向不同的任务 也需要有不同的队列优先级支持。通过队列来隔离调度，能够更好地满足具有不 同需求的用户。不同队列的资源不同，合理的利用资源，到达业务价值最大化。
任务调度，是对任务、以及属于该任务的一组子任务进行调度，为了简单可控起 见，每个任务经过编排后会得到一组有序的任务列表，然后对每个任务进行调度。 这里面，稍有点复杂的是，任务里还有子任务，子任务是一些处理组件，比方字 段转换、数据抽取，子任务需要在上层任务中引用实现调度。任务是调度运行的 基本单位。被调度运行的任务会发送到消息队列中，然后等待任务协调计算平台 消费并运行任务，这时调度平台只需要等待任务运行完成的结果消息到达，然后 对作业和任务的状态进行更新，根据实际状态确定下一次调度的任务。
调度平台设计中还需要注意以下几项：
1. 调度运行的任务需要进行超时处理，比方某个任务由于开发人员设计不合理导致 运行时间过长，可以设置任务最大的执行时长，超过最大时长的任务需要及时kill 掉，以免占用大量资源，影响正常的任务运行。
2.
控制同时能够被调度的作业的数量，集群资源是有限的，我们需要控制任务的并 发量，后期任务上千上万后我们要及时调整任务的启动时间，防止同时启动大量 的任务，减少调度资源和计算资源压力；
3. 作业优先级控制，每个业务都有一定的重要级别，我们要有限保障最重要的业务 优先执行，优先给与调度资源分配。在任务积压时候，先执行优先级高的任务， 保障业务影响最小化。
4.
06总结与展望ETL开发是数据工程师必备的技能之一，在数据仓库、BI等场景中起到重要的作 用。但很多从业者连ETL对应的英文是什么都不了解，更不要谈对ETL的深入 解析，这无疑是非常不称职的。做ETL你可以用任何的编程语言来完成开发，无 论是shelL python, java甚至数据库的存储过程，只要它最终是让数据完成抽 取（E）、转化（丁）、加载（L）的效果即可。由于ETL是极为复杂的过程，而 手写程序不易管理，所以越来越多的可视化调度编排工具出现了。
调度系统作为大数据平台的核心局部之一，牵扯的业务逻辑比拟复杂，场景不同， 也许需求就会差异很多，所以，有自研能力的公司都会选择市面上开源系统二次 开发或者完全自研一套调度系统，已满足自身ETL任务调度需求。
不管是哪种工具，只要具备高效运行、稳定可靠、易于维护特点，都是一款好工 具。
04计算存储系统
大数据计算平台目前主要都是围绕着hadoop生态开展的，运用HDFS作为数据 存储，计算框架分为批处理、流处理。
01传统的计算平台
我们都知道，没有大数据之前，我们计算平台基本是依赖数据库，大数据量的计 算基本依赖Oracle数据库。Oracle很强大，支撑了很多年银行、电信业务数据的 计算存储。Oracle多以集中式架构为主，最大特点就是将所有的数据都集中在一 个数据库中，依靠大型高端设备来提供高处理能力和扩展性。集中式数据库的扩 展性主要采用向上扩展的方式，通过增加CPU,内存，磁盘等方式提高处理能力。 这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适 应海量数据对计算能力的巨大需求。同时传统数据库架构对高端设备的依赖，无 疑将直接导致系统本钱的大幅度增加，甚至可能会导致系统被主机和硬件厂商所 “绑架”，不得不持续增加投入本钱。
02 Hadoop的崛起
随着互联网行业的开展，特别是移动互联网的快速开展，传统数据库面临着海量 数据的存储本钱、有限的扩展能力等问题。新的计算框架MapReduce出现了， 新的存储编码方式HDFS出现了，二者合起来，我们一般称之为Hadoop。
Hadoop很快凭借其高可靠性、高扩展性、本钱低、高效计算等优势在各个领域得 到了广泛应用。
03 Hive的应用
Hive最初是Facebook开源的，我们来看看Hive的特点:
Hive是一个构建于Hadoop顶层的数据仓库工具，可以查询和管理PB级别的分 布式数据。
支持类SQL语音。
可以看作为用户编程接口，本身不存储和处理数据
依赖HDFS作为存储
我们看到Hive支持类SQL语法，我们可以很容易的把传统关系型数据库建立的 数据仓库任务迁移到Hadoop平台上。
Hive的架构：
我们可以看到hive提供了多种连接方式：JDBC、ODBC、Thrifto
那么我们以前使用Oracle的存储过程怎么迁移到Hive中呢？用过Hive的同学可 能都知道，Hive是没有想Oracle那样的游标循环呀，所以我们必须借助其他语言 来配合hive 一起完成数据仓库的ETL过程。比方这个工程： PyHive( s://github /dropbox/PyHive)
借助Python,我们可以很好的弥补Hive在复杂处理的一些缺陷，同时也能更好 的开发ETL任务。
所以，通过Hive我们就可以搭建起一套大数据计算平台。
04 Spark的应用
Hive在刚开始使用过程中很好用，对大数据量的处理确实比以前传统数据库要好, 但是随着业务的增长，公司越来越多的数据工程师反应查询慢，同时业务侧也纷 纷提出，我们的数据能不能早点出，不要老是等到早上8点才刷新。我们需要更 强大的计算引擎，Spark使用了十分之一的计算资源，获得了比Hadoop快3倍 的速度，Spark为什么这么快呢？
我们来看看Spark的特点：
速度快，使用DGA (有向无环图)。
支持内存计算。
低延迟、高容错。
Spark提供了存计算，可以将计算结果存放到内存中，我们都知道MR是将数据 存储在磁盘，对磁盘读写，势必会增加10操作，计算时间过长。之前我也做过一 个Hive和Spark的一个执行效率的比照，当时使用的是Sparkl.6,数据是千万 级别的表。
还是可以看出Spark比Hive快了很多，现在Spark2.0以后，会更快了。而且, Spark同样提供的有JDBC、ODBC、Thrift连接方式。
我们可以从Hive环境直接迁移到Spark环境，提高执行效率。
05 MPP的应用用了 Spark还是不够快，每次查询提交任务后，都得等着任务启动然后看着任务 执行进度一直等着。
MPP (Massively Parallel Processing)是指多个处理器(或独立的计算机)并行 处理一组协同计算。为了保证各节点的独立计算能力，MPP数据库通常采用 ShareNothing架构。比拟有代表性大家熟知的比方：GPDB、Verticao
MPP具备以下特点:
低本钱的硬件、和Hadoop一样，使用x86架构的PC就可以
数据存储采用不同的压缩算法，减少使用空间，提高10性能
数据加载高效，并行加载、数据加载的速度取决于带宽
易扩展，容易对集群节点进行增减
列存储，很多MPP支持列存储架构，能够更高效的访问需要的数据
支持标准SQL, MPP比SparkSQL、HiveSQL对标准SQL支持的更好
从以上MPP的特点和上面我们介绍的Hadoop的特点，会发现MPP更适合数据 自助分析、即席查询等场景、能够使数据人员快速获取数据结果。
06搭建自己的计算平台
开源的计算引擎这么多、我们如何选择合适的计算引擎搭建平台呢？
下面分多个场景来和大家探讨下：
小公司、无大数据平台
真正的从无到有搭建大数据平台，开发人员较少。可以直接使用CDH搭建起来你 的大数据平台，选用Hive作为数据仓库的计算引擎。为什么这样选择呢？很多小 公司没有足够的资金支撑大数据平台的建设，那么就会选择相对来说的比拟稳定 的开源组件，Hive开展了很多年，和磁盘的交互MR计算架构中的任务很少会出 错。Hive对SQL支持的很好，开发人员很容易上手，而且维护本钱很低。
小公司、大数据平台升级
已经有过一段时间使用Hive作为计算引擎后，工程师们对大数据平台已经有一定 的了解和知识积累，对Hadoop的运维能力也提升了，随着开发人员反应Hive比 较慢，领导也考虑升级平台，这时候就可以引入Spark 了。上面我们也说了 Spark 是基于内存运算的，内存始终是没有磁盘稳定，Spark任务很多时候会因为资源 设置不合理而报错。而SparkSQL和可以直接共享Hive的metestore,直接从Hive 迁移到Spark上很自然，工作流很小。同时Spark还提供了 Streaming功能，可 以满足公司逐渐开展遇到的实时数据问题，再也不用担忧以前hive没半小时执行 一次任务，任务还偶尔出现执行不完的场景了。
大公司
很多传统行业的大公司一直依赖传统关系型数据库来处理数据，花了很多钱购置 硬件和服务。现在要“降本增效”，必然会对IT部门下手。大公司有钱，就可以招 聘到专业的工程师，他们有过建设大数据平台的经验，在计算选型上可以根据自 己的技术栈选择合适的计算引擎。
另外，可以买一些MPP数据库的服务，比方GreenPlum商业版、Verticao商业 版的很稳定，几乎不会碰到棘手的问题，平时只管使用就行了，大大提高的运维、 开发效率。比照下来会发现比以前使用传统的关系型数据库省了不少钱。
07总结
基于多个计算引擎搭建大数据平台是目前的现状，针对不同的企业和团队选择适 合自己的，同一个公司不同的业务也可以选择不同的计算引擎。不考虑商业方案， 就要根据自己的技术掌握情况，选择自己精通的并且适合业务的。考虑商业方案 的可以选择商业的MPP,给开发和业务人员提供更好的环境和体验。

用户访问我们的产品会产生大量的行为日志，因此我们需要特定的日志采集系统 来采集并输送这些日志。Flume是目前常用的开源选择，Flume是Cloudera提供 的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume 支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数 据进行简单处理，并写到各种数据接受方的能力。

05自助分析系统
01什么是自助分析平台
自助分析平台是构建在大数据平台之上的，依托于大数据平台的数据研发能力， 通过统一的数据服务，实现对数据查询、分析的统一管理，为企业业务分析提供 高效的数据决策支持，同时也防止数据工程师陷入繁杂的提数需求中。自助分析 平台是有计算机基础的业务人员能够快速上手的前端产品，既要有大数据的处理 性能，有需要有简单好用的可视化分析能力，只有让业务人员能够快速掌握使用 方法，和公司的业务结合起来，自助分析平台才有价值。其实，一直以来，各大 公司的数据分析平台都只有一个目标一一干掉Excelo
02自助分析平台该有哪些模块
上面已经介绍了，自助分析平台是用来查询数据，探索数据的，需要具备Excel 已有的功能，还要比Excel做的更好。
支持多数据源接入
自助分析平台要能够支持多种数据源、不同数据类型文件的接入，能够让数据工 程师和业务人员快速的把数据导入到自助分析平台中。需要支持传统的关系型数 据库、Hive、文件导入（Excel、CSV、TXT 等）。
多维度分析
能够对导入的数据进行快速查询、过滤、聚合、排序、关联等动态操作。比方业 务人员已经有一些用户基本信息，它能够通过导入用户名，通过用户名关联到对 应的用户分析数据。并能够对不同类型的用户进行分组聚合操作。以上所有的操 作需要实现拖拽式，不需要让业务人员写一行代码。
丰富的可视化
需要支持常用的可视化图形，如饼状图、环图、同轴曲线图、柱状图、散点图等， 用户需要绑定自己导入或者通过平台清洗好的数据，既可以快速的生产对应的分 析图表，制作可视化报告。
权限管控
自助分析平台是对公司所有的业务人员使用的，需要有对应的权限管控。比方A 用户制作的数据图表，B用户是不能够查看的，只有A赋权给B后才能查看。自 助分析平台中的数据也要进行权限管控，比方敏感数据不能开放所有用户，下载 数据需要有流程审批等等。
高性能
数据分析查询要快、自助分析要快、可视化要快。很多自助分析平台最终变成了 数据下载平台，其中很大一局部原因就是不够快，虽说大数据了比Excel快多了， 但是实际业务探索中，很多时候数据量就是百万以内的，要是还没有Excel快的 话，人家为什么要用你的平台呢？所以，不管是数据量大，还是数据量小，都要 快！在技术上是否要考虑大数据量和中小数据量使用不能的查询计算引擎呢？
03自助分析平台架构
数据应用
可视化
(Echarts)
自助分析平台
报表
自助分析引擎
ETL力口载
原始数据
Oracle/MySql
Hive

自助分析引擎对于超大数据量的复杂查询分析，我们可以使用Spark提交任务的方式来实现自 助分析。对于中小数据量的数据我们使用MPP数据库实现快速查询。
可视化我们可以使用echarts支撑多种类型图表展示，或者使用superset等开源自助分 析工程进行展示。
权限 为做到相互隔离和数据平安，后台管控系统通过条件限制控制数据的授权，对手 机号、身份证号、邮箱等敏感信息管控端采用加密算法防止数据泄露。
04总结实际中业务人员和IT团队对于自助分析平台的搭建都有自己的想法，也想通过数 据来给公司去做一些事情，所以在建立自助分析平台时，可以和业务人员不断的 沟通，先定一些主题数据，做成果展示，和业务人员以及领导提供，让其参与评 价和建议，不断优化和改善，当相关人员都有参与感时，自助分析平台才会持久 开展。
最后，还是要提醒一下，自助分析平台的目的是“干掉Excel”，让所有的分析结果 存储在线上，千万不要让其沦为数据下载平台。
SourceWeb Server
SinkChannel
业务数据
库
实时业务数据
库
实时Sqoop抽
取
Canal/binl
og
HiveKafka 消
息队列
离线I Canal/binl
Kafka 消
息队列

02数据存储无论上层采用何种的大规模数据计算引擎，底层的数据存储系统基本还是以 HDFS为主。
HDFS (Hadoop Distributed File System)是 Hadoop 工程的核心子工程，是分 布式计算中数据存储管理的基础。具备高容错性、高可靠、高吞吐等特点。
本地磁盘
NameNode
元数据
Secondary NamcNodc I
NameSpace
State
Block
Map
NamcNodc

Heartbeat &
BlockReport
回回 回
回回
回回 回

9 0S
DataNodeDataNodc
DataNode

HDFS存储的是一个个的文本，而我们在做分析统计时，结构化会方便需要。因 此，在HDFS的基础上，会使用Hive来将数据文件映射为结构化的表结构，以便 后续对数据进行类SQL的查询和管理。
03数据处理数据处理就是我们常说的ETLo在这局部，我们需要三样东西：计算引擎、调度 系统、元数据管理。
对于大规模的非实时数据计算来讲，目前一样采用Hive和spark引擎。Hive是基 于MapReduce的架构，稳定可靠，但是计算速度较慢；Spark那么是基于内存型的 计算，一般认为比MapReduce的速度快很多，但是其对内存性能的要求较高， 且存在内存溢出的风险。Spark同时兼容hive数据源。从稳定的角度考虑，一般 建议以Hive作为日常ETL的主要计算引擎，特别是对于一些实时要求不高的数 据。Spark等其他引擎根据场景搭配使用。
实时计算引擎方面，目前大体经过了三代，依次是：storm> spark streaming> Flinko Flink已被阿里收购，大厂一直在推，社区活跃度很好，国内也有很多资源。
调度系统上，建议采用轻量级的Azkaban, Azkaban是由Linkedin开源的一个批 量工作流任务调度器。一般需要自己开发一套元数据管理系统，用来规划数据仓库和ETL流程中的元数 据。元数据分为业务元数据和技术元数据。
业务元数据，主要用于支撑数据服务平台Web UI上面的各种业务条件选项，比 如，常用的有如下一些：移动设备机型、品牌、运营商、网络、价格范围、设备 物理特性、应用名称等。这些元数据，有些来自于基础数据部门提供的标准库， 比方品牌、价格范围等，可以从对应的数据表中同步或直接读取；而有些具有时 间含义的元数据，需要每天通过ETL处理生成，比方应用信息。为支撑应用计算 使用，被存储在MySQL数据库中；而对于填充页面上对应的条件选择的数据， 那么使用Redis存储，每天/月会根据MySQL中的数据进行加工处理，生成易于快 速查询的键值对类数据，存储到Redis中。
技术元数据，主要包括数据仓库中的模型说明、血缘关系、变更记录、需求来源、 模型字段信息等

数据存储信息
权限
血缘关系变更记录
04数据流转

数据源一采集侗步一数据仓库etl
数据分析/ 数据挖掘分析报告
通过上面一张图了解数据采集，数据处理，到数据展现的数据流转。通常我们在 实际工作中，从数据源到分析报告或系统应用的过程中，主要包括数据采集同步、 数据仓库存储、ETL、统计分析、写入上层应用数据库进行指标展示。这是最基 础的一条线，现在还有基于数据仓库进行的数据分析挖掘工作，会基于机器学习 和深度学习对已有模型数据进一步挖掘分析，形成更深层的数据应用产品。
05数据应用俗话说的好，“酒香也怕巷子深”。数据应用前面我们做了那么多工作为了什么，对 于企业来说，我们做的每一件事情都需要表达出价值，而此时的数据应用就是大 数据的价值表达。数据应用包括辅助经营分析的一些报表指标，商城上基于用户 画像的个性化推送，还有各种数据分析报告等等。
02数据采集系统01 “大”数据
海量的数据
当你需要搭建大数据平台的时候一定是传统的关系型数据库无法满足业务的存储 计算要求了，所以首先我们面临的是海量的数据。
复杂的数据复杂数据的概念和理想数据完全相反。所有数据集都有一定的复杂性，但有一些 天生更难处理。通常这些复杂数据集没有定义结构（没有行列结构），经常变化，数 据质量很差。比方更新的网页日志，json数据，xml数据等。
高速的数据高速数据通常被认为是实时的或是准实时的数据流。数据流本质上是在生成后就 发给处理器的数据包，比方物联网的穿戴设备，制造业的传感器，车联网的终端 芯片等等。处理实时数据流有很多挑战，包括在采集时不丧失数据、处理数据流 中的重复记录、数据如何实时写入磁盘存储、以及如何进行实时分析。
02采集工具日志采集
我们业务平台每天都会有大量用户访问，会产生大量的访问日志数据，比方电商 系统的浏览，加入购物车，下订单，付款等一系列流程我们都可以通过埋点获取 到用户的访问路径以及访问时长这些数据；再比智能穿戴设备，实时都会采集我 们的血压、脉搏、心率等数据实时上报到云端。通过分析这些日志信息、，我们可 以得到出很多业务价值。通过对这些日志信息进行日志采集、收集，然后进行数 据分析，挖掘公司业务平台日志数据中的潜在价值。为公司决策和公司后台服务 器平台性能评估提高可靠的数据保证。系统日志采集系统做的事情就是收集日志 数据提供离线和在线的实时分析使用。目前常用的开源日志收集系统有Flume. Logstash. Filebeato可以根据自己公司的技术栈储藏或者组件的优缺点选择合适 的日志采集系统，目前了解到的Flume使用的比拟多。各个采集工具的比照方下：
数据库抽取企业一般都会会使用传统的关系型数据库MySQL或Oracle等来存储业务系统数 据。每时每刻产生的业务数据，以数据库一行记录的形式被直接写入到数据库中 保存。
大数据分析一般是基于历史海量数据，多维度分析，我们不能直接在原始的业务 数据库上直接操作，因为分析的一些复杂SQL查询会明显的影响业务数据库的效 率，导致业务系统不可用。所以我们通常通过数据库采集系统直接与企业业务后 台数据库服务器结合，在业务不那么繁忙的凌晨，抽取我们想要的数据到分析数 据库或者到HDFS上，最后有大数据处理系统对这些数据进行清洗、组合进行数 据分析。
常用数据库抽取工具: 阿里开源软件：DataX
DataX是一个异构数据源离线同步工具，致力于实现包括关系型数据库 （MySQL、Oracle 等）、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之 间稳定高效的数据同步功能。开源的DataX貌似只能单机部署。
Apache开源软件：Sqoop
Sqoop（发音:skup）是一款开源的工具，主要用于在HADOOP（Hive）与传统 的数据库（mysql、postgresql…）间进行数据的传递，可以将一个关系型数据库（例 如：MySQL ,Oracle ,Postgres等）中的数据导进到Hadoop的HDFS中,也可以 将HDFS的数据导进到关系型数据库中。可以集群化部署。
爬虫爬取有很多外部数据，比方天气、IP地址等数据，我们通常会爬取相应的网站数据存 储。目前常用的爬虫工具是Scrapy,它是一个爬虫框架，提供给开发人员便利的 爬虫API接口。开发人员只需要关心爬虫API接口的实现，不需要关心具体框架 怎么爬取数据。Scrapy框架大大降低了开发人员开发速率，开发人员可以很快的 完成一个爬虫系统的开发。
03数据存储HDFS
2003 年，Google 发布论文 GFS,启发 Apache Nutch 开发了 HDFS。2004 年, Google 又发布 了论文 < MapReduce: Simplified Data Processing on Large Clusters》,Doug Cutting等人实现计算框架MapReduce ,并与HDFS结合来 更好的支持该框架。2006年工程从Butch搜索引擎中独立出来，成为了现在的 HadoopoGFS隐藏了底层的负载均衡，切片备份等细节，使复杂性透明化，并提供统一的 文件系统接口。其本钱低，容错高，高吞吐，适合超大数据集应用场景。
HDFS原理:横向扩展，增加“数据节点”就能增加容量。
增加协调部门，“命名节点”维护元数据，负责文件系统的命名空间，控