数仓项目背景

添码座原创大约 6 分钟

项目背景

这是很早之前开发过的一个数仓项目，现在将它还原出来，以作记录和分享。

当用户使用PC、APP或者小程序访问电商系统时，会通过埋点接口记录用户行为，这被称之为客户端记录数据。

同理，除了埋点记录的数据，业务系统也会有对应的操作行为，例如，用户下单或者取消支付，这被称之为服务端记录数据。

因此，针对同一个同户行为，可能会有两条数据来记录它，这两种类型的数据虽然都记录的是同一个用户行为，但应用场合是不同的。

客户端记录数据：可满足按分钟级甚至秒级来实时统计用户行为的需求，但统计数据本身可能会有遗失或不够准确，因为它不像业务系统会有各种一致性、完整性和安全性的保证，它适用于查看用户行为趋势，而不是准确的行为结果的汇总与聚合，例如，用户每日的消费总金额。
服务端记录数据：和客户端记录数据应用场景刚好相反，它适用于查看用户行为结果的汇总与聚合，而非行为趋势。例如，用户每日消费的真实的总金额就只能通过业务系统的数据来汇总，而非埋点数据。

为了消除这种不一致，统一客户端记录数据和服务端记录数据，就必须有一个地方能够对平台中所有的数据进行整合，为所有部门和人员提供一个统一的、规范的数据访问入口，让所有基于数据的计算都是基于相同的数据源进行的。

经过这种整合以后，计算出来的各种指标就不会再有不同的结果了。

而且，一个完善且合理的数据仓库也是整个大数据系统中重要的一环，更高层次的数据分析、数据挖掘等工作都会基于数据仓库进行。

基本上，任何数据仓库都需要具备下面这些功能组件。

数据采集组件：采集各种数据源中的数据，例如，MySQL数据、文档数据、日志数据等。通常会用到 Flume、Sqoop、Logstash或Filebeat等中间件，而数据采集方式也有两种。
- 数据本地采集：直接在产生数据的业务服务中采集。例如，直接在订单服务器中部署Flume，采集它产生的日志数据，然后传输到远程数据采集组件里。相对于数据采集组件来说，这是一种推的方式。
- 独立服务采集：部署一台独立的数据采集服务器，专门从多个不同的业务服务中采集数据。相对于数据采集组件来说，这是一种拉的方式。
数据采集方式的技术选型
数据仓库组件：存储和管理采集到的数据。常规组合就是Hadoop + Hive + MySQL。
数据计算组件：对原始数据进行清洗和计算。常规组合就是Hive + Spark（或者Flink、Clickhouse）。
数据可视化组件：以直观的图表方式展现数据。可以选择HUE、Zeppelin或者ECharts等。

典型的数据仓库会划分为如下的几个层级。

这样划分的好处在于。

而在用户行为数仓这个案例中，数据仓库的整体架构设计如下。

因为要统一客户端和服务端的记录数据，所以需要同时对它们进行采集，统一采集到HDFS中。
服务端数据就是商品详情、订单信息之类的数据，这些数据一般都存储在MySQL之类的关系型数据库中，这类数据主要通过Sqoop进行采集。
客户端数据就是用户在网站、APP或小程序等客户端上的滑动、点击、浏览、停留时间之类的用户行为数据，这些数据通常会以埋点的形式直接上报。这种类型的数据没有事务性要求，并且对数据的完整性要求也不高，就算丢失一些数据，对整体结果影响也不大。这类数据主要通过HTTP接口进行传输。
采集到HDFS中的数据在经过ETL清洗后，会将它们输送到Hive里面去。
如果需要报表展示，那么可以再将它们从Hive导出到MySQL，然后利用数据可视化组件来呈现。

对生产环境资源规划的一点说明。

另外补充几点。

关注公众号后回复 数据仓库 即可获得Hive离线数据仓库栏目剩余文章的访问密码。