大数据架构和技术选型示例、数据采集层、数据存储层、数据分析层、数据调度层、数据同步层、数据olap存储层、大数据架构和技术选型

1、sdk日志埋点

2、日志文件：爬虫日志、业务日志

3、关系型数据库：mysql、oracle等

1、离线：flume、Sqoop、Nifi 2、实时：filebeat、nginx+lua 补充：当数据量达到5亿左右的时候，filebeat+logstash采集数据到hdfs，数据会出现丢失的情况，所以此种方案不适合用于大数据存储到hdfs

1、hdfs用于存储离线大数据量 2、kudu用于存储mysql关系数据库更新变化的数据 3、es存储一些log日志，比如说我们需要快速的定位某一个业务的log情况 4、kafka作为消息中间件，存储filebeat或者是flume采集的日志

1、es，分析一些log 2、hive适用于分析一些离线大数据（基于磁盘IO分析） 3、impala、presto适用于分析一些准实时日志（要求快速出数据，基于内存分析） 4、spark core+spark sql 适用于分析一些离线数据，自定义解析规则 5、spark streaming适用于分析一些实时（不是完全实时）数据 6、flink、jstorm进行分析完全实时的数据

1、airflow：使用于大集群，阿里的调度系统就是根据airflow二次开发，配置复杂，python脚本实现 2、azkaban：cpu和内存要求不高，主从配置支持的不算太好，适用于小集群，以job的文件实现，配置简单 3、oozie：通常hue集成，单独的使用oozie的情况下，配置及其复杂，不建议使用，所有的任务是以mr的形式进行的，可支持复杂的依赖调度 4、jobX：cpu使用高，bug还没修复，所以造成agent的cpu维持在1个左右，配置简单，只支持依赖调度，并行调度不支持 5、crontab：一般用于每分钟调度一次的任务，不支持依赖调度、并行调度（配置复杂，通过脚本自定义控制），没有可视化界面，不能准确的判断任务是否成功或者是失败…

6、NiFi

7、自定义，公司自己开发使用的

1、sqoop用的是1.x系列版本 2、datax

3、kettle

4、NiFi

mysql、es、tidb、redis、hbase、clickhouse

补充：有时间的话去研究一下tidb和clickhouse

PowerBI、帆软等BI可视化工具、前端定制开发。

​ 可以使用lua或者filebeat将nginx数据采集到kafka，数据经过spark streaming或者是jstorm进行分析后，尽可能的存入一些高吞吐量的数据库（非关系型），但是有时必须要存入一些关系型数据库，比如说mysql，但是spark streaming发现仅仅通过一个map操作，每个执行的batch的时间，就超过我们所设置的batch时间，这时候我们需要一个措施，增加一个缓冲层，不直接mysql或者是redis，先写入kafka，然后通过kafka推送到独立的写入服务，这样会发现实时处理服务的时间明显的降低。

采集这块用flume的tailf形式，或者使用sqoop和nifi。

数据分析使用Hive、SparkSql，数据存储使用HDFS。

最终将数据导出到mysql等常用的关系型数据库当中。