各位朋友，上午好。我是周卫林，Aloudata 的创始人和 CEO。今天我演讲的主题是《NoETL 开启自动化数据管理新时代》。在这个主题中，有两个大家很熟悉的词：ETL 和数据管理。但同时，也有两个不太熟悉的词：NoETL 和自动化数据管理。我们是否在创造一种新的概念？今天我将回答这个问题，并通过回答这个问题来解释我们为什么要创立 Aloudata 这家公司，以及我们的定位是什么。
我在数据领域工作了 21 年，专注于大数据领域的学习、理解和问题解决。其中，我在阿里和蚂蚁集团工作了 15 年，在阿里巴巴时期担任数据仓库架构师 5 年多，在蚂蚁集团数据平台部任负责人 9 年多。我对这个行业有比较深入的了解和实践。
首先，我想从业务的角度来谈谈数据化运营和数字化转型时公司面临的典型应用场景和挑战。每家公司都会通过指标进行经营管理，比如公司层面的 KPI 指标，如收入。这些指标不仅要监控当前进展，还要与同期值、与目标值比较，并且要细化到不同部门，比如线上销售部门和线下销售部门。
这些指标一旦细化到部门，就会进一步拆解成更具体的指标。然后，这些指标会与不同团队绑定，例如渠道运营团队、商家运营团队、产品运营团队和会员运营团队。这样，团队可以通过 BI 平台、AB 实验平台等找到业务问题和优化机会，并将这些机会通过不同的运营工作台、营销投放平台等应用到业务系统中，从而推动业务的闭环发展。
总的来说，通过管理指标的方式，我们可以有效地管理业务。通过指标的上卷和下钻的能力，和跨多主体的指标分析等数据协同，可以实现多团队多组织的组织协同。
其次，我想从组织的角度来谈谈企业数据化转型对组织能力结构的演化，我分三个阶段进行介绍。
当企业处于信息化建设的成熟期，通常会在 IT 技术部内部分出两层：一层是面向业务场景的业务技术团队，例如面向商家事业部的商家技术部；另一层面向技术基础设施的平台技术团队，负责数据中心的规划、硬件设备的采购和平台的运维监控等工作。
从信息化往数据化发展，在数据化管理的早期阶段，组织结构中会增加一条专门负责 BI 的线，支持 BI 的数据技术团队可能会外包给 DT（Data Technolog） 供应商。
随着企业进入数智化运营的成熟期或中后期，不仅业务团队内部会有分析师、数据科学家和业务算法专家，技术部内部也会有专门的数据团队，甚至在业务技术团队里部也会有数据和数据工程师，形成一个面向业务场景的技术特种部队。这种组织体系结构是许多行业头部公司和互联网公司的常态。
通过上面从业务和组织两个角度的介绍，我们可以进一步分析数智化运营对数据管理的挑战。核心问题是随着场景的增加，数据链路也在增长，导致数据管道的复杂性增加。就像上面介绍的那样，由于越来越多的组织参与数据技术，这很容易导致数据管道的烟囱化，从而形成更为复杂的数据体系结构，进而导致数据交付效率和质量的双下降。解决这些问题是当前数据管理面临的主要挑战。
首先，我们面临的挑战之一是数据可用性的风险。数据可用性的风险主要是数据产出时效和数据质量问题。数据时效指的是数据链路没有延迟，可以按时交付，数据质量主要指的是数据的准确性和完整性。
在数据时效运维保障上有一个重要的概念是“任务基线”运维保障。当数据处理链路依赖加深且链路变长时，任务容易出现破线，当任务一旦破线且破线次数越来越多，定位和解决问题的难度也越来越大。例如，如果公司的管理层看板需要在早上八点准时更新，但由于上游任务的错误或延迟，数据无法及时提供，这就需要进行链路治理。在这种情况下，可能需要协调大量人员来解决问题，在大型金融机构，这种情况可能涉及上百人，需要拉群进行链路治理。这种做法的效果往往越来越差，因为靠人工在几万、几十万的任务里进行优化的代价和难度都非常大。这就形成了一个困境：如何有效保障数据的可用性。
为了解决这个问题，我们可以将任务分为两个阶段：开发态和运行态。在从开发态变更到运行态的过程中，很重要的是把基线管控列入发布管控，事前阶段确保基线设置的合理性至关重要，比如如果没有经验的人直接设定了任务的下游基线，比如说八点钟要完成，但实际上他们并没有客观地评估这个基线是否可行，一旦上线可能就会出现延迟故障，就会触发报警，这就是一个典型的问题。
另外，在事中阶段，可能没有设置预警和告警规则，或者当需要告警时联系不上相关责任人，所以这种情况就是典型的基线运营巡检需要处理的问题，一旦出现问题后，需要进行复盘，找出问题的根本原因。
这种机制可以帮助解决一部分数据时效性问题，但是造成时效性问题的还有可能是数据质量问题，比如说，上游的任务出错导致下游受影响，或者任务虽然正常运行，但产出的数据是错误的。这种情况下，问题发现得太晚，需要回溯上游数据，这会影响下游的任务执行，造成下游产出数据延迟。
要控制数据质量问题造成的数据可用性影响，涉及到数据质量控制（DQC）、数据任务调度配置、数据链路异常恢复和数据影响面评估等复杂问题，又需要一个更大更完整的数据可用性保障体系，需要制定一个数据可用性保障全景图的规划，这种规划从 DataOps 的角度来看，包括研发阶段，如开发、设计、测试、发布和运维等阶段，从数据管理和数据架构的角度，你需要将其分成不同的等级、维度和方面，比如研发规范、数据质量要求、成本控制和安全合规等要求，通过这些功能和平台能力来确保数据的高可用性。
数据可用性保障功能规划全景图这个需求一方面是由问题倒逼出来的，比如故障复盘；另一方面是当企业进入数智化运营阶段，数据已经直接参与到业务中了。例如在金融行业使用数据进行风控，做授信准入；例如在营销场景，数据可以用来影响广告投放和推广，当数据进入业务链路时，如果数据不准确，将直接影响业务效果，甚至导致业务无法开展。在这种情况下，数据技术体系与业务技术体系是融合的，从开发运维一体化的角度来看，DataOps 体系需要与 DevOps 体系对接打通，因此 DataOps 体系的发展可以从逻辑上学习 DevOps 的体系结构，借鉴引用完善形成 DataOps 体系，形成数据可用性保障功能规划全景图。
以上我们分析的是数据管理的第一项挑战——风险。
数据管理的第二项挑战是成本。随着企业产生的数据量的增加，表的数量也在增多，这背后意味着需要更多的计算存储资源。随着表和任务的增加，人力成本和技术要求也在不断提高。一个运行五年以上的数据平台，表数量和存储的增长曲线会越来越陡峭，数据仓库各分层的存储占用也会随之增加，尤其是应用层，因为企业内部对数据的使用越来越广泛，在组织结构上，业务技术部门和数据分析团队的参与使得表的数量持续增加，应用层的增长速度会明显快于中间层，形成 数据仓库“头大脚轻”的现象。
面对这种情况，成本管理成为一个挑战。传统的做法是采用运动式治理，例如数据模型重构或数据仓库重构。但是，对于运行了五年或更长时间的数据仓库系统，由于表的数量庞大，进行重构的难度非常大，甚至不可能实现。因为在十万张表的数据量级下，靠 ETL 架构师的个人能力已经无法看全了。
在业务领域，我们可以使用大数据和 AI 的技术去解决复杂业务问题，比如会员运营、商品交叉销售这样的一些场景。那么为什么不能用大数据和 AI 的方法来解决数据平台内部的问题呢？
所以我们的思路就是用数据治理数据，用行为来改变行为。
具体来说就是像业务场景里我们对用户打标签形成用户画像一样，我们也可以对数据资产进行刻画，给它打上标签。打标签可以有不同的角度，简单举几个例子，比如看数据的健康度，可以从穿透率、覆盖率、复用率和重复率等角度来打分，建立健康度仪表盘。
同样，类似于业务侧的会员运营体系会管理会员的生命周期，我们也可以建立数据资产的治理和运营体系，对数据资产进行生命周期管理。通过数据资产运营体系的运营动作，比如说组织“下存储送计算”这样的活动，给数据存储治理优秀的团队奖励更多的计算资源。另外可以建立数据资产健康度的红黑榜，通过这样的方式进行效果量化和展示，就可以比较好地促进各个数据团队落实和优化长效治理机制。
数据管理的第三大挑战是效率。不同于“风险”挑战和“成本”挑战，如果是站在我们过往的经验里，我觉得“效率”挑战这个事情是无解的，为什么呢？因为效率这个问题反映在多个层面。
首先，需求响应效率逐渐降低，原因在于当前的数据需求变得更加灵活，但平台却越来越复杂，从数据技术的角度来看，同样的需求，满足需求的周期正在变长，这是大家都有的体感。
其次，数据研发协同的效率也在下降。以数据模型重构为例，数据中间层重构完成后，需要让下游数据切换到新的中间层上，这个过程耗时很长。例如，在 8 月份，旧的中间层可能有 2000 张表，四个月后，可能只迁移了 60 张表，而新的中间层的表数量从 500 张增加到 1800 张。这是因为在进行中间层重构时，下游的末端节点可能不属于你的团队，这个团队有业务需求需要优先满足，而无法跟重构节奏同频。这就进入了一个进退两难的窘境：下游数据尚未切换，旧的中间层无法废弃，中间层团队需要同时维护二套数据链路。
再来看研发时间问题。随着需求和 ETL 工作量呈指数型增长，运维和答疑的工作量也在同步增加。这意味着在工程量增加的同时，花在运维上的成本也在增加，导致研发投入相对减少，效率进一步降低。
“效率”挑战背后的原因非常复杂。
首先，数据工程师与其他技术工程师有所不同。例如，如果是负责会员系统或交易系统的 Java 工程师，系统调用次数的增加会直接证明我的技术价值和技术能力，从而有助于我的职业晋升。然而，对于数据仓库的架构师和 ETL 工程师来说，他们的工作被下游依赖得再多，也不容易直接体现技术深度。这是因为数据仓库本质上是一个 Serverless 平台，其稳定性和计算能力主要由计算存储引擎团队负责，尤其是在大数据和分布式计算普及后，系统的弹性扩容变得非常简单，ETL 工程师只需确保作业正确执行和模型设计合理。更多的下游依赖不仅不能体现技术深度，还带来了更大的运维工作量和更多的责任，这就导致数据技术体系从“我为人人，人人为我”的模式转变为“人人为我，我为自己”。这种变化导致了每个团队只负责自己的部分，不再承担整体责任。
其次，从下游的角度来看，如果我负责风控或营销业务，我需要为我的业务数据的质量和完整性负责。如果上游数据提供者不承担相应责任，我怎么能放心使用他们的数据呢？这种情况下，业务数据团队可能会选择构建自己的数据链路，从而确保全链路质量，这种做法类似于农耕时代的自产自销。
最后，数据团队的去中心化趋势是不可逆的。随着业务数智化程度的加深，业务与数据相互融合，业务团队内部自然而然地会培养数据意识，提出更多数据化业务需求，这类业务需求也是数据需求，二者往往是不可分割的，这就要求业务技术团队也需要有数据处理能力，因此一个数据化业务需求涉及多个不同团队的协同，而协同问题的解决往往是非常棘手的，这背后是组织架构和文化问题。当问题发展到这一阶段时，你会发现这种问题似乎无解，因为作为数据技术团队的一员，我们很难解决这些 CTO 或 CEO 层面的问题。
总结一下，我们面临的挑战是：在风险、效率和成本之间很难达到平衡，甚至两者之间的平衡都难以实现。这正是 Aloudata 创立的出发点——通过技术创新，来解决这一数据管理的困局。
要解决这个问题，我们首先需要明确其产生的根因。技术是为了服务业务的，随着互联网和移动互联网的兴起，数据需求从稳态需求转变为敏态需求，这导致我们的 ETL 工程量的指数级增长。
但我们 ETL 工程师的人数和能力却是有上限的。因此我们上面提到的大型企业为了应对数据挑战而实施的诸多策略与机制都是不断把功能做得更多更全，把制度和规范制定的更多更全，却无法从根本上解决数据管理的困境。
因此我们需要跳出传统的 ETL 工程师驱动的模式，寻找全新的思路。
我们认为，数据管理的本质是追求一份统一的数据资产。如果我们能够实现“一份数据资产”这种干净的状态，那么数据的管理问题、效率问题以及成本问题自然可以得到全面解决。但如何实现这一目标呢？是在物理上、逻辑上或在某个局部实现“一份数据资产”吗？
Aloudata 给出的解决方案，就是我们首倡的 NoETL 概念。其核心目标有三个：看得清，管得住和变得动。即可以更清晰地看到数据流动，更有效地管控数据口径，以及更灵活地应对业务需求的变化。
“看得清”，需要元数据。类比业务侧通过构建商家画像和用户画像从而实现智能运营，通过元数据我们可以创建一份对数据的画像，通过血缘分析让数据资产看得清。
“管得住”，数据管理的关键不在于管理数据和表本身，而是管理数据的业务含义，即数据口径，也就是业务语义，因为真正的资产价值是数据口径和业务语义，代表的是业务知识的沉淀。表里的数据只不过是业务语义的计算结果的固化。
“变得动”，是最具挑战性的，因为它涉及到组织协同，是一个复杂的问题。比较可行的解决方案是数据虚拟化，我打个比喻，方便大家理解。在商业世界中，存在着线下零售和线上零售。线下零售的逻辑非常类似于传统 ETL 的逻辑，即通过多层数据搬运，例如一级批发商、二级批发商到零售商，以满足客户需求。在门店，为了满足业务场景，往往需要备足货物，这就导致了库存积压。为什么呢？因为为了业务的灵活性，你必须备足够的货，而这些货物不可能全部被购买，总会有库存，从而导致经济性下降。
那么，线上零售是如何操作的呢？线上零售的逻辑是，商家发布商品，形成商品库，消费者通过搜索商品库找到商品加入购物车，下单，商品随后被配送。在这个过程中，库存问题会得到极大的缓解，而商品送达的及时性问题，则可以通过物流端的优化来解决，例如通过设置中央仓或前置仓来提高物流效率。
我们提出的 NoETL 理念，类似于线上零售，即基于数据虚拟化的自动化 ETL 编排，旨在通过重构 ETL 和数据管理方式来实现这一目标。这种方式类似于企业从物理搬运转向虚拟化逻辑构建的过程。
正如电商世界中的三种模式：从线下到线上、只做线上（完全虚拟化），以及从线上到线下。我们的理解是，虚拟化与传统数仓的方式需要结合起来，根据企业的特点来实施，这看起来是一种比较稳妥且可持续迭代的方法。我们已经有许多客户采用这样的方法来应用和实施数据虚拟化技术。
Aloudata的 NoETL 理念与 Data Fabric 不谋而合。Data Fabric 的核心在于引入了一个切片，这个切片位于业务场景与数据之间，通过语义化的交付方式，旨在快速满足业务需求并隔离背后的复杂性。在当前的数据管理和分析领域，虚拟化技术的应用日益重要。这种技术允许我们在没有物理移动数据的情况下进行信息流的管理，类似于电商平台在处理商品信息流时的方式。这种方法不仅提高了效率，还简化了数据处理流程。
在 NoETL 的整体思路下，我们推出了三款产品。旨在帮助数据团队不再进行复杂重复和不经济的层层数据处理，而是首先明确业务的数据口径，然后再构建相应的数据集和指标，以及实现更加智能的数据管理。
Aloudata AIR 是一款逻辑数据平台。AIR 的典型场景是企业的业务开展可能存在多个云平台或多个区域的数据中心，特别是在涉及跨境和合规问题时，我们的解决方案能够支持多云环境下的数据集成与查询。这种多云联合分析的场景，可以有效应对合规监管等需求，允许企业灵活地进行数据分析和决策支持。
AIR 的另一个典型的应用场景是大型集团公司，这些公司下属有多个不同的业务实体。在这种结构中，各个子公司可能各自拥有独立的数据仓库。总公司层面如何有效访问和管理这些分散的数据成为一个挑战。通过数据虚拟化，总公司可以无需物理迁移所有数据，而是通过虚拟化技术直接访问和分析各子公司的数据，极大地简化了数据管理和分析过程。
在先进制造领域，一家拥有众多工厂的企业，每家工厂的需求各不相同，简单地用一套方法管理所有工厂显然不是最佳选择，因此每家工厂可能都有自己的信息化系统和数据分析平台，企业可以通过虚拟化技术访问和分析各个工厂的数据。
这些场景展示了数据虚拟化在现代企业中的强大应用潜力，特别是在处理复杂的数据结构和多源异构环境中，提供了一种高效、灵活的解决方案。
第二款产品 Aloudata CAN 是一款 NoETL 的自动化指标平台。指标的应用覆盖了从管理层看板到部门看板，再到运营活动和业务闭环运营的全过程。这种基于指标的管理方式，能够有效支持企业的决策和运营。我们从 NoETL 的角度出发，关注的是如何通过自动化技术来优化指标的生产、消费和统一管理。这种方法的核心在于通过定义清晰的语义，对数仓中间层和应用层进行建模，然后通过自动化构建和物化加速实现指标的定义、开发、管理、消费的一体化。
Aloudata BIG 是基于算子血缘解析能力的主动元数据平台。正如我前面介绍的，在处理大规模数据时，如何有效管理和利用这些数据成为了一个挑战。这就需要一个强大的 DataOps 体系来支持，该体系包含了数百个功能项，但真实场景下，并非所有数据需求都需要完整走过这些功能流程。因此，基于具体的业务场景进行数据需求的分类和分级，选择合适的流程至关重要。
这种流程的设计和实施，最终都依赖于元数据的支持。没有元数据的驱动，平台只是一个简单的工具箱，无法有效地支持研发过程和数据管理。数据管理的理念、思想和控制能力必须体现在研发流程中，我们需要利用元数据来引导研发流程并实现研发流程的智能化，如果缺乏这样的能力，再多的工具也只是堆砌，无法形成真正的数据管理解决方案。例如在实施 DataOps 体系时，一个关键的环节是模型的 Review，包括判断模型是否符合要求以及是否存在重复或需要优化，这需要一套基于元数据的算法来实现。
上述三款产品均在头部金融企业的生产场景中获得了验证。
最后我想分享一下 NoETL 的本质， 传统数据管理体系是通过 ETL 工程师来驱动的。随着数据需求的大幅增长，数据链路的日益复杂，ETL 工程师在数量和能力上都存在上限。在这种情况下，我们只能通过 NoETL 来重塑数据管理，NoETL 的本质是自动化，而 ETL Agent 是这种自动化的终极实现，成为推动整个新一代自动化数据管理的关键。
希望我的分享能对大家有所帮助，谢谢大家。
