专访｜美的集团实时数据负责人 董奇：智能家居行业实时数仓的建设

　　随着业务快速增长，时效性越显重要，传统离线数仓的不足暴露出来：

　　运维层面——所有调度任务只能在业务闲时(凌晨)集中启动，集群压力大，耗时越来越长;

　　业务层面——数据按T+1更新，延迟高，数据时效价值打折扣，无法精细化运营与及时感知异常。

　　目前各大公司的产品需求和内部决策对于数据实时性的要求越来越迫切，需要实时数仓的能力来赋能。传统离线数仓的数据时效性是 T+1，调度频率以天为单位，无法支撑实时场景的数据需求。即使能将调度频率设置成小时，也只能解决部分时效性要求不高的场景，对于实效性要求很高的场景还是无法优雅的支撑。因此实时使用数据的问题必须得到有效解决。

　　近日，ITPUB 有幸采访到美的集团实时数据负责人、资深数据架构师董奇老师，一起探讨智能家居行业实时数仓的未来发展计划，实时数仓架构等，并给数仓从业者一些独到见解和经验。

　　问题 1：您好，董老师!很荣幸有机会采访到您，先简单介绍一下您自己?

　　好的，我叫董奇，目前就职于美的集团，担任实时数据团队负责人、资深数据架构师，团队主要负责支撑美的集团全域的实时数据应用诉求，包括美的的B端传统核心业务场景，例如供应链、营销等领域，和C端新兴业务场景，例如家居设备实时智能调控、电商活动等场景。同时，在支撑好业务应用场景的背景下，建设适用美的场景的实时数仓生态体系，通过体系赋能，更好更快更稳定的以数据赋能业务。

　　问题 2：美的实时数仓架构，分为哪几个模块分别建设?每个模块主要关注的内容是什么?

　　大的方向上主要分为四块，实时基础设施建设(Flink集群建设、Flink相关大数据生态组件建设等)、实时研发平台建设(基础研发模式支持、元数据管理、开发运维监控告警全研发生命周期建设等)、实时数据资产沉淀(分业务域的实时数仓建模&业务公用逻辑沉淀等)、实时数据服务/分析(数据服务接口平台配置化、分析工具打通等)。

　　问题 3：实时数仓的应用场景主要有哪些?哪些业务场景更适合用实时数仓者解决方案?

　　实时的应用场景从普适场景下大的类目来说个人觉得主要分为三类，实时决策、实时监控、实时业务过程联动，实时决策主要指高管决策实时数据看板，用以辅助高管进行公司业务决策判断;实时监控分为几类，包括大促活动指标监控、业务系统稳定性实时监控、风控场景下反欺诈监控等业务场景;实时业务过程联动，包括实时搜索推荐、实时智能设备分析联动、实时营销内容/设备状态推送等业务场景。

　　问题 4：您认为实时数据仓库的最关键能力是什么?如何全面确保数据分析的实时性、正确性、稳定性?

　　其实这一点和离线数仓一样，对于数据相关从业人员，核心还是业务洞察力或者说至少是理解力以及数据分析和数据敏感度，其次才是特定职能的专业技术能力，包括对于数仓建模、Flink应用原理、调优策略、引擎侧技术深入能力、实时相关生态工具的构建能力等。再谈到如何全面确保数据分析的实时性、正确性和稳定性，这一块除了相关专业人员要具备上述的基础素质以外，更要有实时生态体系的建设保障，人总有失误的时候，完善的实时生态体系建设，包括多链路的联动保障、数据质量保障体系严控、扎实的数据资产沉淀、灵活的工具化/引擎能力的补充应用、底层自动化/半自动化的集群运维保障等，多面结合，才更能万无一失。

　　问题 5：实时数仓与AI、云技术等如何结合?能实现什么效果?

　　实时与AI的结合从引擎层面无论是Flink还是Spark都有相应的ML模块和对应的成熟应用以及平台结合，这一块的结合方式灵活度很高，具体结合方式还是要从业务场景出发，大到可以是通用化的平台工具能力沉淀，小到可以用算法模型结果数据或者算法应用接口来和实时串接，最终的实现效果不可一概而全，还是要从应用范围和具体应用场景来评判，比如淘系的实时搜索推荐AI算法结合和今天传统制造业B端的实时智能备货补货体感和效果表现一定不一样，但技术的最终落地点一定降本、增收或者提效，这是从工业界的业务现实诉求出发的。再谈到和云技术的结合，实时更多是底层集群基础建设的云原生架构部署，以期能够做到灵活的在线扩缩容、运维自动化和资源分配灵活智能化的沉淀等，实时应用从Flink的引擎角度来说，是一个24小时在线进程，更准确实时的通过不同的业务场景和数据波动周期的捕捉等，把运维也和业务自动的联结，从大盘上实现资源的动态隔离和分配，会更好的降低运维成本、提高运维效率、拓展运维实践深度。

