大数据实时（4）-YJD的Flink&Hologres的实时数仓补足

目录：

1、场景与痛点

2、技术选型

3、应用最佳实践

        1）客户系统实践

        2）大屏实践

        3）实时数仓实践

4、思考

1、场景与痛点

一家快速成长的公司，在短期内发展起来时，技术方面都会留下一些问题，比如从大单体到微服务的转型，从选型到落地，有时为了快速满足业务的需求，会采用一些临时方案满足客户要求，造成一些临时方案遗留症。比如：

架构方面：多种数据源、多语言、多布式、异构系统、业务侵入严重，多种架构带来的复杂性；

数据方面：按场景化的产品开发造成的数据孤岛，系统间的数据不通，造成大量的数据复制、冗余、不一致，重复烟囱式的建设严重；同时，数据的定制化也带来了前所未有的挑战；

应用方面：对于业务分析的数据，比如销售业绩，客户希望实时、准确进行查看分析，准确、时效性要求非常高；

效率方面：工具化支撑严重不足，代码开发严重影响效率，质量也会有比较大的影响；面向需求的开发的整体DevOps链路上都出现了很多的瓶颈，自动化方式应用不足；

成本方面：大数据与业务双重人才非常缺乏，团队建设成本非常高，招人非常困难；

随着业务的不断增长，各方面的问题突现，在数据方面尤为突出，痛点问题的解决已迫在眉睫。

2、技术选型

说到技术选型，之前跟大家分享架构其实包括功能和非功能，核心点还是非功能性上的支撑程度和未来的发展空间。所以技术选型主要是在非功能性方面，主对于数仓来说，要包括以下一些维度（包括但不限于）：准确性、可用性、性能、安全几个方面。

最优先的应该是可用性，包括能否快速快速的清洗完成、能否实时的查询并且高并发低延迟、能否快速的获取异常和预警并及时修复恢复，能否基于不确定性的流量进行熔断、限流、降级机制等等；

然后是性能，性能主要是数据服务的性能指标，有具体的查询时间，有高并发场景下的性能压力值，数据服务其实核心对应的是查询存储引擎是否具备良好的性能指标和成本平衡；

其次是准确性，数仓简单而又复杂的一个领域，简单是指标的开发并不需要太高深技术，SQL是比较核心的，当然也有些SQL搞不定的，对于大数据理解越深成果就会更好；复杂是指标开发的准确性如何保证，其中涉及到比较多的是数据治理的范畴，可大可小，涉及到的团队非常多，利益也非常多，水还是很深的，想做好并不是非常容易的事。

最后是安全，对于客户信息的隐私，目前政策是越来越严，客户的敏感信息，如电话、身份证以及随着AIOT的蓬勃发展，人脸的信息在管控上也是非常严格。对于私域与公域的转换，更是增加了很多的规定。落实到具体的内部数据来说，对于一些敏感信息的生成、传输、保存过程的加密处理，也是非常重要的一件事情。

当然，以上都是基于技术维度的，基于历史维度来看，公司现在的现状，也有很大的影响，比如如果你是跟着云厂商共同进退，则开源就是比较困难的一件事件。虽道阻且长，依然努力奋斗，坚定不移的一往直前是我们的不变追求，在技术不断升级的条件下，持续地做到最好，总有收获。

3、最佳实践

3.1、客户系统实践

1）以往的架构：MySQL+Canal+MQ+PHP+Dataworks+Hologres；自研的消息中间件，成本高，过程复杂，对于有序的清洗要求极高；

2）新的架构：基于Hologres+Dataworks+Flink，直接通过DataWorks数据集成将数据库数据实时写入Hologres，通过FLink实时订阅Hologres做进一步实时清洗，把结果更新到数据库，即可直接服务业务；

整体架构清晰简单、数据精准、端到端纯实时、存储分析一体化、托管式运维、全自动工具作业，以往要3~4个月完成的项目，现在仅需2天即部署完成。

3.2、业绩大屏实践

1）要求：实时、精准，业绩计算绝不允许出错；

2）以往的架构：架构：Binlog+Canal+MQ，业务领域进行数据分层和清洗，任务调度完成“日、月、季、年”等维度的统计，会出现实时性（5~10分钟批处理延迟）、并发（消费的并发有一定限度）、运维（任务节点出问题，整体不可用）、数据清洗时效性问题（清洗脚本运行一次需要数分钟）。

3）新的架构：通过DataWorks实时同步明细数据至Hologres，基于Hologres数据再增加一份实时计算Flink的实时ETL作业，即可完成“日-月-季度-年”数据的加工，最后基于Hologres对上层应用提供分析查询服务。整个系统纯实时调度、实时性高、秒级延迟、全SQL开发、数据校验高效。以实时高（实时性）、准（一致性）、快（系统调度）的大屏展示。

3.3、实时数仓

有了以上的实践，通过实时计算FLink+Hologres+DataWorks完成实时数仓的落地，为业务开发人员提供大数据开发能力，为业务团队赋能。

以上实时数仓将为公司或技术团队提供以下价值，真正做到开箱即用，所见即所得：

1）统一的数据：数仓的建模统一和有序，包括整个的流程、所有的数据包括明细表、维度表、汇总表；

2）统一的服务：提供统一的数据分析、数据服务，通过开放的方式，提供统一的数据开放平台，业务团队可以自主开发、自主控制；

3）统一的存储：统一接入Hologres，统一存储，无冗余，节约成本；

4）统一的治理：DataWorks的强大的能力，为大数据平台提供统一的治理平台；

4、思考

总的来说，Flink和Hologres的实时数仓给我们带来了一条可能性的道路，统一的存储及统一的服务，有点小数据湖的概念，通过离线、小批、实时的数据处理，最终实现不同场景不同时效性的数据要求，方向是OK的。

同时，Dataworks的实时采集，基于本身的数据集能力，快速、易用，可以满足数据源不是太多的情况，大大节省了开发成本和运维成本，提升了团队的质量和效率。

不过，有几个潜在问题

1）如果是SAAS化的场景，则有可能很难保证采集的时效性，Binlog反而可能是一个更好的选择。

2）Hologres可以满足简单清洗逻辑的处理，对于复杂SQL的清洗能力并不是很合适，性能依然是个问题。

3）Hologres依然需要存储自己的一份数据，如果在已有数据架构的基础上，需要再同步一份数据，也是性能和成 本的损耗，虽然说Hologres支持外部，但是如果要性能好，就需要通过内表保证性能，所以当复杂的清洗场景出来时，可能还要寻找其他的解决方案。

虽然有些问题，但这是一个很好的解决方案和思路，只要不断探索，找到适用的场景，就会有收获。印证“没有银弹”这句话，找到合适的场景，为业务赋能，不断尝试，挖掘并发挥价值。