离线数据采集流程

我们的数据从哪里来？
互联网行业：网站、app、系统（交易系统。。）
传统行业：电信，人们的上网、打电话、发短信等等数据
数据源：网站、app(pc端，移动端)
都要往我们的后台去发送请求，获取数据，执行业务逻辑；app获取要展现的商品数据；发送请求到后台进行交易和结账
网站/app会发送请求到后台服务器，通常会由Nginx接收请求，并进行转发

后台服务器，比如Tomcat、Jetty；但是，其实在面向大量用户，高并发（每秒访问量过万）的情况下，通常都不会直接是用Tomcat来接收请求。这种时候，通常，都是用Nginx来接收请求，并且后端接入Tomcat集群/Jetty集群，来进行高并发访问下的负载均衡。
比如说，Nginx，或者是Tomcat，你进行适当配置之后，所有请求的数据都会作为log存储起来；接收请求的后台系统（J2EE、PHP、Ruby On Rails），也可以按照你的规范，每接收一个请求，或者每执行一个业务逻辑，就往日志文件里面打一条log。

mysql层面分表优化，支付宝口碑面试
点击一个商品会有数据插入数据库,大量用户点击会造成单表负载高,如何分表达到负载
（用户点击的商品行为数据会记录下来，通常选择用mysql去接收，如何做到分表让数据存储均衡，不会导致一台机器或表负载过高？
分表的方法有多种，1根据用户id进行范围分表，1-1000的在A表，1001-2000的在B表，优点：可部分迁移，缺点：数据分布不均。2根据商品id或者user_id取模分表，比如分100张表，1/100=1放A表，2/100=2放B表，优点：数据分布均匀，缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据。3根据时间戳分表，比如8点-9点间访问的放在A表，1点到两点访问的放B表。3hash分表，针对商品id做hash，为了降低负载可以设定一个中间库用来存储当前用户访问商品的信息存储在哪个库下面的，查询前先去查询这个库获取信息后再去查询事实表。不过这样有失性能，优点：灵活性强，一对一关系，缺点：每次查询之前都要多一次查询，性能大打折扣）

到这里为止，我们的后台每天就至少可以产生一份日志文件，这个是没有疑问了
日志文件（通常由我们预先设定的特殊的格式）通常每天一份。此时呢，由于可能有多份日志文件，因为有多个web服务器。
一个日志转移的工具，比如自己用linux的crontab定时调度一个shell脚本/python脚本；或者自己用java开发一个后台服务，用quartz这样的框架进行定时调度。这个工具，负责将当天的所有日志的数据，都给采集起来，进行合并和处理，等操作；然后作为一份日志文件，给转移到flume agent正在监控的目录中。

数据采集也是重要环节
其中重要的一个重要的数据手机点就是日志文件的采集，比如用NSLogger ，Logkafka
http://www.oschina.net/project/t ... ng=21&sort=view

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以后建立起来的数据仓库中的某些表。然后来开发特殊的，符合业务需求的大数据平台。通过大数据平台来给公司里的用户进行使用，来提供大数据的支持，推动公司的发展。

数据源——>Flume、Kafka数据采集——>HDFS存储——>数据清洗——>ETL流程作业——>导入Hive数据仓库存储——>Hadoop/Spark大数据平台进行数据分析——>应用平台——>用户