　　问题 6：针对当前的传统企业，特别是智能家居企业，实时数据仓库的建设情况如何?对实时数据分析的需求，到底如何?

　　从目前的传统制造业或者智能家居企业来说，实时数仓还处于高速发展中的阶段，相比互联网核心C端业务的高并发超大数据量处理来说，传统制造业的业务场景一般会更复杂、领域中的业务链路也会更长，且由于业务系统主数据质量在不同业务领域的发展存在一定的差异性，因此后续的全域数据的处理应用需要考虑的因素也会多很多，目前在美的来说，经过过去2年左右的快速追赶建设，目前已经达到了实时2.0的阶段，可以较好的承载各业务域的实时服务和实时分析的诉求，通过和StarRocks的有机结合，实现了服务分析一体化，也计划在今年进一步的实现流批一体的应用和平台建设，运用更少的人力和存储成本来更加高效稳定的赋能业务。

　　问题 7：尽管实时数仓的最终实现效果都是为了数据实时性要求，但实际表现形式却“五花八门”，很多企业用云数仓、湖仓一体架构解决实时数仓需求。您如何看待这种变化?到底什么才是实时数仓?

　　其实不论是实时还是离线或者说准实时，今天的底层引擎、链路架构、实现方式都可以是包罗万象的，所有的架构体系的应用一定要从业务场景出发，工业界应用很讲究投入产出比，一个品种的植物生长在不同土壤下一定会有多多少少的差异，我个人不认为有普适一切业务场景的”落地”架构方案，实时数仓的业务诉求本质对比离线来说，就是时效性差异，某些超大数据量场景下，由于业务模式的特殊属性，甚至可以接受以细微的准确性损失来换时效性和稳定性，在这样的场景下，湖仓一体就不太能满足实时服务性的秒级时效性要求，但有些中等数据量长周期B端业务非大促场景更看重准确性，而对实时的时效性要求没有到秒级那么高，甚至个别业务并没有完全实现线上化，还存在手工补录的数据源依赖，需要不定时回刷数据，那么对于此类场景日常的业务过程跟踪来说，一般分钟或小时级也就足够，因此这种场景下，部分纯实时、部分准实时结合的架构或者湖仓一体的架构就足以解决和支持，但从湖仓一体这个命题目前的发展状况来说，底层基础建设和平台功能建设的完备性要求就更高，没有这些，相关实时研发人员的应用门槛就会很高。一定的企业业务背景下，大的实时架构生态肯定还是要有主流约束，比如实时计算引擎的选型、实时服务/分析应用存储的选型、甚至数据湖存储的选型等，至于相关之间的灵动联结，可以根据业务场景细看，不可一概而全。

　　问题 8：未来，美的实时数仓平台的规划主要包括哪几个方面?预期达到什么效果?

　　首先是实时集群基础设施的云化，能够做到云原生架构部署，这个是基础;其次是平台进一步的功能完善化，包括统一实时集成功能的配置化实现、细粒度的资源配置、流批一体研发支持、自动资源调优、更完善的实时应用生态监控告警体系等等;再次是引擎技术能力的发展和平台功能的有机结合，包括但不限于自定义数据源的支持、引擎多版本的支持、引擎特定功能的场景化应用优化的打通、引擎新特性的平台功能化引入。我个人预期的好的研发平台，是具备教学的功效的，可能今天一个刚接触实时的小白，也可以通过平台的应用了解，能够快速的上手进行相关的研发工作，并在过程中不断加深对于引擎应用原理和引擎底层的理解。

　　问题 9：企业对于数据实时性的要求，已经变得更加重要，甚至在某些情况下会大于我们数据分析的价值，请问您对实时数仓从业者有哪些建议呢?

　　最大的建议还是多去了解业务和加深自己的数据感知能力，技术更多是一种结果的落地达成手段，跨过入门阶段以及公司内部相对具备完善的实时生态体系建设的实时研发人员可以思考一下，在日常的工作中，更多花精力的究竟是业务需求沟通理解、方案&链路架构设计、数据模型的思考设计阶段还是纯粹的开发落地工作，另外结合公司的业务背景，思考下实时的业务应用范围。如果实时相关工作还是处于纯粹执行的阶段，并没有透过实时真正了解相关业务场景的需求目的，并有所思考和经验/工具体系沉淀，很难在实时这个偏横向的领域做到融会贯通。技术的发展尚且不断的通过吸收业务的目的和诉求去分析来持续优化，个人更是，保持好奇心，往整个数据链路架构上层、下层多看两步，实时是一门体系化的学科，你想做好实时，就不能只看“实时”。