42 | Kafka Streams在金融领域的应用
胡夕
该思维导图由 AI 生成，仅供参考
你好，我是胡夕。今天我要和你分享的主题是：Kafka Streams 在金融领域的应用。
背景
金融领域囊括的内容有很多，我今天分享的主要是，如何利用大数据技术，特别是 Kafka Streams 实时计算框架，来帮助我们更好地做企业用户洞察。
众所周知，金融领域内的获客成本是相当高的，一线城市高净值白领的获客成本通常可达上千元。面对如此巨大的成本压力，金融企业一方面要降低广告投放的获客成本，另一方面要做好精细化运营，实现客户生命周期内价值（Custom Lifecycle Value, CLV）的最大化。
实现价值最大化的一个重要途径就是做好用户洞察，而用户洞察要求你要更深度地了解你的客户，即所谓的 Know Your Customer（KYC），真正做到以客户为中心，不断地满足客户需求。
为了实现 KYC，传统的做法是花费大量的时间与客户见面，做面对面的沟通以了解客户的情况。但是，用这种方式得到的数据往往是不真实的，毕竟客户内心是有潜在的自我保护意识的，短时间内的面对面交流很难真正洞察到客户的真实诉求。
相反地，渗透到每个人日常生活方方面面的大数据信息则代表了客户的实际需求。比如客户经常浏览哪些网站、都买过什么东西、最喜欢的视频类型是什么。这些数据看似很随意，但都表征了客户最真实的想法。将这些数据汇总在一起，我们就能完整地构造出客户的画像，这就是所谓的用户画像（User Profile）技术。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
Kafka Streams在金融领域的应用案例展示了其在实时计算领域的强大功能。通过实时ID Mapping，金融企业能够实现客户生命周期价值的最大化，降低获客成本并实现精细化运营。文章详细介绍了使用Kafka Streams实现实时ID Mapping的具体步骤，包括构建表和流、实现流-表连接等关键逻辑。通过简洁的Java代码，展示了如何利用Kafka Streams快速实现实时ID Mapping任务。总结来说，Kafka Streams在金融领域的应用为企业提供了强大的实时计算能力，帮助企业更好地理解客户需求，实现精准营销和客户价值最大化。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Kafka 核心技术与实战》，新⼈⾸单¥68
《Kafka 核心技术与实战》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(12)
- 最新
- 精选
timmy21KTable是全部保存在内存吗？具体实现是怎么样的？作者回复: 保存在底层的Topic中，这类topic一定是启用了compact了的
2020-10-032
Minze胡老师您好，最近我在学习使用Kafka streams，有一点让我困惑的是在使用join的时候，生成的topology中会有一些名字包含KSTREAM–JOINTHIS和KSTREAM–OUTEROTHER的processor和store创建出来，这些本地的store应该是用来存储join要用到的数据，这我能理解，但是这些processor的作用和JOINTHIS、OUTEROTHER的命名含义却百思不得其解，老师可否给些建议或者提示？作者回复: 没有什么特别的含义，源码就是这么命名的，如下： static final String OUTEROTHER_NAME = "KSTREAM-OUTEROTHER-";
2021-04-291
King最后写入outputTopic是以append还是update？可以保证用户在outputTopic中只有一条记录吗？作者回复: append的方式。不能保证，因为最后是将所有状态转换成stream了
2020-03-211
IT小僧老师好，这个构造IDMapping中的KTable对象肯定会越来越大吧，这个怎么处理呢作者回复: 也没关系啊，保存在底层的topic中
2020-02-0631
J.Smile老师，我看到有使用stream加迭代器的方式去消费消息的，貌似建立连接时传入了一个topicCount的map，也就是说这个stream其实可以消费到多个topic的数据，总觉得有点奇怪，因为跟老师之前课程里那种poll的方式差别很大。我不太能明白这种形式消费数据，到底消费者对应是某一个stream？还是topicCount的每个topic？是哪个决定了consumer的数量？作者回复: 如果是Kafka Streams，consumer的数量由num.stream.threads直接决定，当然也受订阅总分区数的制约
2020-07-21
兔2🐰🍃App上发现该栏目更新了最后一节，目前才学到22节，完成了前三章的了解。我从上个月20日开始的，有20天时间了，也算是从0开始的，对Kafka有了很多了解，每听完一节，遍跟着写笔记，结构化文章内容，感觉有点慢，实践还没开始。明天起换个方式试试效果，搭个环境，实践下前22节内容，接着后面的章节先每章节内容听一遍后梳理整个章节的内容，再到实践。 感谢胡老师的教课，节日快乐~2019-09-10411
曾轼麟left join 可以关联上不存在的数据行，而join其实是inner join 需要两张表数据都匹配上结果才会有，left join的好处就是，如果其中有一张表没有匹配数据，也不会导致结果集没有这条记录2019-09-115- Shopman希望再出一个streams课程！！！2023-06-02归属地：四川1
Kaine老师在<VT, VR> KStream<K, VR> leftJoin(final KTable<K, VT> table, final ValueJoiner<? super V, ? super VT, ? extends VR> joiner); 有这么一段注释，上面说输入流的分区数必须与Ktable对应的topic的分区数一致这是为什么呢 Both input streams (or to be more precise, their underlying source topics) need to have the same number of partitions. If this is not the case, you would need to call through(String) for this KStream before doing the join, using a pre-created topic with the same number of partitions as the given KTable. Furthermore, both input streams need to be co-partitioned on the join key (i.e., use the same partitioner); cf. join(GlobalKTable, KeyValueMapper, ValueJoiner). If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join. The repartitioning topic will be named "${applicationId}-<name>-repartition", where "applicationId" is user-specified in StreamsConfig via parameter APPLICATION_ID_CONFIG, "<name>" is an internally generated name, and "-repartition" is a fixed suffix.2022-02-23- 小仙这里用到的 4 个 topic 就是普通的 topic 吗？也是默认 7 天消息过期等等设定，并非永久保存2022-01-18
收起评论
