人群创建成功后会存储在Hive表和OSS中，画像平台用户有时需要拉取人群数据并应用到一些业务中。比如用户希望在Push平台上针对指定人群下的所有用户推送消息，此时可以使用画像平台接口拉取人群数据；在七夕活动中，运营人员投放使用了多个人群，为了分析不同人群的转化效果，此时需要将人群结果的Hive表提供给数据分析师使用。综上可知，人群数据对外输出方式主要分为两种：Hive表和服务接口。
Hive表的方式就是将人群结果表告知业务使用，此时需要注意以下3个问题：
- 权限问题：如果所有人群的结果都存储在同一张Hive表中，需要严格进行权限控制。拥有数据表权限的用户理论上可以读取到所有人群下的用户数据，如果部分人群数据比较敏感（比如充值用户人群、日活用户人群），就需要严格控制Hive表的读取权限。如果不同人群数据存储在不同Hive表中，这个根据实际需要申请相关Hive表权限即可。用户对人群结果表的权限仅限于读权限，只有画像平台拥有人群结果表写权限。
- 数据锁问题：用户在读取人群结果表数据的同时可能遇到人群数据正在写入的情况，这个时候会出现数据锁问题，可以通过show locks查看锁表情况。如果业务允许在人群处理过程中忽略锁的存在，比如为了提高人群读取的效率，在人群数据读取时不希望受到锁影响，可以直接设置参数hive.support.concurrency为false。
- 数据表下线问题：当人群结果表应用到数据生产和分析任务中时，人群表的更新或者下线会对下游依赖产生影响。比如人群表应用在了某场活动的离线分析任务中，分析结果定时更新后通过数据看板展示出来，人群结果表的更新或者下线都会影响到看板上的分析结果。此时需要找到人群结果表的所有的下游使用方并及时通知对方进行数据表切换。
考虑到以上问题，在画像平台业务中一般不建议直接将人群结果表提供给业务方使用。可以通过人群下载等平台功能将人群数据导出到临时Hive表中供业务使用，这样可以避免上述三类问题的发生。
对外提供人群数据的服务接口主要有两个：获取人群基本信息接口和获取人群BitMap接口。获取人群基本信息接口主要用于查询人群基本信息，其中包括人群名称、用户数量、人群状态、创建者、创建规则等，该接口可以使用缓存来提高接口性能。获取人群BitMap接口可以读取OSS中的人群数据并返回给调用方。上述两个接口可以通过微服务的形式封装到SDK中对外提供数据服务。
当业务方需要感知人群状态变化时，可以定期调用人群基本信息接口，对比人群前后状态就可以知道人群状态是否变更。比如在Push平台上置了一个定时更新人群，当人群数据更新后需要再次给人群下的用户推送消息。此时Push侧需要及时感知人群状态变化，当发现人群重新创建成功后再次进行Push操作。由于大部分时间下人群状态不会变动，定期调用接口的方式会产生大量的无用请求；定期调用本身也有时间间隔，当人群状态发生变化时需要等待下次调用才能捕获到状态变化。为了解决上述问题，画像平台可以将人群状态变更信息写入消息队列，业务方订阅消息队列便能及时感知人群状态变化。
当调用方通过接口拉取人群数据时，画像平台侧首先从OSS读取人群BitMap数据，然后通过人群BitMap接口返回给调用方。在这种情况下，当接口并发调用量较大时，画像平台会有较大的资源压力，因为内存和网络中需要存储和传输大量的人群数据。此时可以将从OSS拉取人群的代码逻辑封装到SDK中，即拉取和解析人群数据在调用方侧执行，从而减少画像平台侧的资源压力。
图5-37展示了通过服务接口对外输出人群数据的流程图，其中包含了人群状态监听和人群数据拉取过程。
本文节选自《用户画像：平台构建与业务实践》，转载请注明出处。
