数据平台 & 数据采集全流程刨析 & 面试准备tip - 20181227
数据平台
- 为什么建设数据平台？
当公司业务多元化，有多条业务线，如oms、wms、bms、tms、erp、oa十几种业务系统，导致需求变化多。
数据生命周期：产生(业务系统库mysql，tms，日志存储)，传输(中间件Kafka)，入库(HDFS --> hive + hbase)，'统计、分析、挖掘'(Spark、Flink)
基础平台的稳定性。
- 架构1.0版本
初期单纯的是，MySQL通过Sqoop1/Datax[Sqoop1启map job,要走yarn流程；DataX性能较高，类似Flume，可以实现异构数据源之间高效的数据同步功能]，将数据写入HDFS/Hive中。
log日志则是Flume采集，将数据写入HDFS。
之后，通过airflow[调度分析平台，python + shell脚本书写的hive sql/简单的Azkaban只写hive sql即可]，注意：airflow与正常理解的调度不同，它调度的批次是上一个调度，即有延迟性，需要人为控制；所以它的坑较多，就是将hive sql写到sql文件中，指定成shell脚本封装调度；然后数据回写到Mysql，之后Mysql数据进行自定义开发报表处理[Superset，优秀的数据可视化效果，支持"上卷下钻",就是操作指指点点就能拼成sql查询发向后台]。
综上，底层其实就是Hadoop，用来存储与分析数据：将mysql和log日志传输到hadoop平台，利用的是flume或是其他的组件，再经过airflow进行调度，开发者书写hive sql完成业务需求，之后将数据写到mysql当中。
存在问题：架构简单，解耦差，查询纠错难，复杂度较高；易发生故障(hive相关问题)；架构功能单一，只做到了取数据。
- 架构2.0 数据平台1.0
第五层：使用层：数据平台、报表、数据产品、对接业务线
第四层：API层：
业务API、数据平台API、
第三层，工具层：
核心☆MetaData[哪些源，哪些库，哪些表，哪些字段，就是拿到表结构，n张表；
表的总数据量 日数据量，均值，高峰期，低谷期；
表的总数据量–相等代表数据没有丢失，不相等发邮件，微信，钉钉，发短信–自动触发job刷数据再次比对，ps在邮件发送html
日数据量–热表/冷表–揪出异常][类似Hive]
等等等…
ETL Job[产生的数据，回写到HBase、新写Redis和ES]
ADHOC[数据报表引擎]
第二层，存储层：实时数据仓库HBase + Phoenix
[HBase的表做QPS限流处理]
第一层，采集层：实时中间件[解决数据延时性，Canal/Maxwell + Flume(flume保证数据零丢失)]，数据来源于Mysql和(80%)log日志
数据采集全流程刨析
Flume完成日志采集(beats也可以)
一个Flume配一个Agent，一个Agent由三个组件构成，Source、Channel、Sink
在多台机器上部署Agent，采集WebServer的数据，采用AvroSource形式接收，在用AvroSink形式，写到其他Agent的AvroSource中去；123的数据聚合到4机器上。这种架构的问题是：Sink挂掉会导致Source采集数据浪费了；4的sink挂掉导致数据堆积在channel4中，导致内存或磁盘数据堆积挂掉，导致整个flume采集挂掉，导致离线崩盘；即使是实时的也一样挂掉，因为没有数据能传到kafka streaming等等
从client采集数据，
数据传输单位是event，source到channel之中会有Interceptor拦截器[常用TimeStamp、Host]和channel Selector[常用几种：default'Replicating多路复制'和Multiplexing根据指定header去到对应channel，相当于广播和轮询 ]；之后channel到sink之间，经过sinkProcessor[常用默认，failover和loadbalance]，综上可以保证理论上的数据零丢失。
设计Agent技术选型
source： exec/taildir：tail -F (taildir功能更强大，可以周期性拿到读写位置，将位置存储为json，就是偏移量形式非常友好)
channel：memory/kafka/file需要根据需求来选
sink：离线hdfs，实时kafka
面试准备
大数据日志采集，数据的清洗，先通过kafha在去向HBase，kafka可以做到异步、解耦、削峰填谷，kafka在项目中的应用是与flume做对接，一些实时统计可以利用kafkaStreaming统计，推荐基于kafka统计新用户，采集用户行为打分，再调用mahout工具类；书写mapreduce对推荐数据再进行一下过滤，防止数据无效，之后将数据写入传统数据库，传统业务推荐列表。