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支持外部，但是如果要性能好，就须要通过内表担保性能，以是当繁芜的洗濯场景出来时，可能还要探求其他的办理方案。
虽然有些问题，但这是一个很好的办理方案和思路，只要不断探索，找到适用的场景，就会有收成。印证“没有银弹”这句话，找到得当的场景，为业务赋能，不断考试测验，挖掘并发挥代价。
