| 编辑推荐: |
本文主要介绍了基于Lindorm的大数据用户画像解决方案的背景、用户画像数据特征、面向大数据场景的Lindorm及Lindorm核心能力概述等。
本文来自于微信公账号HBase技术社区，由火龙果软件Linda编辑、推荐。 |
|
一.背景
在传统的商场里的销售人员往往会对顾客进行察言观色，揣摩其喜好，然后投其所好，达到营销的目的，实现收益最大化。进入互联网时代，店铺搬到了线上，买家和卖家都处于一个“虚拟”的世界当中，你的“对手”是男是女、是美是丑、是普通的上班族还是家里有矿的土豪，这些信息似乎变得不可获得。
互联网的“虚拟”性决定了需要通过技术手段解决“察言观色”的问题。好在进入互联网，特别是移动互联网时代，用户随时随地都会在网上留下“言”和“行”，如何让这些言行数据“开口说话”就变得越来越重要。用户画像应运而生，而且已经广泛的应用到精准营销、推荐系统、广告投放、风控、智能客服等等领域。
那么用户画像数据及其面向的应用场景有什么的特征，针对这样的特征应该选择什么样的数据存储呢？
二.用户画像数据特征
首先我们先明确下本文所指的用户画像包含两类数据。一类是明细数据，是通过采集获取到的用户行为数据或其他的基础数据。另一类是经过分析后产生的标签数据，即通常意义上大家所称的用户画像数据，比如用户性别，住址，喜好，购物需求等等。用户画像可以通过如下的架构简图描述：
从架构简图中我们可以看到，系统一般会包括4个部分，数据采集系统、在线查询系统、离线分析系统以及数据存储系统。数据采集后会把数据写入数据存储系统，同时数据也会归档到离线系统，离线系统周期性的对数据进行训练生成新的用户画像，新的画像回流到在线系统供上层业务查询。在线系统中包含了明细数据和历史画像两个部分的数据。
基于上述的用户画像的数据范围定义及应用到的业务场景的定义，用户画像数据有哪些痛点呢？
数据量大：互联网应用的一个典型特征是拥有海量的用户，往往都是以千万甚至亿计算，海量的用户意味着会产生海量的行为数据。有些产品还有爬取外部数据的需求，以丰富其数据维度。基于海量明细数据，通过离线模型训练产出最终的用户画像，最终的用户画像数据往往也是数以亿计的高维(数百，数千甚至万计的字段数量)数据。
高并发读写：海量用户产生大量的数据需要实时写入到后台的存储系统中，因此数据写入的并发度往往会达到每秒数万，数十万甚至数百万或更高。同时，用户画像数据的在线应用场景，如推荐、广告投放等，往往会随着投放效果的提升，运营推广意愿也会提升，则意味着更多的查询数量和更高的查询并发。
明细数据需要归档：写入后端存储的用户行为明细或其他基础数据，为了尽快的反馈到用户画像数据中，往往需要准实时的归档到离线系统。
大数据量回流：归档到离线系统的数据经过分析后产生新的画像数据，需要回流到线上提供在线查询。
有动态列需求：用户画像的数据维度往往处于不断变化不断丰富当中，因此表结构也会处于不断变化当中。
查询种类多而且复杂：面向不同的业务需求，对用户画像数据的查询需求也会有差异。比如：获取用户的画像数据，只需要根据key做单条记录的查询；对用户行为数据的分析，可能是按照用户ID批量获取其数据；也可能是运营人员根据需要查询某个维度的统计数据。
针对用户画像数据的上述痛点，同时画像数据通常来讲没有强事务要求的特点，是否存在一个合适的存储方案呢？
三.面向大数据场景的Lindorm
既然用户画像没有强事务要求，又是大数据量、高并发读写场景，那么关系型数据库并不是合适的选择。在此笔者向大家推荐一款可以完美解决用户画像业务痛点，面向大数据的NoSQL数据库产品“Lindorm”。
作为面向大数据场景的半结构化、结构化存储系统，Lindorm已经在阿里发展近十年，并始终保持着快速的能力更新和技术升级，是目前支撑阿里经济体业务的核心数据库产品之一。在过去的岁月，伴随着经济体内部对于海量结构数据存储处理的需求牵引，其在功能、性能、稳定性等方面的诸多创新历经了长时间的大规模实践考验，被全面应用于阿里集团、蚂蚁集团、菜鸟、大文娱等各个业务板块，成为目前为阿里内部数据体量最大、覆盖业务最广的数据库产品。
基于Lindorm存储的用户画像架构可以用下图来描述： 
下面笔者详细阐述下Lindorm的那些特性可以解决用户画像的业务痛点。
3.1 低成本
大数据有众所周知5V特征，这其中首当其冲的是Volume，因此面向大数据场景的数据存储解决方案必须具备高密度、低成本的特性。Lindorm是诞生于大数据时代的一款NoSQL数据库，低成本解决海量大数据的高效存、取是根植于其体内的基因。Lindorm的低成本能力体现在：
多样化存储类型支持
性能型存储、标准型存储、容量型存储，总有一款适合你的业务场景
深度压缩优化
存储成本最低的系统是没有数据需要存储的系统，但这点显然是不现实的，现实可行的方案是将需要存储的数据降到合理的最低点。为了降低存储开销，Lindorm引入了一种新的无损压缩算法，旨在提供快速压缩，并实现高压缩比。它既不像LZMA和ZPAQ那样追求尽可能高的压缩比，也不像LZ4那样追求极致的压缩速度。这种算法的压缩速度超过200MB/s,
解压速度超过400MB/s（实验室数据），很好的满足Lindorm对吞吐量的需求。经实际场景验证，新的压缩优化下，压缩比相对于LZO有非常显著的提高，存储节省可以达到50%～100%，对于存储型业务，这就意味着最高可以达到50%的成本减少。
冷热分离
Lindorm具备在单一个存储架构下的“一张表”内实现数据的冷热分离，系统会自动根据用户设置的冷热分界线，自动将表中的冷数据归档到冷存储中。在用户的访问方式上和普通表几乎没有任何差异，在查询的过程中，用户只需配置查询Hint或者Time
Range，系统根据条件自动地判断查询应该落在热数据区还是冷数据区。对用户而言始终是一张表，对用户几乎做到完全的透明。
3.2 高性能吞吐
根据实测同样规格，相同数据量的情况下，Lindorm不管是在单行读、范围读还是单行写及批量写场景下，其吞吐量和P99延迟相比社区版本HBase2.0都有数倍提升。
备注：1) P99延迟指99%请求的响应时间小于该值; 2) 图中数值供参考，具体以实际场景为准
下图为以批量写为主的真实业务场景迁移后的表现，而用户画像的行为日志数据采集往往也可以通过累积一定量的数据后做批量写入。
3.3 实时增量归档
实时增量归档是Lindorm的一项独立服务，通过监听Lindorm产生的日志，LTS解析日志并同步到离线系统比如Hadoop或者MaxCompute。同步到离线系统的数据按时间分区，这样可以很方便的进行T+1，H+1或其他不同周期的计算。
这样的同步机制下，一方面数据归档过程与在线存储解耦，在线读写完全不会受到数据归档的影响。另一方面明细数据可以实现准实时同步到离线，然后进行分析，从而可以高效实现用户画像数据的更新。
3.4 Bulkload技术
与关系型数据库不同，Lindorm采用LSM Tree架构。读取存储到Lindorm里的一条记录需要合并对应数据分片内存中(即memestore)的数据、该数据分片所owner的多个LDFile中该记录的最新版本数据，合并后提交给客户端。基于这样的原理，Lindorm可以实现直接生成并向系统中“插入”新的LDFile，从而实现“新”数据的加载，使得其相比于其他的关系型数据库或NoSQL有非常大的优势。这样的数据加载过程完全绕过了存储引擎，WAL及Memstore等等，只有必不可少的物理IO和网络开销，从而极大的提升了数据加载的性能，降低了对在线业务请求的影响。
3.5 动态列
Lindorm的宽表模型支持多列簇、动态列、TTL、多版本等特性，可以很好的适合用户画像这样表结构不稳定，经常需要进行变更的业务场景。
3.6 多维度&复杂查询
对于基于rowkey的单key或基于rowkey前缀的scan，Lindorm自身就可以很好的满足业务的需求。
当遇到多维度、少量组合列，而且有固定查询模式的场景来说，Lindorm内置的高性能全局二级索引功能也可以满足业务需求，同时仍保持强大的吞吐与性能。
当面对更加复杂的查询，比如模糊查找、随机条件组合查询等等，二级索引方案会显得力不从心，这时候Lindorm搜索引擎LSearch就有其用武之地。LSearch是面向海量数据设计的分布式搜索引擎，兼容开源Solr标准接口，同时可无缝作为宽表、时序引擎的索引存储，加速检索查询。其整体架构与宽表引擎一致，基于数据自动分区+分区多副本+Lucene的结构设计，具备全文检索、聚合计算、复杂多维查询等能力，支持水平扩展、一写多读、跨机房容灾、TTL等，满足海量数据下的高效检索需求。
四.Lindorm核心能力概述
Lindorm通过其具备的全方位、多角度的能力，可以很好的满足用户画像业务大数据量、高并发、实时归档、高效&稳定批量数据加载、动态列及多维度复杂查询的需求。
当然，Lindorm的能力还远不止于此，Lindorm具备了大数据背景下，面向海量数据的存储系统应该具备的一系列的能力：
是一款支持宽表、时序、搜索、文件的多模数据库
是一款基于存储计算分离架构的数据库，提供极致的计算、存储弹性伸缩能力，并将全新提供Serverless服务，实现按需即时弹性、按使用量付费的能力
是一款支持冷热分离、、追求更优压缩优化方案的极具性价比的数据库
是一款具备全局二级索引、多维检索、时序索引等功能的数据库
提供具备智能化服务能力的LDInsight工具，白屏化完成系统管理、数据访问及故障诊断
提供LTS(Lindorm Tunnel Service，原BDS)，支持简单易用的数据交换、处理、订阅等能力，满足用户的数据迁移、实时订阅、数湖转存、数仓回流、单元化多活、备份恢复等需求
五.案例
某大型三方支付公司金融风控系统
风控系统是一个金融系统的基石，该三方支付公司的风控系统提供的安全保障在业界是最高的，资损率低至百万分之零点5，全世界排第二的资损率是万分之六(2018年公布的数据)。这背后有安全团队做出的各种模型和规则，而为这些规则和模型的运行提供数据存储支持的正是Lindorm。
大家在进行支付，扫描二维码的时候，可能只有短短的零点几秒的时间，这其中有100毫秒系统会针对这笔交易获取用户的安全画像数据进行安全甄别，比如：支付的场景，对方的背景，支付时候所处的环境，以及你的一些行为特征，购物喜好，通常的购物时间等等，去帮你甄别这个交易是否存在风险，如果存在风险，便在交易的两端去尽量的提醒，甚至截断交易，整个交易的背后是大概一百多个风险模型和五百多个风险策略的一个运算。
上文提到的用户安全画像数据正是下图所描述的明细数据和经过归档、分析和回流后导入Lindorm的日帐数据。
对于一笔交易而言就需要这么大量的模型和规则，那么双十一大促高峰期间，其对背后的数据支撑系统的要求可想而知。 |
