这种都是挺标准的金融信贷数据设计，都有成套的方案，做房贷的按理说你们那儿应该有对应懂产品的人；

一般的标准结构都分这么几个部分：
1 、用户系统，下属用户数据、扩展数据，征信数据，内部预授信数据，内部风控数据……
2 、进件系统，产品，内容、合同……
3 、信贷业务，细分里你说的那个部分，是结合产品、内容、合同和用户的数据，一般有还款计划表（就是贷款后要先把计划还款都列出来），实际还款（就是根据合同和实际还款行为的对应数据），一般的统计计算就是这几个数据和用户及合同这几个数据的联合；
4 、业务催收数据；

当然这里面还有各种配套的，什么卡 bin 、日期时间、息费规则、代收付配套接口等等等等等；

房贷业务你们还要自己写？？？

经测：华为畅聊

@geekvcn 想起我们这个年代的人，小时候要买 walkman 说是要学英语，这么多年了，套路没变嘛 /doge

注册成功了，大陆 ip 不能提供服务，需要额外处理一下；

确实 jp 的服务节点没了，挑了个 mumbai ，如果是三哥的那个 mumbai ，相对来说也近点儿，至少比 us 、eu 之类的快些，理论上的，感谢分享。

“钱多” ❌
“事儿少” ✅
“离家近”❌

一般来说，三条几乎不可能同时达到，所以通常人们都选择两条，常见的选择是“离家近”+“事儿少”，换而言之，如果离家也不近，那几乎必选“钱多”，也就是如果三条中只能选一条，那么绝大部分普罗大众都应该选“钱多”，无论男女，而你完美避开了人肉穷举出来的最优算法；

你的算法是要精进了…… 还有耳根子……太软；

刷不刷的，先投着，就像做电销，先给那些不太靠谱儿的企业投着，反正你现在有大把时间，5 点后大城市 hr 都还没下班，如果有地方接，你就知道自己的下限在哪里，最差还能知道现在外面这些企业究竟想要什么，所谓“抬杠长能耐”，这样再刷题学东西的时候，至少更有清晰的方向。

1 、想盈利，算了；
2 、兴趣，just do it

感谢，已收藏，准备在自己服务器上试试看

技术其实都差不多，主要看有没有跟对好的老大；

单打独斗永远都很辛苦，如果你有一个团队，无论是跟着团队一起走，还是带着一个团队走，团队的力量永远要比自己轻松。

这个和用哪种方法实现无关，一般有点儿技术背景的且和金融相关的产品，为了降低沟通成本，大多都用这种表述方法，当然具体的表述可能根据自己的技术背景有所差异；

主要是省事儿，因为很多时候稍微复杂一点点，用日常用语做业务交互，费时费力还不准确，时间长了换谁都烦，尤其是不太有技术抽象思维的业务之类部门再掺进来，东一句西一句，企业沟通就是这样，一来和技术打交道，费了半天话不如给个公式，那些没什么抽象思维的就知道 blablabla 的，看见一个公式出现，都会说话开始慎重；

实现时候就两种，要么就是技术看完在原有技术栈的系统里做一次实现，要么就是写系统的时候把这些做成一个标准计算和运算符的实现，产品或业务人员简单学习后自己按照“标准语法”扔进去套就行了，省嘴皮子。

主要看钱归谁，钱到位，我在什么岗位都能写

你这是色心又起，lsp ，都不惜的戳穿你 /doge

根据老夫多年观察，负责任地说：穷才会衰老的快，大城市不会。

mysql 本身也不适合干这个活儿；

如果你是生产库，那更不适合干这个，没事儿总 count 容易挂；

看你的延迟需求，是不是说一定要实时 count ，还是准实时，对于这类聚合，如果不是要求绝对实时，踏踏实实另搭个 clickhouse ，你再加个 0 也是秒出

怎么说呢，其实哪里都缺好思路，这种思路比较散，不太具象，如果深入到某一个领域进去的话，就会发现，每个细分领域的“好思路”其实很多，而且一群创投人天天跑场，生怕错过好项目；

其实我们真的不缺“好思路”，但是年代不一样了，比如就说互联网，大块儿互联网市场，但凡有利润的行业，基本都被吃干净了，剩下各种结合的也一样，而且最麻烦的是，不像以往有个点子就行，现在深入到细分市场后，对团队的综合能力和资源要求，都奇高无比；

举个例子，我们原来做互联网金融项目起步的时候，一个集团内部用户转化成本可能只要几块钱，做到后面这个行业的用户成本都奔着 2000 块钱一个去了，当然这种生意本身也不是个人或小团队能起来的，就是现在，你发布个 app ，个人名义没个软著没个注册企业，连市场都上不去；

不要提这种行业，去年前生物制药飞起，几乎一年时间，针对生物制药各个研究领域的公司几乎都全了，竞争不是一般的惨烈；我们在北京，申请个不是国自然，是北京市的科研基金，团队里挂两个全国杰青级的教授，也就能过第一轮而已；

作为过来人，只能说：

创意+护城河技术的团队+资源，缺一不可，不然真的最后还不一定能赶上 v 站吹吹水，至少还是真人。

简单理解就是一周有 7 天，说多点儿就是和工作周期有直接关系的，绝大部分人的工作周期都是周一到周五工作，周六周日休息，一般的业务运营也是根据绝大部分人的生活工作周期习惯来的，相应周期的规律比较稳定，对比就比较容易；

有没有其他周期的统计，根据业务来的，比如我原来做金融，那就不仅仅是 7 ，用户行为日的+-1-+2-+3……+-n ，自然日的+-1+-2+-3……+-n ，还有 7 、上中下旬，工作时间休息时间夜间凌晨……各种不同的维度攒变量，攒统计指标，有的可以直接拿来做报表，有的直接进模型，行为数据、业务数据的粒度做的就特别细，分属在不同集市层放着，各种诡异指标完全和业务相关。

没想过 v 站上这类问题能有这么多，可以考虑开班了

如果业务系统没有做额外的记录，可以看看交换机那边的日志还有没有，一般企业用的交换机日志信息还是比较全的，能访问而且还没有被覆盖的话，去那里面找找。