公司总在围绕用户发展，研究用户，注定绕不开画像。画像不仅可以提升对用户的认知，还可以通过落地赋能业务。如果要想利用大数据来精细化运营和精准营销服务，用户画像是至关重要的一步。
公司在18年就已经尝试去建立用户画像，可基于种种原因，技术也好，人员也罢，最终不了了之。 从2020年疫情过后，架构调整后，又着手去准备，从技术调研到参与业务讨论乃至争论，不断打破思想禁锢，直到接近完善，过程可谓是痛苦。一年以来，请教了n多位前辈，看了n多篇公众号，翻烂了两本书，也终于对用户画像有了点自己的认识，在此做下记录，方便日后复盘。
在整个工程化方案中，系统依赖的基础设施大体分为四部分：
- 数据计算：SparkSQL、Spark Structure streaming、Pandas。
- 数据同步：Kafka、StreamSets、MQ
- 数据存储：Kudu、Hive、MongoDB、MySQL、pg
- 支持设施：Azkaban、Redis、Presto
HBase是第一个调研的，大部分人会反映RowKey难设计、对大面积数据扫描不友好，同时战友们一致不喜欢使用HBase，所以放弃。
Elasticsearch是比较遗憾放弃的，原本打算当做应用层，由于担心数据量大了以后，运维能力跟不上，所以用MongoDB和Kudu代替。
走过来发现，作为技术，有个整体的大数据眼界很重要，为了解决需求选取合适的架构，而不是局限于某种框架。
为了在开发阶段做出合适的架构设计，在业务中能发挥更大的效能，必须同时具备技术和业务思维。
- 如果技术不懂业务，面临的问题就是技术人员只是单方面了解画像的技术实现，对应用方面会有思维局限，不能从大局观上考虑整体的实现。
- 如果业务不懂技术，就算有强烈的业务需求但是不清楚画像在业务中能发挥的作用，不了解数据具体计算过程，同样思维受限。
从我的角度来看，数据分析要掌握，业务要熟悉，用户画像实现的过程中会感触更深，要不然只是根据需求机械的去计算一些指标，失去了灵魂。
我认为团队做的比较到位的就是数仓维护得很稳定，不会因为业务的变动而抽出一个人的力量再去维护数仓，这样就可以把所有力量投入到用户画像的开发中。
从用户画像的角度看，数仓是基础，一定要保证数据质量，这样才能在标签的使用上放心。
所以数仓不稳定，用户画像费时费力只是徒劳。
学习《用户画像-方法论与工程化解决方案》一书时，有幸认识了作者赵宏田老师，也感谢赵老师持续的指导。实时和批处理是处理数据的两种方案，但是怎么样配合，优先级谁高，都要根据业务特点好好考量。
对于用户画像来讲，时效性决定了标签的价值性，所以实时流工程的健全性和准确性很关键。但问题是起初经验不足，业务域不一定会想得很明白，贸然投入大力量去开发实时工程，结果就会吃大亏。
