今天终于喝到了咖啡，感谢当年埃塞尔比亚人的贡献，感谢巴西咖啡研究所在1930年跟雀巢公司的深度合作，感谢麦尔维尔的小说（不敢在技术文章里提及这么商业化品牌的名字，说到这就知道了）。
所有的系统，最重要的环节就是用户（特指用户的信息，从分类到分层，从定义到画像）；用户就是我们最大价值化的资产，了解用户的过程，是一个利用连接载体不断试错的过程，你的链接载体的可触达性越好，对用户就越不构成骚扰，得到的结果就可以更好的帮助你去做真正意义的用户画像。
-第一：别指望用户画像一蹴而就（虽然用户就是静态属性和动态属性）
-第二：别在自己的想象中作用户分层和用户画像（先问问自己是否有相应的领域模型支撑你作用户分层）
今年非常有设计感的包包，个人很喜欢
用户分层：是用在最粗俗的眼光将用户分成三六九等，就是为了降低运营成本，进而用最经济的方式提升转化（当然如果你有的是钱，也可以不做这件事）；而用户画像：是用最精准的方式找到用户的个性所在，然后利用产品力/有效的产品组织及产品特性去刺激用户的购买欲望。想想为什么小红书，花西子，完美日记，元气森林，包括拼多多都能做出这么的用户，道理太简单了，因为人们有欲望，又不愿意任何品类的购买都在淘宝/京东上完成，恰逢这些平台都各自构建了垂直领域中最能和消费者同频的产品力，于是流量就这么来了，需求就被创造出来了。（话说回来，下一波带货的能否集中在某些固定品类上，更专业，更垂直；当然这些跟我一毛钱关系没有）用户分层，RFM足够了，你一下子能找到你高UP值的用户，你可以把他们定位为你的KOC，他们也许不能成为你要的KOL，但确实是你重点运营的客户。怎么做，就两步（定义你的RFM值域，把所有的客户数据都filter一遍）,当然，怎么定义取值范围，相当关键，这跟你的产品定价的中位数有关，而且如果你的产品是季节性的，或者围绕着营销活动进行波动，一定请你们自己的运营负责人帮你定这个值。
import org.apache.spark.rdd.RDD
import org.apache.spark.{SparkConf, SparkContext}
import org.apache.spark.sql.SQLContext
//Sales class map to sales table, which indicates users' historical purchasing records
case class Sales(cu_id: Int, price: Int, date: String, days_ago: Int)
case class RFM(cu_id: Int, r: Int, f: Int, m: Int)
object RFMOnSparkSQL {
def main(args: Array[String]) {
val conf = new SparkConf().setAppName("SQLOnSpark").setMaster("local")
val sc = new SparkContext(conf)
val sqlContext = new SQLContext(sc)
// this is used to implicitly convert an RDD to a DataFrame.
import sqlContext.implicits._
//register table sales
sc.textFile("/test/sales.csv").map(_.split(" "))
.map(s => Sales(s(0).trim.toInt, s(1).trim.toInt, s(2), s(3).trim.toInt))
.toDF().registerTempTable("sales")
//register table rfm
val rfm = sqlContext.sql("SELECT cu_id as cuid,min(days_ago) as r, count(price) as f,sum(price) as m FROM sales" +
" group By cu_id").map(t => RFM(t(0).toString.toInt, t(1).toString.toInt, t(2).toString.toInt, t(3)
.toString.toInt)).toDF()
rfm.registerTempTable("rfm")
//avgr avgf avgm
val vls:Map[String,Double] = sqlContext.sql("select avg(r) as avgr,avg(f) as avgf,avg(m) as avgm from rfm ")
.map(_.getValuesMap[Double](List("avgr", "avgf", "avgm"))).collect()(0)
//sparksql udf:flag()
sqlContext.udf.register("flag", (r: Int) => if(r>=vls("avgr")) "1" else "0")
//show cu_id flag
val vfmwithflag=sqlContext.sql("select cu_id as cuid,flag(r) as flagr,flag(f) as flagf,flag(m) as flagm " +
"from rfm")
vfmwithflag.show()
sc.stop()
}
}
用户分层的值就这么来了。那么用户画像呢，在哪里。
网络上关于用户画像
用户画像基本内容
看上去用户画像就是打标签的过程，你的应用/营销触点是否充足，是否能有效跟用户产生交互，直接决定了你的用户画像带来的价值。
针对用户画像，一定要做到数据的统一，正确，及时。所谓的统一，就是大家的数据统计口径，数据字典的完备；所谓正确，不要因为人为的对生产数据库进行修改导致脏数据留存（系统可能不正确，但在生产数据库上作改动更不正确，当然有几个做技术的能回避这一点呢，业务领导告诉你，我现在统计个数据都不对，你改还是不改呢？这是个管理和机制问题，跟技术没有本质性关系，当初设计系统的时候，为啥技术团队不关注业务实践，业务需求为啥总是我要，我要，我还要....所以，真正的技术债，不是你对日后业务变化的不可预知性，进行错误的技术架构选型，是思想上的摸着石头过河）。关于标签体系的构建，我个人觉得HBase，Hive都可以胜任，就像前文讨论ALS的过程中，只要数据正确，有效，就能够满足业务上的需要。即使是用户的标签体系的构建，也是要进行分类的，并且WOE的过程会为这些分类属性提供不同的权重（建议参考 https://www.cnblogs.com/fengyouheng/p/11048386.html）当然，针对数据存储选型上，如果非要说个区别，我还是感觉，Hive是个数据仓库，还屏蔽MapReduce的操作，降低了编程的复杂度；HBase是个数据库，借助LSM树，屏蔽了对HDFS的操作，降低了部署及应用的复杂度。
LSM Tree
别着急说HBase因为太多随机读IO降低了性能，总得全表扫描，你要是有这么多猜测型场景，就去优化它（公司不好，你就去改变它；领导不好，你就加速成长，你来当领导；产品不好，你就自己构建个产品力强的产品；实在不行还能换工作不是么）看看你的Scan Cache设置的是否合理，你的JVM CMS的GC是否合适，你的BlockCache，BucketCache等等。当然，每次都有团队的伙伴问起来为什么不直接用Kudu(估计就是觉得技术栈老，虽然老，但是稳定有价值呀，跟我对自己的评价一致)。我也承认Kudu的确有优势所在，比如在Table下，提出了Tablet这样的概念（就是Segment，来源于Linux的文件管理方式，针对分布式文件有天生的优势，也是HTAP的一个很好的选择）；HBase的确就是在HDFS基础上构建的（RegionServer->region->store-> memstore & storefile 底层是hfile）我个人的感觉还是因为团队的可接受程度，用了Kudu，因为不直接支持SQL，还要引入Impala，而且不支持跨行的ACID事务，且引入的越多运维复杂度就会越高。毕竟我们的团队还没有到大家有充足的时间把玩代码的程度。到此，基本的工具和数据我们都有了，给大家推荐篇文章，专门说怎么用的（https://new.qq.com/rain/a/20201204a01iuh00）因为一旦用户的标签体系和用户画像构建起来，下面要做的就是针对性的营销和用户运营。数据分析是过程，运营是我们永远的终极目标。
网友评论