O2O中客户主数据、数据仓库和大数据

在O2O项目中强调电子化和数字化，因此数据是个很关键的基础工作。而围绕数据，那么经常提到的客户主数据和数据仓库、大数据是什么关系呢？今天我们简单来聊聊，帮助大家理顺一下思路。

O2O强调的是客户体验，所有的流程和场景都离不开人，都是以人为本。所以，O2O项目中，对人的数据非常关注，尤其是用户的主数据模型的设计，以及对应主数据模型的数据采集、用户ID的统一等等，而基于主数据模型进行ID统一和主数据采集的，可以称之为“统一客户数据管理”，我们一般简称为UCM（Universal Customer Master）。

在对人进行统一后，基本上是形成大会员系统，通过会员ID进行统一和唯一识别，这样形成了对客户的主数据（基础数据）的统一。但是企业一定是需要对整体业务数据的分析，这就意味着要建立DW（DataWarehouse）数据仓库，在DW里面进行数据的抽取清洗完善，并进行建模和分析，形成不同主题的数据集市，再通过BI工具进行统计分析展现和数据可视化。

但由于当前企业的数据量越来越大，而且非结构化数据越来越多，对非结构化数据的处理需求也越来越紧迫；同时海量的结构化数据当数据量增长到10TB以上，可能就会遇到性能瓶颈，这时候就需要构建大数据平台如Hadoop或者类似Spark等平台进行重构。

实际上，大数据平台不是万能的，它的优势在于海量数据的存储和运算，但不善于对结构化数据的业务和事务处理。所以，类似Hadoop大数据平台适合做大数据量的存储、ETL和运算，但不适合做企业的业务系统和事务处理。

如果企业既要做业务系统，又需要海量数据和高并发，那么这种情况不要采取大数据平台，而是可以采用内存数据库+内存计算的技术，可以实现大数据量的业务系统。比如12306的系统平台，以前经常死机卡顿，但现在明显感觉快多了不死机了吧？就是因为用了内存数据库和内存缓存计算技术。而内存数据库技术，类似SAP的HANA和Oracle的内存数据库，都是可以考虑的。

同样，大数据在查询统计上也不如关系型数据库。大数据平台因为结构不同，所以对一条数据的查询和对数万条数据的查询可能都是一个效率，而关系型数据库当对处理后的小数据量的查询特别快。因此，统计分析时会选择一个方式：大数据平台将数据清洗整理运算之后，加载到一个关系型数据库，再通过SQL或者BI工具进行统计分析展现，这样效率最高。

是不是太专业了？说到底，一个合理的大数据平台的架构可能是：

针对关系型数据库，建立企业统一的ETL机制和接口规范，按照统一规则或者基于企业数据总线对接全部业务系统，抽取清洗数据源后到数据源历史库，再分别根据UCM的需要加载或者平抽到UCM的临时库、根据DW的需要抽取到数据仓库的ODS。

针对非结构化数据，通过大数据平台进行海量数据收集、归档和索引。并提供专用的大数据查询工具满足常规数据查询和动态的数据分析。尤其要确保既能满足实时的数据细节获取也能满足批量的与关系型DW的数据同步。

UCM在大数据平台上清洗整理合并后形成UCM基表库，根据需要加载到关系型数据接口准备主数据分发服务，服务的对象包括业务系统、企业数据仓库和数据集市、以及大数据平台。分发的渠道则仍是统一的ETL平台。

数据仓库根据抽取过来的ODS数据进行清洗整理格式化和迁移转换，在DW进行建模和形成数据集市，比如有关联分析、有画像分析、有购物篮分析等等不同主题，最后根据分析的需要将所需数据加载到关系型数据库，通过BI工具进行统计分析和可视化展现，或者实现移动端报表展现