步骤一：
| 我们的数据从哪里来？ 互联网行业：网站、app、系统（交易系统。。） 传统行业：电信，人们的上网、打电话、发短信等等数据
数据源：网站、app
都要往我们的后台去发送请求，获取数据，执行业务逻辑；app获取要展现的商品数据；发送请求到后台进行交易和结账 |
连接线（网站/app会发送请求到后台服务器，通常会由Nginx接收请求，并进行转发）
步骤二：
| 后台服务器，比如Tomcat、Jetty；但是，其实在面向大量用户，高并发（每秒访问量过万）的情况下，通常都不会直接是用Tomcat来接收请求。这种时候，通常，都是用Nginx来接收请求，并且后端接入Tomcat集群/Jetty集群，来进行高并发访问下的负载均衡。
比如说，Nginx，或者是Tomcat，你进行适当配置之后，所有请求的数据都会作为log存储起来；接收请求的后台系统（J2EE、PHP、Ruby On Rails），也可以按照你的规范，每接收一个请求，或者每执行一个业务逻辑，就往日志文件里面打一条log。 |
连接线（到这里为止，我们的后台每天就至少可以产生一份日志文件，这个是没有疑问了）
步骤三：
| 日志文件（通常由我们预先设定的特殊的格式）通常每天一份。此时呢，由于可能有多份日志文件，因为有多个web服务器。 |
连接线（一个日志转移的工具，比如自己用linux的crontab定时调度一个shell脚本/python脚本；或者自己用java开发一个后台服务，用quartz这样的框架进行定时调度。这个工具，负责将当天的所有日志的数据，都给采集起来，进行合并和处理，等操作；然后作为一份日志文件，给转移到flume agent正在监控的目录中。）
步骤四：
| flume，按照我们上节课所讲的；flume agent启动起来以后，可以实时的监控linux系统上面的某一个目录，看其中是否有新的文件进来。只要发现有新的日志文件进来，那么flume就会走后续的channel和sink。通常来说，sink都会配置为HDFS。 |
连接线（flume负责将每天的一份log文件，传输到HDFS上）
步骤五：
| HDFS，Hadoop Distributed File System。Hadoop分布式文件系统。用来存储每天的log数据。为什么用hadoop进行存储呢。因为Hadoop可以存储大数据，大量数据。比如说，每天的日志，数据文件是一个T，那么，也许一天的日志文件，是可以存储在某个Linux系统上面，但是问题是，1个月的呢，1年的呢。当积累了大量数据以后，就不可能存储在单机上，只能存储在Hadoop大数据分布式存储系统中。 |
连接线（使用Hadoop MapReduce，自己开发MR作业，可以用crontab定时调度工具来定时每天执行一次；也可以用Oozie来进行定时调度；也可以（百度、阿里、腾讯、京东、美团）自己组建团队来研发复杂、大型、分布式的调度系统，来承担全公司所有MapReduce / Hive作业的调度（对于大型公司来说，可能每天除了负责数据清洗的MR作业以外，后续的建立数据仓库、进行数据分析和统计的Hive ETL作业可能高达上万个，上十万、百万个），针对HDFS里的原始日志进行数据清洗，写入HDFS中另外一个文件）
步骤六：
| Hadoop HDFS中的原始的日志数据，会经过数据清洗。为什么要进行数据清洗？因为我们的数据中可能有很多是不符合预期的脏数据。
HDFS：存储一份经过数据清洗的日志文件。 |
连接线（把HDFS中的清洗后的数据，给导入到Hive的某个表中。这里可以使用动态分区，Hive使用分区表，每个分区放一天的数据。）
步骤七：
| Hive，底层也是基于HDFS，作为一个大数据的数据仓库。数据仓库内部，再往后，其实就是一些数据仓库建模的ETL。ETL会将原始日志所在的一个表，给转换成几十张，甚至上百张表。这几十，甚至上百张表，就是我们的数据仓库。然后呢，公司的统计分析人员，就会针对数据仓库中的表，执行临时的，或者每天定时调度的Hive SQL ETL作业。来进行大数据的统计和分析。 |
连接线（Spark/Hdoop/Storm，大数据平台/系统，可能都会使用Hive中的数据仓库内部的表）
步骤八：
| 我们的Spark大型大数据平台/系统（比如我们这套课程要讲解的这个），其实，通常来说，都会针对Hive中的数据来进行开发。也就是说，我们的Spark大数据系统，数据来源都是Hive中的某些表。这些表，可能都是经过大量的Hive ETL以后建立起来的数据仓库中的某些表。然后来开发特殊的，符合业务需求的大数据平台。通过大数据平台来给公司里的用户进行使用，来提供大数据的支持，推动公司的发展。 |