大数据实时（7）如何构建Flink实时平台

　　目录：
　　1、场景痛点
　　2、实时平台建设方案
　　3、FlinkSQL开发平台
　　4、展望
　　1、场景痛点
　　对于一个实时要求很高的业务领域，实时是非常重要的。分析下来场景问题差别不大，比如之前某一款产品解决的实时场景包括实时数仓 、加速查询、联邦查询。今天说的场景也大同小异，包括以下几个方面：
　　1）实时数仓：针对行业日志，进行数据处理并提供高可用的即席查询服务，同时针对离线数仓，进行实效性的补充，提供更加实时的分析服务；
　　3）实时监控：实时开始最核心的场景就是监控，后来才应用于业务相关的实时处理，所以监控的场景一直存在，一直演进；
　　4）实时分析：要发挥数据的价值，要提供有价值的分析结果，支撑业务的决策、改进、优化，收获实际的业务价值；
　　5）广告推荐：针对客户进行分类，然后针对不同客户制定不同的策略，推荐不同的结果，提升业务转化价值；
　　6）特征工程：提取提炼特征，尝试通过算法进行实际的业务赋能；
　　针对不同场景，核心的问题或痛点也是类似的，包括以下几个方面：
　　1）更高的时效性：实时有时是客户能否用起来的关键，一个需要实时查看的数据如果不能实时，产品的价值折半，失去使用的价值都有可能；
　　2）更稳的可用性：如何针对集群进行管理、进行资源隔离、指定任务的优先级及独立资源等等；
　　3）更好的性能：针对不同的业务资源隔离、对于计算或查询型IO隔离等；
　　4）更低的成本：随着任务、集群规模、计算量、峰值的不断增长，合理的进行成本规划和预算；6000+任务、几千万的成本、查询引擎高并发负载等；
　　2、实时平台建设方案
　　实时平台的核心场景包括3个部分，实时数据采集存储、实时数据计算、实时数据分发。采集存储是如何快速有效的将业务及行业数据采集到数据平台中；实时数据计算是将采集过来的数据如何准确有效的进行建模、计算、并生成最终的实时结果数据；实时数据分析是如何将结果数据快速地输出到使用方，包括输出给实时业务方或同步存储到实时DB中，并提供统一数据服务。
　　说到平台，大家的理解可能不一样。这里说的是基于上述3个实时核心技术场景，提供技术支撑的技术平台，具体包括为数据处理过程提供基础设施平台、数据开发平台、运维平台、监控平台、质量平台。
　　基础设施平台：主要是包括各种组件集群的构建，包括Kafka、Spartstreaming、Flink、Clickhouse、Doris等集群；
　　运维平台：负责元数据管理和时间戳管理；
　　监控平台：负责监控和预警，监控又可以分为进程、日志、延迟、状态等类型的监控；告警则根据规则进行不同等级的告警提醒，及送推送通知并通过看板展示相关监控结果信息；
　　质量平台：重点是针对数据准确性，进行质量的巡检，并按照巡检结果依据质量处理机制及时处理准确性的问题，确保数据质量，更好的为业务服务和赋能；
　　数据开发平台：最核心的内容，主要是Flink一体化计算平台，整个实时平台的核心，以Flink为基础，构建整体计算平台。另外一个比较重要的是数据采集分发平台，不管是数据的采集还是输出同步，都需要通过数据分发平台进行整合、管理、执行、运营。只有这样，才可能将数据汇集，然后提供数据价值服务，数据的核心价值所在。数据如果是静静地躺在电脑中，是没有任何意义的，需要流动起来，用起来才是真正有价值的。
　　对于Flink一体化计算平台技术架构，大致包括数据接入（业务数据和行业日志）、计算引擎、实时存储、基础管理平台几个部分。对于数据接入，采取Canal进行业务数据采集，利用Canal的高可用方案，提升业务数据实时接入的完整性和准确性，并提供初始化、监控、重启、恢复等高可用方案；采取Flume进行行为日志的采集，也可以直接将行为日志上报到消息中间件中，确保行为日志数据的完整和准确，通过各种措施，保证行业日志的丢失率小于1%。计算引擎则是紧跟时代潮流，从Sparkstreaming到Flink，保证了实时计算引擎的领先性。实时存储的选择则非常多样，针对不同的场景提供不同的存储，以适应不同的需求，包括Kafka、Hbase、Es、ClickHouse，也研究过ADB、DWS等去上产品。基础管理平台则是对于整体平台、基础设施及运行时的状态提供必要的管理、监控、预警，保证高可用要求。
　　其实计算平台各个厂都大同小异，各个组件也比较成熟，核心是要基于业务场景，做到比较好的匹配，以保证业务的顺利开展。背后的诉求主要就是3点，实时性、准确性、可用性要达到相当高的要求。特别是应用于业务实际场景时，要求就会更高，这是要重点关注的核心因素。
　　3、FLinkSQL开发平台
　　既然采用了Flink，那么FlinkSQL是绕不开的一个解决方案，传统的API方式，不灵活应用比较困难门槛也高，应对流批一体的场景，则显得力不从心。FLinkSQL自然而然就成为了首选。从之前的Sparkstreaming到python到Flink最终确定为FlinkSQL，一是从技术的发展路线，一是从需求的客观要求，从2方面决定了非FlinkSQL莫属。
　　为什么采取FlinkSQL稍微展开下，主要有以下方面的因素：
　　1）很好的社区服务，完整的生态，为实时的长期发展提供了必要的条件；
　　2）健全的故障转移策略，高可用，动态扩展，实现7*24小时全天候运行，完善的Flink 度量系统以及成熟指标监控与告警配套方案；
　　3）可基于SQL+UDF开发，极大地解决了开发难度的问题，扩展性方面也得到了很大的提升；
　　4）提供了匹配多种业务，多种保障机制，比如状态计算、状态管理、高度灵活的窗口设置；
　　简单说就是大势所趋，随心而动。
　　如何构建平台？其实有比较成熟的一些方案，可以借助于Dlink来构建，从开发、调试、测试、上线各环节，完善开发工具，支撑起整体开发流程，解决开发、测试、发布人员的生产力，确保数据质量，提升整体的研发效能。
　　4、展望
　　说到展望，其实也是面临的最核心的一些问题是什么，主要是3个方面：
　　1）准确性：实时目前比较期待的一个方式，是流批一体的实现，从Lamda架构到kappa架构的演进，真正解决数据准确性、一致性的问题，是一直在研究的课题，但现在应用其实都不是太好，继续努力；
　　2）可用性和成本：目前资源的利用率是比较低的，如何通过资源的优化、调整，合理利用，得到长足的进步，降低费用成本；一个系统是否能很好的发挥价值，可用性、稳定性是一个非常重要的指标，目前事中事后的监控虽然能发现一些问题，但是基本都是问题发生后才知道，其实是会影响系统使用的，能否在事前进行监控，及早发现，把问题处理在萌芽状态，对于系统的稳定性是大有益处的。
　　3）价值：任何一个技术平台，最终都要服务于业务，只有业务产生价值，技术平台才有生存的空间，所以场景挖掘方面，需要多关注，与产品经理起来，持续改进优化平台，服务好各个角色，让平台活下来。