好久没更新了，后面计划更新一波关于实时计算/数仓的相关内容，也算是记录一下自己的学习和填坑的过程，主要是应用部分包括架构设计、流程、思路、问题处理的东西，关于底层原理或者组件的一些知识点可能不涉及或者较少涉及。
关于实时计算的一些，可能大部分大数据从业者想到的解决方案就是kafka+flink这套处理框架，不可否认这套流程不管是成熟度、适用性都非常的高，但是在实际工作中，还是存在很多其他的解决思路。
首先明确一点，在企业中，实时的应用场景并不像离线计算那么广泛，毕竟大数据只是手段，最终的目的不外乎为决策提供分析结果、为观测提供数据看板、为其他一些场景提供即系查询结果、风控类评估和决策流等。
第一点，在分析类的应用中，除一些日志类场景中应用较多，可能对时效性要求较高外，其余业务分析类对时效性要求并不像想象中的那么高。日志类分析可以用标准实时计算流程处理，其他分析场景可以考虑微批处理形式处理，根据业务需求，决定调度系统执行作业的调度周期，可覆盖绝大多数业务需求。
第二点，为观测数据提供数据看板，尤其是驾驶舱或者实时大屏类的需求，可能对于实时性要求较高。但是，但是，需要注意的是，大屏的更新频率往往不需要指标类数字一直在跳动，实时计算也需要通过滚动或滑动窗口来控制计算频率，比如步长设置为1小时，计算频率5分钟诸如此类，也可以通过微批达到类似效果。
第三点，即席查询类需求，大部分和第二点内容重叠，少部分场景提供离线数据或者准实时数据即可。
第四点的实时要求可能会比较高，比如用户数据流进入决策决策引擎或者评分系统后，需要实时对用户进行评分打标。
我想跟大家分享一个心得，就是不要局限于自己的思路，不要执着于技术栈，解决问题的办法永远是在“妥协”中寻找一个动态平衡的。
比如说，资源方面的妥协，可能存在硬件设施（云服务器）采购成本的考量，；比如说技术实时间成本和业务需求紧急程度的妥协；比如说人员学习使用成本和当下人员任务分配的妥协等等。
当然，从长远发展来看，肯定是越标准化越好。但是公司可能考虑开始做企业级数据仓库/中台，一开始可能只是想解决某一个问题点，比如说解决数据安全的问题，查询业务从库的性能问题等等。
Flink该学还得学，但是不要局限思维，一切从实际出发。
