技术架构: Nginx-1.12.2+Flume-1.7.0+Kafka-0.11.0+Spark2.1.1
+Mysql-5.7.16+ZooKeeper-3.5.7+Hadoop-2.7.2
项目背景：公司的各种 app 总安装量过亿,但是运营很长时间,用户的行为数据的积累几乎为 0,最后呈现的数据
就几张莫名奇妙的报表。对于一个互联网公司,对所有的数据有绝对的控制权,才是最合适的。针对于这种前提
下, 决定创建一个私有化部署的产品,可以部署在客户的内网，技术选型上选择热门的开源技术，同时在数据处
理从采集、传输、查询的各个环节提供普适易用的接口，降低客户的开发代价。
项目架构设计:
1 全端数据采集
因为一个用户在同一个产品上的行为，需要在多个来源进行采集，这些来源包括 IOS、安卓、Web、
H5、微信、业务数据库、客服系统等。不仅仅需要采集到，还需要能够将同一个用户在不同来源的数
据进行打通。
针对这样的场景，决定采用全端的数据采集方案，需要包括主流的客户端平台和 Restful 风格的数据导
入 API，全埋点与可视化埋点等埋点辅助手段。最后还需要提供 ID-Mapping 方面的解决方案。
2 数据接入
将采用开源的 Nginx +Flume+Kafka 来实现数据的接入。
选择 Nginx 来接收通过 API 发送的数据,并且将之写到日志文件上。 主要考虑到它的高扩展与高可
靠,易于集成,并且在我们测试下,Nginx 单机可以轻松做到每秒接收 1 万条请求。 考虑到一条请求通常
不止一条用户行为，可以认为很轻松就能做到数万 TPS。
对于 Nginx 打印到文件的日志,会由 Flume 读取和处理 Nginx 日志 ,并将处理结果发送到 kafka。
在 Flume 这个过程中,还会对数据进行格式的效验,属性类型的识别与相关的元数据的操作。
与 ID-Mapping 的处理也是这个阶段完成。字段的解析和扩展的工作,基于 IP 判断国家、省份、城市、
基于 UserAgent 判断游览器、操作系统等，也是这里实现。
Kafka 的选择，作为数据接入与数据处理流程之间的缓冲，同时作为近期数据的一个备份作用。另
外，这个阶段也对外提供 API，客户可以直接从 kafka 中将数据引走,进入自己的计算流。
3 数据储存
存储是建立在 HDFS 上,但是为了满足秒级导入和秒级查询，我们将存储分为 WOS 和 ROS 两部分，
分别为写入和读取进行优化，并且 WOS 中的数据会逐渐转入 ROS 之中。对于 ROS，选择了 Parquet(面
向分析型的列式存储格式)。根据业务具体的查询需求，对数据的分区方式做了很细致的优化。首先按
照日期和事件的名称对数据做Partition，同一个Partition内，会有多个文件，文件大小尽量保持512MB
左右，这里会开启一个 MapReduce 任务,定期合并 Parquet 中每个 Partition 内的碎文件。
虽然 Parquet 是一个查询性能很好的列式存储，但是它是一个不能实时追加的，因此在 WOS 部分，
选择 Kudu。在向 Kudu 中写数据时，选择类似与 0/1 切换的方案，即同一时间只写入一张表，当这张
表的写入达到阈值时，就写入新表中，而老表则会开始转为 Parquet 格式。
4．查询引擎
采用 SparkSQL 的方式访问 Kudu 与 Parquet 数据共同构建的 View，完成对应的聚合和聚散。这
里采用 Redis 进行精细的缓存。
5．元数据与监控
采用 Mysql、ZooKeeper 来维护元数据。主要包括维度字典，数据概括，预测的配置、任务调度、
权限等信息。
6．数据模型
Event+User 模型
每一条 Event 数据对应用户的一次事件，由用户 ID、Event 名称、自定义属性三部分组成。User
则主要描述用户是什么样的人。ID 和自定义属性组成。
个人职责：1.负责将各个来源的数据源的日志数据进行抽取并对其标准化进行存储。
2.对采集的数据进行数据格式的效验,属性类型的识别,并将数据进行分区和读写分离操作。
3.维护管理 Kudu,完成 0/1 切换的方案。
4.实现数据模型中的各个数仓分层的数据建模，建表。
5.负责实现每个分层的数据抽取、转换、加载。
6.负责编写 shell 实现 sqoop 脚本批量导入数据。
7.负责编排 sqoop 导入数据的任务调度。
8.负责使用 sparksql 进行数据应用层指标进行分析。
9.解决项目中 ThriftServer 资源不足 GC 问题、ThriftServer 单点故障、数据倾斜、数据采集不
一致等突发问题。
10.对集群中资源优化与代码开发优化。