感谢关注转发，知识在于积累

行业业务背景

目前会员业务在购物中心中占据很重要的一部分业务，未来也是购物中心运营着重发力的一个点，怎么对会员进行精准营销，怎么刺激会员在购物中心进行消费，是重点也是难点，针对会员精准营销，则需要对会员进行全方位的分析，包括年龄爱好分析，消费分析，以及日常习惯分析等，目前很多做购物中心会员系统的服务商来说，会员画像(即人群/标签)这块一直处于文档方案阶段，怎么落地，怎么做到会员精准分析的目前没几家，在此基础上，针对购物中心所采集到的数据，进行会员画像的精准分析，则更加迫切

会员人群/标签的画像分析，难点在于规则的复杂多样性以及大数据量的统计计算，本文是技术方案讨论，不是产品需求落地，针对公司具体的业务以及数据量探讨合适的技术方案

技术方案背景

1，以单个客户的数据进行分析，单表数据量不超过1千万， 合计分析的表数据不超过5千万，供人群/标签分析的表结构不超过50个，单客户的人群/标签定义不超过100个，要求批量定时计算任务不能超过2小时，实时计算任务需要在200毫秒以内出结果

2，需要控制机器成本，实施成本，开发成本等

方案分析

整体来说基于会员人群/标签等画像分析，有两个部分组成

规则定义基于规则的数据分析计算

一，规则定义

每个购物中心对会员的人群/标签分析规则不一定一致，比如针对标签《购物狂魔》，A广场定义规则为每月消费4笔则定义为《购物狂魔》，而B广场定义规则为每月消费10000元以上为《购物狂魔》，故规则具有动态变换的性质，需要支持自定义

目前市面上有一些针对规则这块专门的软件，即规则引擎，

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

比如开源的Drools,基于JAVA和RATE算法的产生式规则引擎实现, 但规则配置较为复杂，可能需要开发介入；

收费的规则引擎，包括 URULE,Visual Rules等，规则配置界面较友好

开源的规则引擎大部分都具有这么一种特点，规则的定义较为复杂，规则定义语言包括sql，xml，自定义语言等，很多规定定义需要开发介入，不建议推荐

目前可以参考收费的规则引擎定义方式，定义规则较为简单，可参考其设计方式自研处理

二，基于规则的数据分析计算

基于会员的人群/标签分析，整体来说所有的人群/标签理想情况下都可以在使用的情况下进行计算，但这样的计算会对整个系统负载压力非常大，比如将生肖属虎的会员定义为一个标签A，每次根据标签A查询的会员都需要进行数据计算，对存储以及计算的压力都是非常大的，实际上这种标签对于存量数据来说只需要计算一次，不需要每次查询使用的时候都进行计算，故将整个人群/标签分析从两个维度来进行计算

1：规定频率定时计算

定时计算的场景，比如会员后台批量自动循环发券，针对的会员发券群体的标签是《消费狂魔》，标签定义是《这个月消费满4笔》，则需要将当月的所有消费数据进行计算，除了当天的消费数据，历史的消费数据都可通过定时计算来进行筛选，定时计算的结果存到mysql或者es中，发券时直接查定时计算的结果即可

2：实时计算

上述《消费狂魔》标签的数据，当天的数据统计需要实时计算，即来一笔消费则计算一次，用来实时判断是否有新的会员符合《消费狂魔》标签，故是实时计算

整体来说数据分析计算从软件流程的角度来说分三块

数据源计算结果存储

数据源

mysql与hbase的选择

hbase

是一个分布式的、面向列的开源数据库，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。

HBase是一个面向列的数据库，

row key是用来表示唯一一行记录的主键，HBase的数据时按照RowKey的字典顺序进行全局排序的，所有的查询都只能依赖于这一个排序维度。访问HBASE table中的行，只有三种方式：

通过单个row key访问；通过row key的range（正则）全表扫描(性能较低)

优点

列式存储，针对row key查询效率非常高

分布式数据库，支持水平扩展，支持存储的数量量非常大，

稳定性高，单个region分区挂了之后会再找一个节点来代替

缺点

对复杂的业务查询性能一般

需要较多的技术研究投入

mysql

关系型数据库

优点

支持复杂的业务查询

不需要大的技术投入，对于开发人员都比较熟悉

针对小数据量的项目，不需要额外的机器资源

缺点

吞吐量差，当数据量级上升之后需要进行分库分表分区等操作，实践起来对业务侵入非常大

结论

如果简单业务查询可以用hbase，查询复杂的话还是mysql，实际上针对我们的业务使用场景，单表数据量在千万以下，mysql是可以顶住的

当单个mysql数据库有负载压力时，考虑以下的优化方案

mysql配置优化，包括硬件，网络，mysql自身配置等索引优化采用一主一从或者一主多从架构方式，所有的人群/标签数据计算来源都取从库数据，并支持分库查询

数据分析计算

数据分析计算是一个难点，我们传统的处理方式可能就是在单应用上开启多线程处理，考虑到数据量以及以后的扩展性，故准备选型大数据计算引擎

目前开源大数据计算引擎有很多选择，流计算如Storm,Samza,Flink,Kafka Stream等，批处理如Spark,Hive,Pig,Flink等。而同时支持流处理和批处理的计算引擎，只有两种选择：一个是Apache Spark，一个是Apache Flink。目前暂以分布式计算框架 spark streaming以及flink来进行选型分析

spark streaming

Spark Streaming 是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。支持从多种数据源获取数据，包括Kafka、Flume、Twitter、ZeroMQ、Kinesis 以及TCP sockets等，从数据源获取数据之后，可以使用诸如map、reduce、join和window等高级函数进行复杂算法的处理。最后还可以将处理结果存储到文件系统，数据库和现场仪表盘。在“One Stack rule them all”的基础上，还可以使用Spark的其他子框架，如集群学习、图计算等，对流数据进行处理。

Spark Streaming是Apache Spark之上支持流处理任务的子系统，看似一个特例，实则不然——Spark Streaming采用了一种micro-batch的架构，即把输入的数据流切分成细粒度的batch，并为每一个batch数据提交一个批处理的Spark任务，所以Spark Streaming本质上还是基于Spark批处理系统对流式数据进行处理

优点：

社区活跃，参考资料较多

Spark Streaming是小批处理，故吞吐量大

计算性能较高

缺点：

实时性支持不好，因为是小批量作业方式处理，不是事件驱动机制

flink

Flink核心是一个流式的数据流执行引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务

支持高吞吐、低延迟、高性能的流处理支持带有事件时间的窗口（Window）操作支持有状态计算的Exactly-once语义支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作支持具有Backpressure功能的持续流模型支持基于轻量级分布式快照（Snapshot）实现的容错一个运行时同时支持Batch on Streaming处理和Streaming处理Flink在JVM内部实现了自己的内存管理支持迭代计算支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存

阿里，饿了么，uber等多家企业正在使用，阿里在flink的基础上自研出blink，

优点

基于事件驱动机制，实时性非常好吞吐量大流计算性能非常高一个任务运行时同时支持Batch on Streaming处理和Streaming处理可能是未来流计算的标准，以及大数据的未来

缺点

flink正处于发展中，参考资料较少，技术研究投入会比较大

结论

1：如果选型spark streaming，则定时计算采用spark streaming，实时计算采用自研处理

2：如果选型flink，则定时计算与实时计算都交由flink处理，

暂选型flink

结果存储

mysql/elasticSearch的选择

elasticsearch

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,

es适合文档类数据存储，比如日志等，全文检索效率非常高，当然基于索引查询效率也非常高

elasticsearch是分布式的，故可水平扩展，支持存储大数据量的数据

目前暂考虑用mysql，原因有以下几点

结果存储的表具有非常明显的索引查询特征，mysql基于索引查询效率还是不错的，当然相对于ES可能不占优势机器成本，开发成本，实施成本等方面，mysql具有优势，可直接在业务库实例上进行处理以200万会员，每个会员标签在10个以上的数据量进行分析，结果数据可能在千万以上，此时可考虑将结果进行分表分库

回到文章开始的两种计算方式

定时计算

定时计算不要求具备实时性，但需要在较短时间内执行完成， 比如每天晚上执行一次的定时计算，则必须2小时内全部计算完成，定时计算job最好选在凌晨执行

实时计算

需要实时计算的数据具有一个显著的特征，即特征主键，比如一笔会员消费交易上来，需要实时计算出这个会员是否满足上述标签《消费狂魔》，如果满足，则触发送券送积分等营销规则。这种数据带有明显的特征主键字段就是会员id，通过会员id这种主键或索引查询mysql表数据是非常快的，故是可以做到实时计算的；