聊聊云原生数据平台

2022 年 8 月 10 日
浙江
本文字数：15356 字
阅读完需：约 50 分钟

本文作者：字节，观远数据首席科学家。主导多个 AI 项目在世界 500 强的应用落地，多次斩获智能零售方向 Hackathon 冠军。曾就职于微策略，阿里云，拥有十多年的行业经验。

在之前的文章中，我们介绍过云原生机器学习平台的组成和搭建[1]。在实际企业应用中，机器学习平台非常依赖于企业底层的数据平台，虽然这两年 AI 的热潮一波接着一波，但要很好地去落地算法应用，非常依赖于数据平台的基础建设。从 a16z 的一些分析报告[2] 中也可以看出，目前数据平台类公司吸引了非常多的市场和资本关注，也应运而生了 modern data stack[3] 之类的概念。这篇文章我们就来聊聊什么是所谓的云原生数据平台。

1. 发展历程

最早的数据平台来自于关系型数据库（RDBMS）技术，从一开始以记录业务运作数据的 OLTP 系统开始，逐渐发展出了对业务情况做数据分析并进一步采取决策的相关需求，也就是所谓的 OLAP 系统，其中包含了很多经典的理论和技术方法。

在 1980 年代，出现了针对数据分析需求建立数据仓库系统（Data Warehouse）的设计方法，成为了最早一代的“数据平台”系统。1992 年，著名的“数仓之父”Bill Inmon 出版了《Building the Data Warehouse》一书，形成了一套自上而下中心化地构建企业级数仓的方法论。另外一位大佬 Ralph Kimball 则在 1996 年出版了《The Datawarehouse Toolkit》一书，提出了自下而上基于 Data Mart 的概念来构建企业级数仓的思路。在上世纪 90 年代，这两位大佬的书几乎成了从业者的必读权威著作，企业级数仓的概念也逐渐开始普及，与 BI 分析应用一道被各大企业广泛采纳和部署。当时主流的软件系统都来自于各大商业闭源软件，如 IBM DB2，SQL Server，Teradata，Oracle 等。

到了 21 世纪初，互联网的概念开始兴起，在数据处理分析方面，“大数据”的挑战也应运而生。传统的数仓技术已经难以应对互联网时代海量的数据，快速变化的数据结构，各种半结构化非结构化数据存储和处理的需求。从谷歌发表的三篇经典论文（MapReduce，GFS，BigTable）开始，出现了与传统关系型数据库技术有所不同的分布式数据系统技术栈。这一趋势被后来的 Hadoop 开源生态发扬光大，在业界形成了长达十多年的深远影响。记得当时去参加各种技术会议，大家都在聊“数据湖”，NoSQL，SQL on Hadoop 等技术和理念，互联网公司们采用的数据平台也大都是基于 Hadoop 这套开源生态体系（HDFS，Yarn，HBase，Hive 等）构建起来的。市场上也涌现了著名的 Hadoop 三驾马车，Cloudera，Hortonworks 和 MapR。

随着 AWS 引领的云计算浪潮的崛起，大家越来越意识到 Hadoop 系统架构的各种问题，包括存储和计算资源绑定，非常高的运维难度和成本，无法很好地支持流式数据处理，交互式查询等。云原生时代一个非常大的变化是大家都倾向于降低各种系统的拥有成本和运维成本，由云厂商来提供专业的服务。另外一大趋势是对极致的“弹性”能力的追求，比如现在一些云数据仓库甚至可以做到按单次查询所消耗的计算量来收费。这些要求在 Hadoop 生态相对来说都比较难实现，因此逐渐出现了新一代的云原生数据平台的理念，也是本文主要讨论的主题。

2. 数据平台架构

2.1 经典数仓架构

在传统视角中，数据平台就约等于数仓平台。所以只需要 ETL 工具，把数据从各种数据源中载入到数仓中，然后用 SQL 做各种处理，转换，构建数仓分层体系，再通过 SQL 接口对外提供服务即可：

传统数据平台

2.2 数据湖架构

但随着业务的发展，大家逐渐对数据平台的能力有了更多的要求，包括经典的四个 V 中的几点：

Variaty，数据的多样性。比如需要存储和处理各种半结构化的 Json，Avro，ProtoBuf 类型的数据，或者是非结构化的文本，图像，音频，视频等。这些内容的处理，往往 SQL 就会比较难以应对了。此外需求方面也变得更加多样，除了 BI 类分析，AI 类的分析建模需求，业务系统对分析结果的消费等也变得越来越普遍。
Volume，数据的量级。随着业务在线化，数字化的转变，数据驱动的思想越来越普及，现代企业需要存储和处理的数据量级也变得越来越巨大。虽然传统的商业数仓软件可以支持水平扩展，但往往其架构是绑定了存储和计算的，这就导致其开销非常的巨大。这也是现代数据平台中非常显著的一个差异点。
Velocity，数据的变化速度。在一些数据应用场景中，逐渐开始出现了自动化实时决策的需求。例如用户在浏览了一些商品后，系统可以获取到新的行为数据而实时更新用户推荐内容；或是结合用户最近几分钟的行为作出的自动风控审核决策等。在这种情况下，传统的 T+1 形式的数仓作业显然就无法满足需求了。

在这些需求的驱动下，数据平台的架构向着更加复杂的结构演化，也开始引入很多知名的大数据系统组件如 Hadoop，Spark 等。其中比较知名的有 Storm 作者 Nathan Marz 提出的 Lambda Architecture:

Lambda 架构

这个架构在设计上还是经过了很多经验总结和深思熟虑的，核心还是每天的全量数据的批处理（Batch Layer），相比传统的基于 SQL 的数据转换，可以支持更加丰富的数据类型和处理方式，同时借助 Hadoop 架构也能支撑更大的数据量。同时为了支持“实时”需求，增加了流处理层（Real-Time Layer），最后在数据消费时，可以再把这两块的数据结合起来（Serving Layer），形成最终的结果。不过这个架构也受到了一些诟病，尤其是需要维护批处理和实时两套计算框架，且要重复实现两遍相同的处理逻辑，在架构复杂度上和开发维护成本上都有不足。后续 Kafka 的作者 Jay Kreps 又提出了 Kappa 架构，想将批处理和实时处理统一到一起，有点“流批一体”的意思。

Kappa 架构

但个人感觉 Kappa 架构又太理想化了，即使到了 2022 年，流式数据也还远没有成为行业主流。对于消息流的数据重复，消息顺序，复杂计算（如实时 join）之类的支持，各类源数据系统的支持，数据 schema 的管理，数据存储的成本控制等方面，都还没达到非常稳定好用且高效的状态。所以要让一个企业的数据完全跑在流式数据系统基础上，目前看还是不太现实的。因此现阶段比较主流的数据平台架构实际上还是从业务需求和全流程系统成熟度出发，把批处理系统和实时处理系统进行了结合。

2.3 云原生架构

对于各种组件的组合需求，伴随着云原生时代的到来，出现了越来越多更加易于直接“组装使用”的 SaaS 数据产品。相比之前部署运维 Hadoop，Kafka 集群的复杂度，新一代的云原生产品一般都可以直接使用托管服务，按量付费，即开即用，对于非互联网类公司来说非常友好。所以常见的数据平台架构都开始往引入各种产品组件的方向发展，出现了很多有意思的新思路：

在数据处理层面，会使用不同的计算引擎来执行批处理或者流式处理的任务，但对于用户接口来说，希望尽可能保持一致，于是就有了所谓的“流批一体”。
在存储和数据服务层面，曾经“数据湖”和“数据仓库”两者争得不可开交，但在几年的发展后发现也并不能完全替代对方。于是数据湖阵营增加了很多 SQL，Schema，数据管控这些功能的支持，成为了新物种 lakehouse。而数据仓库也都走向了云原生化，很多云数仓也支持使用他们的计算引擎直接对数据湖上的文件进行计算处理。“湖仓一体”也成了一个热门名词。
此外还有 feature store 中对于批量和单点查询特征的需求，实时分析和数据消费应用的需求结合而生的“HSAP”等等，不一而足。

著名的投资机构 a16z 给出的统一数据架构总览就很具有代表性：

a16z 的统一数据架构

这张图画得非常详细，把整个数据流转的过程分成了数据源（一般不包含在数据平台里），数据获取与传输，存储，查询处理，数据转换和分析输出这几大块，而且每一块中的各个模块，相关的产品都做了详细的标注。一般企业都会根据需求来选择其中的部分组件进行部署，例如如果没有流式数据的需求，那么就不需要下面那部分流式数据接入和处理的部分。而跟 Lambda 架构不同的是，对于同一个业务场景，一般也不需要让同一份数据既经过实时处理链路，又在 T+1 时经过批处理链路做两次，而是选择合适的一条链路去做后续处理即可。

不过上述的架构图因为考虑到不同企业不同场景不同阶段的需求，画的有些过于复杂了，个人更喜欢在《Designing Cloud Data Platform》一书中，作者给出的一张相对精简的架构总览：

云数据平台架构

这个架构在核心上与 a16z 给出的架构参考是基本一致的，不过在各个 layer 的拆分设计上更加的清晰一些，有助于我们理解和规划整个数据平台。如果能将各个 layer 之间的职责，接口定义清楚，那么对于数据流程的标准化，组件实现的灵活替换升级也会非常有好处。后续我们会根据这两张图来展开描述云数据平台的各个组成部分。

总体来看数据平台架构近年来的演变趋势主要有两个方面，一是为了满足多样化的业务需求，平台整体的系统组件越来越多，处在一个高度分化的阶段，但又希望能对用户保持透明；二是组件的选择会倾向于选择各类公有云厂商或者数据 SaaS 平台厂商的产品，在架构较为复杂的情况下并没有提升太多的维护成本，但组件间的职责明确（松耦合）和接口标准化仍然是一个挑战。

3. 数据获取

在数据获取方面，平台必须能够同时支持批量数据和流式数据的接入。

各类数据接入

3.1 批量获取

对于批处理数据，比如各种上传文件，ftp，或者其它无法支持实时消费的第三方 API 数据源。实际上大多数企业目前对接的各种数据源和企业内部的基础数据架构，基本都是以批处理的形式为主的。绝大多数的平台对于这块的支持都还是比较好的。典型的做法是定时触发任务，通过组件去数据源中获取全量或者增量更新的数据内容，存放到数据平台中。如果把这个任务触发设置的比较频繁，我们也可以通过批处理的方式得到一个“准实时”更新的数据内容进行后续分析和使用。

3.2 流式获取

流式数据是近年来非常热门的趋势方向，但在互联网公司之外的应用还相对比较少。大家对于“实时”的理解也各不相同。比如对于分析场景来说，大家普遍的认知是 T+1（第二天看到截至前一天的情况）的数据更新属于批处理，只要一天内有多次数据更新的，就属于“实时”分析了。这类需求完全可以通过前面提到的小批量更新来实现。而对于一些自动决策场景，例如推荐系统，交易风控，即使做到分钟级的“小批量”更新，其时效性也是不满足需求的，必须对接流式数据系统。

一个比较有意思的场景是对接上游业务系统的数据库数据。如果采用批处理接入的方式，一般做法是通过一个更新时间戳去定时查询相关的数据表，然后把增量数据保存到数据平台中。这个做法看起来没啥问题，但实际上如果在更新的时间窗口里，原始的数据条目做了多次变更，例如用户在 5 分钟里先开通了会员，然后取消，通过批量查询的方式，可能两次查询下来用户都是非会员的状态，丢失了中间的状态变更信息。这也是为何现在有越来越多的场景会使用 CDC 的技术来捕捉业务数据的实时变化，通过流式数据的方式对接到数据平台中来，避免有任何的信息丢失。

这块建议的建设路径是先构建稳定的批处理数据接入能力，然后是流式数据获取，最后才是根据实际需求考虑流式数据处理和分析（引入 Flink 这类）。

3.3 需求与产品

对于数据获取的组件，需要满足以下几个要求：

插件化架构，支持多种数据源的数据接入，如不同的数据库，文件，API，流式数据源等，支持灵活的自定义配置。
可运维性，因为需要与各种第三方系统打交道，各种信息的记录，出现错误时的排查的便利性都非常重要。
性能与稳定性，为了应对大数据量，重要分析决策流程的稳定运行，需要有企业级的平台质量保证。

数据获取这块可以考虑使用的产品也有不少：

三大云的相关服务，例如批处理方面的 AWS Glue，Google Cloud Data Fusion，Azure Data Factory；流数据方面的 AWS Kinesis，Google Cloud Pub/Sub，Azure Event Hubs 等。
第三方 SaaS 服务，如 a16z 提到的 Fivetran，Stitch，Matillion，Airbyte 等。
开源框架，如 Apache NiFi，Kafka，Pulsar，Debezium（CDC 工具）等。
基于 Serverless 服务来自行开发数据获取功能。

注意涉及到云服务，第三方 SaaS 服务，开源或自研工具选型时，可以参考下图来做权衡评估。越靠近右端如云厂商的产品，需要的运维开发投入就越小，但可控性和可移植性就相对较弱（除非兼容开源框架的标准 API）；越靠左的情况则反之，使用开源产品具有非常灵活的定制（但要注意控制私有分支魔改成分）和部署灵活度，但投入的研发运维成本就会高很多。

产品选择的权衡

4. 数据存储

在进行数据获取后，就需要把数据保存到平台存储中。在前面的数据平台架构图中，我们看到作者把存储分成了 fast，slow 两块：

快慢存储

4.1 Slow Storage

这个 slow storage 相对比较好理解，在数仓时代就是 warehouse 系统里的存储部分，在大数据时代就是所谓的数据湖，之前比较流行的是 HDFS 这类分布式文件系统，目前越来越往存算分离的方向发展，主流的存储方式基本都选择了各种对象存储，如 S3，GCS，ABS 等。数据湖的存储形式上比较自由，数据质量，企业管控等方面经常难以得到保证，所以这两年 Databricks 又提出了 lakehouse 的概念，其中存储方面在底层对象存储之上又搭建了相应的元数据和存储协议，能够支持 schema 管理，数据版本，事务支持等特性，我们之前也在算法平台中的数据湖系统[4] 一文中有过介绍。

4.2 Fast Storage

这个 fast storage 可能就比较容易误解了。在 Lambda 架构和 a16z 的架构图中，fast storage 一般指对数据消费者提供即席查询，实时分析服务的存储系统，例如我们可以用一些实时性较高的分析型数据库（Presto，ClickHouse），或者针对性的存储服务如 KV 系统，RDBMS 等。而在作者提供的这张图里，fast storage 其实代表的含义更简单，就是流式数据系统的自带存储，如 Kafka，Pulsar 系统存储事件消息的部分。这是不是感觉又回到计算和存储绑定的老路上了？所以现在 Kafka 跟 Pulsar 也都开始支持 tiered storage[5] 了，提升整体的可扩展性，降低成本。

Tiered Storage

4.3 数据接入流程

从数据接入层进入的数据，一般会以原始数据的方式直接存放到 slow storage 中，后续再通过其它的处理调度转换成后续需要使用的形式，如 lakehouse 中的表或者对外提供服务的数仓中。流式数据进入到 fast storage 后，实时处理分析组件会来获取和消费其中的数据，最终触发下游的数据更新。同时流式数据一般也会通过一个实时处理流同步把原始数据保存一份到 slow storage 中，以便后续有其它使用需求可以进行灵活的处理操作。实时系统自带的 fast storage 中的消息，一般只会保留一段时间，避免高昂的存储成本。这里可以看出 slow storage 需要存储的基本是全量的数据，其开销会非常大，这也是为何现在一般主流都会选择廉价易扩展的对象存储系统的原因。

4.4 需求与产品

对于存储组件，一些重要的特性需求包括：

高度的可靠性，丢数据绝对是最不能接受的，一般 CAP 中只有 C 是不能妥协的一个特性。
可扩展性，需要能非常轻松地做存储空间的扩缩容。
性能，slow storage 需要有比较好的吞吐量，支持消费者的并发大数据量的获取。而 fast storage 需要有非常好的小数据量读写响应速度。

存储产品方面云厂商的服务应该是主流选择，毕竟自己搭建维护存储集群太复杂了。也有一些开源项目基于这些云厂商的对象存储做了一些附加功能（例如支持 POSIX）和优化，如 lakeFS[6]，JuiceFS[7] 和 SeaseedFS[8] 等（后两个都是国人的项目）。

5. 数据处理

数据处理是整个平台中比较复杂，也是各种流派争夺比较激烈的部分。最典型的做法是使用两套计算引擎来分别支持批处理和流处理，与数据获取部分一致。这样做的好处是可以针对业务场景选择最合适的技术，且更能发挥框架本身的特长。绝大多数公司都是以批处理需求为主的，那样的话在一开始也就没有必要引入流处理引擎了。

5.1 批处理

批处理方面最流行的框架莫过于 Apache Spark，作为一个老牌开源项目，社区活跃，发展阶段较为成熟，功能上也非常全面强大，除了典型的结构化数据处理外，也能支持非结构化数据，图数据等。如果是以结构化数据为主，那么老牌的 Hive，以及 Presto，Dremio 等新晋力量也是非常不错的 SQL 计算引擎选择。在做海量数据的批处理时，也会涉及到不少优化手段，如各种 join 方式的选择，任务并行度的调整，数据倾斜的处理等，这里就不具体展开了。

5.2 流处理

流处理方面国内听到最多的肯定是 Apache Flink 了。此外像 Spark Streaming，Kafka Streams 也都提供了相应的流处理能力。对于一些复杂计算逻辑，流式计算上的开发门槛还是相当高的，而很多需求其实不一定要在流处理中做复杂计算也能实现。例如我们可以把数据简单处理后实时写入到实时分析型数据库，如 ClickHouse，Pinot，Rockset，或者像 ElasticSearch，KV 存储，in-memory DB 之类的系统中，也能提供流式计算一大部分的需求满足，后面我们会介绍相应例子。流式处理也跟批处理一样，需要做各种性能，扩展性的优化工作，比如指定分区逻辑，解决数据倾斜，checkpoint 调优等。

5.3 流批一体

最近几年流批一体的概念也比较火，尤其是 Flink 社区，认为批处理只是流处理的一种特殊形式，完全可以使用统一的框架来完成。这跟前面提到的 Kappa 架构差不多是一个意思。当然也有从软件层面来做统一的尝试，例如 Apache Beam，可以使用相同的 DSL 来做开发，底层执行时再转换到 Spark 或者 Flink 上分别执行批处理和流处理。

Flink 的流批一体

Beam 的流批一体

5.4 需求与产品

对于数据处理组件，需要满足的要求有：

计算的水平扩展能力，能够使用多节点来进行大数据量的计算。
稳定性和可用性，多节点的 failover/recovery 能力。
灵活开放的 API/SDK/DSL 支持，如可以使用 SQL，或者各类主流编程语言开发处理逻辑。

批处理产品除了前面提到的各种开源框架，云厂商也有提供各种 managed service，包括我们耳熟能详的 AWS EMR，Google Dataproc 或 Cloud Dataflow（基于 Beam），Azure Databricks 等。

流处理产品包括云厂商提供的 AWS Kinesis Data Analytics，Google Cloud Dataflow，Azure Stream Analytics。此外也有一些知名的 SaaS 厂商，包括 Kafka 的“官方”公司 Confluent[9]，Upsolver[10]，Materialize[11] 等。

流式数据处理公司 Materialize

6. 元数据

传统的 RDBMS 经过了多年的行业应用，产品打磨，在元数据方面做得还是比较完善的。而云数据平台因为还没有普及，在各家公司内部搭建过程中往往容易被忽略。这部分的能力实际上作为企业级成熟产品是至关重要的一环。

6.1 平台元数据

平台在运行过程中会产生各种信息，例如配置的各类数据源，数据获取的执行情况，数据处理的执行情况，数据集的 schema、统计信息、血缘关系，系统的资源使用情况，各种日志信息等等。通过这些信息，我们可以对各种平台任务进行监控和告警，当出现问题时也能通过这些信息的查看进行方便地排查处理，而不是分别登录到各个模块的管理控制台上去一一检查。

平台元数据类型

Schema 这块是一个比较大的话题。相对于基于关系型数据库技术的数仓系统来说，云数据平台在灵活的处理数据集 schema 的变化方面具有一定优势。大多数的云数据仓库在处理 schema 变化时，都会对其服务造成一定影响（例如需要锁表）。而很多 lakehouse 则可以比较好地支持 schema evolution，例如 Delta 里的 mergeSchema 选项。当然这个功能也并不是万能的，在整个数据平台中，涉及到各种数据的处理转换，各个环节的交互配合，下游系统如数仓，实时分析数据库的写入和其它外部系统的消费，我们必须对 schema 进行严格的记录和管理。

元数据中的 Schema Registry

另外一块非常重要的元数据类别是数据质量。随着企业数字化进程的推进，涉及到的各类数据源越来越繁多，内部的各种数据处理转换也越来越复杂，且各类企业决策越来越依赖于数据内容和相应的分析结果，如何保证我们在整个复杂度上升的过程中仍然保证“数据产品”的质量和整体的迭代运维效率，成了一个非常关键的问题。这类诉求推动了所谓 DataOps 运动的产生，借鉴 DevOps 中如何维持企业开发，交付，运维复杂软件的经验，将其应用到了数据产品领域。

DataOps Cycle

这其中非常重要的一环就是数据质量检查的持续监控测试，并应用于数据流 CI/CD，以及数据管控，数据发现等环节。这也催生出了一类新的产品，称为“Data Observability”，非常形象地表达了洞见数据平台中整体数据健康状态的目标。

6.2 业务元数据

除了技术层面的元数据外，在业务上也有相关的元数据管理和使用的需求。例如平台数据集多了之后，管理和搜索就会比较复杂，基础的文件夹结构可能难以满足需求，所以我们需要支持对数据集的描述，打 tag，搜索等功能，帮助业务用户更快地找到合适的业务数据信息。所谓的 Data Discovery，Data Catalog 产品一般就是为了满足此类需求。

此外根据公司业务的不同，还需要遵循相应的数据合规要求，如个人信息的隐私保护，支持用户的各类数据权利和自由等。这方面的能力也需要专门的元数据管理和数据管控（governance）支持。典型的公司有 Collibra 等。

6.3 需求与产品

对元数据组件，常规的需求肯定还是需要保证高可用和扩展性能，当平台规模较大时，元数据的规模量级也会非常可观。此外一个重要的是灵活性和扩展性，比如支持用户自定义的元数据内容，通过开放 API 来提供对外服务等。在数据处理，流程编排执行，以及后续数据消费等模块中，都需要与各类元数据打交道，因此一个设计优良的元数据服务也越来越受到大家的重视。

这个领域相对来说比较新，云厂商提供的产品不一定能满足所有需求，如 AWS Glue Data Catalog，Google Data Catalog，Azure Data Catalog。

也有一些开源厂商有提供相关服务，平台元数据方面相对比较少，比较有代表性的是 Marquez[12] 。而在业务元数据层面或综合性的比较多一些，有 Apache Atlas[13]，Amundsen[14]，DataHub[15]，Atlan[16]，Alation[17] 等。

Atlan 功能介绍

对于 Data Observability 这块，也有很多我们熟悉的开源工具和产品，例如 AWS 开源的基于 Spark 的 Deequ[18]，“碰瓷”狄更斯的 Great Expectations[19]，Monte Carlo[20]，BigEye[21] 等。

BigEye

7. 数据消费

数据平台对外提供的服务相比于数仓时代也丰富了许多，除了典型的数据分析型应用，也开始涌现出流式数据消费和数据科学，机器学习类应用需求。为了满足不同的需求，云数据平台可以在松耦合组件化的设计思路下，引入或对接各类专用数据系统，灵活扩展其服务能力。

各类数据消费需求

7.1 分析查询

对于 BI 数据分析类需求，绝大多数的应用都是通过 SQL 来进行数据的查询获取的。由于自助式数据分析需求的兴起，对于查询的灵活性，交互的时效性（一般需要亚秒级到秒级响应），以及对大数据量处理的要求越来越高，传统的 Hive，Spark 查询由于响应时间的问题往往无法满足需求。在这个背景下也出现了很多相应的解决方案：

云数仓，如三大厂商的 BigQuery，Redshift，Azure Synapse，或者第三方的 Snowflake 等。在结构化数据处理需求为主的情况下，甚至可以直接以这些系统为核心，替代传统数仓来打造整个数据平台。
Lakehouse，例如 Spark 的商用版计算引擎 Photon，或者 Presto，Dremio 等技术，基于一些数据湖上的 open format（Delta，Hudi，Iceberg）做高效的查询处理。
开源实时分析数据库，如前面多次提到的 ClickHouse，以及各种新涌现的项目如 Apache Doris[22]，Databend[23] 等。

7.2 数据科学

在数据科学，机器学习领域，目前最重要的生态都是基于 Python 构建的，其典型的运作方式会通过 notebook，Python 脚本等方式，直接从数据存储层获取大批量的数据来进行统一处理并用于后续模型训练等，比较少需要通过 SQL 来执行复杂的查询。在这种情况下，如果可以直接访问 slow storage 中的原始文件，那么成本开销自然是最低的了。当然这样做也有坏处，比如数据的管控，权限等就会难以保证。

另外如果考虑整个机器学习的开发，部署，监控全流程，那么就会引入另外一大坨 MLOps 相关的需求，其中像数据这块的需求涉及到 Feature Store，里面的批量和实时特征请求模式的区别，也跟我们讨论的数据平台中批量获取和单点查询的需求有所对应，在建设时可以考虑是否能复用部署组件。

机器学习相关 Infra

关于 MLOps 相关的讨论，也可以参考我之前的这篇 MLOps 简介[24]。

7.3 实时消费

最后，对于流式处理和分析的结果，也会有相应的应用来进行实时消费。可以通过实时结果推送，写入关系型数据库，KV 存储，缓存系统（如 Redis），搜索系统（如 ElasticSearch）来对外提供服务。很多流式处理系统如 Flink 也支持实时查询，可以开发特定 API 来直接从流式系统中提供数据结果。

7.4 权限与安全

在企业级应用中，用户权限的控制，各类操作记录的审计和监控，包括数据脱敏，加密等方面的需求至关重要。除了平台本身要重视这方面能力的支持外，我们也可以考虑利用各类相关的云服务，例如 Azure Active Directory，Auth0[25] 之类的身份认证服务，Immuta 这类数据安全公司，以及云厂商提供的各种 VPC，VPN 相关的网络安全服务等。

7.5 服务层产品

除了前面提到的云数仓，lakehouse 和实时分析数据库，也有类似 Metric Store 之类的产品，构建在各类数据源之上，对外提供统一的服务。如 LookML[26]，Transform[27]，Metlo[28] 等。

Metric Store

8 流程编排与 ETL

8.1 流程编排

传统数仓架构中，编排工具也是极其重要的一环，在云数据平台中，相关的 pipeline 流程执行调度会更加的繁多复杂。例如我们需要通过定时或 API 的方式来触发数据获取的流程，并在之后进行各种级联任务的触发和调度运行。在任务执行出现问题或失败时，可以自动进行重试和恢复，或提示用户介入处理。

流程编排示意

例如上图中就是一个最简单的任务依赖关系示意，任务 2 的触发依赖于任务 1 的批处理任务成功完成的前提，这时我们就需要编排工具来支持此类工作。

8.2 ETL

编排流程中执行的具体任务，一般都是各种数据接入，数据转换操作，也就是我们俗称的 ETL 了。除了通过 SQL 或者计算引擎的 SDK（如 PySpark）来开发业务逻辑，市面上也有不少产品支持通过 no-code/low-code 方式做开发，大大降低了用户门槛。例如我们观远的 SmartETL 就是这个方面的一个不错的产品，受到了很多业务人员的喜爱。

观远 SmartETL

8.3 需求与产品

对于流程编排相关的工具，主要的系统需求有：

可扩展性，支持海量 pipeline 的调度，监控。
稳定性，必须保证稳定和高可用，一旦流程编排能力瘫痪，相当于整个平台的数据处理核心能力都陷入了停滞状态。
可观测，可运维，各种任务的执行状态，日志，系统资源开销等都需要进行记录并方便查看，方便运维与问题排查。
开放性，能够方便地在工具中开发各种自定义的处理逻辑，运行不同类型的任务。
DataOps 支持，即使提供了 no-code 的拖拽式开发，底层应该仍然能够很好的支持 DataOps 的需求，例如 pipeline 逻辑的版本化管理，测试与发布（CI/CD），支持 API 调用以实现流程自动化等。

可以注意到实际上很多数据获取，数据处理工具多少也带了些 ETL 或编排的能力。云厂商的产品基本都是数据获取工具的那几个，包括 AWS Glue，Google Cloud Composer（托管版的 Airflow），Google Cloud Data Fusion，Azure Data Factory。

开源工具方面，编排工具中，Airflow 应该是最著名的一个，后面随着机器学习领域对 workflow 编排的巨大需求，也涌现出了很多后起之秀，如 Dagster，Prefect，Flyte，Cadence，Argo(KubeFlow Pipeline) 等。另外像国人的 DolphinScheduler[29] 的知名度也相当不错。ETL 的开源工具好用的不多，talend 并不是完全开源的，比较有名的主要是 Apache NiFi[30] 和 OpenRefine[31] 两个历史比较悠久的开源项目了。

SaaS 厂商方面可以参考数据获取部分的厂商，如 Airbyte，Fivetran，Stitch，Rivery 等，上面提到的很多编排工具的开源项目也都有对应的商业公司提供托管服务。还有不得不提到的是如今非常火爆的 dbt[32]，基本上每家公司都在用的数据转换工具，很好的借鉴了很多软件工程领域的最佳实践，可以说是对于 DataOps 需求支持的非常好的一款产品了。

9. 最佳实践

9.1 数据分层

我们在建设企业数仓体系时，一般会遵循一些经典的最佳实践，例如关于数据表模型，有星型模型和雪花模型等设计方式；从数据的流转过程来看，有非常经典的数仓分层模式：

数仓分层

在云数据平台，我们也可以借鉴这方面的思路。例如 Databricks 设计的 lakehouse 中的数据流程就跟上面的数仓分层很相似：

Lakehouse 数据架构

具体流程步骤如下：

一般通过数据获取进入到云数据平台时，都会尽量保持原始数据的状态（可以是原始格式或者 Avro 格式）存放在 landing(bronze) 区域，注意在整体架构中，只有数据获取层工具可以写入这个区域。
原始数据接下来会进行一些通用的质量检查，去重，清洗转换，进入到 staging(silver) 区域。从这里开始更建议使用类似 parquet 的列式存储格式。
同时原始数据会被拷贝到 archive 区域，后续用于重新处理，流程 debug，或者进行新 pipeline 的测试等工作。
数据处理层工具，会从 staging 区域读取数据，进行各类业务逻辑的处理，聚合等，最终形成 production(golden) 数据，提供数据服务。
Staging 区域的数据也可以不做处理，bypass 到 production 区域并最终流入数仓中，这部分相当于是原始数据，可以在某些情况下帮助数据消费者来做比对和定位相关问题。
不同的数据处理逻辑会形成面向不同业务主题，应用场景的“数据产品”，在 production 区域提供 batch 消费服务（尤其是算法场景），或者载入数仓中提供 SQL 查询服务。
在 staging，production 流转过程中，如果数据处理层碰到了任何错误，可以将数据保存到 failed 区域，等排查解决后，再将数据放回 landing 区域，重新触发全流程。

数据流程最佳实践

上述这些区域的划分可以通过典型对象存储的概念，如“桶”或者“文件夹”来进行划分。也可以根据不同的读写 pattern 来决定各个区域对于不同 layer 模块的访问权限控制，以及冷热存储的设计以节约成本。另外流式数据的处理流程也可以借鉴类似的逻辑，但在数据去重，质量检查，数据增强，schema 管理等方面会有更多的挑战。

9.2 区分流式获取与流式分析需求

我们经常听到 BI 分析类的客户有“实时数据分析”的需求。但仔细分析来看，用户并不会时时刻刻一直盯着 BI 分析看板来做“实时分析”，总体来说打开看板是有一定的时间间隔的。我们只需要保证客户每次打开分析看板时看到的数据是最新的即可，因此完全可以使用如下的架构来满足：

流式数据获取架构

这里我们只需要通过流式数据获取系统把订单数据实时写入云数仓即可，当用户每隔一段时间打开报表时，触发数仓的 SQL 查询，展现最新结果即可。

但考虑另一个场景，在某个游戏中，我们希望展示用户的实时行动数据，如自上线以来获得的经验值等统计信息。这个时候，如果我们仍然沿用上述“流式获取”的架构可能就不合适了。因为此时每个玩家都是真正“实时”盯着自己的统计数据的，必须做到高频，大并发的查询支持。一般云数仓的响应时间和并发服务能力就难以满足了，这时才是真正涉及到了“实时分析”的需求。我们需要在流式获取用户的新数据后，执行流式统计分析操作，并将结果存入到一些能够支持高并发，低延迟查询的数据库/缓存系统中，才能支持海量在线玩家的数据消费需求。

流式数据分析架构

9.3 控制云计算开销

云原生时代，我们在使用各类组件时的上手门槛低了很多，开箱即用，弹性伸缩，免运维给开发者带来了非常多的便利，也在悄悄地转变我们的思维意识。在自建系统的年代，我们对于各个组件的资源开销，整个集群的利用率等都有比较精细化的理解和深入优化。但现在各种系统设计的 trade-off 从有限的资源池分配，转向了费用与性能的权衡上来，反而减少了对各个组件做资源开销优化的意识。包括云厂商们自己有时候也会有意无意的“摆烂”，最近还有一篇 The Non-Expert Tax[33] 专门来讨论云厂商的 auto-scaling 的经济性问题。

因此作为云数据平台的开发者，仍然要深入理解各类云计算组件，产品的架构原理，收费模式，并实践相应的资源监控，优化手段。典型的例子包括网络开销的控制（减少跨云传输），冷热存储的设计，数据分区等提升数据计算处理效率的优化手段等等。

9.4 避免紧耦合

从前面复杂的架构图中可以看到，云数据平台一般会由非常多的组件构成，而且整个技术生态的变化也是日新月异。一般对于这类复杂系统，我们会采取分步构建的方式，过程中会持续增加，替换或淘汰部分组件产品，因此必须要借鉴软件工程中的松耦合原则，避免对某个具体的产品/接口有紧密的依赖。虽然有时候直接访问底层存储之类的做法看起来减少了中间步骤效率较高，但也会让我们后续想要做扩展和变更时碰到很大的麻烦。理想情况下我们应该尽可能明确组件之间的边界和接口，对不同的产品进行封装以提供相对标准的接口实现交互和服务。

10. 数据平台建设

10.1 业务价值

最后值得一提的是，复杂的云数据平台建设不能仅仅是从技术角度出发去推动的。必须从业务（商业）的目标出发来发起和规划整个项目。数据平台的典型价值包括：

节流，提升业务运营效率，节约资产投入和各类运维成本。
开源，支撑营销优化，客户体验优化等场景，促进公司收入增长。
创新，通过优秀的产品能力，支撑业务的自助式数据分析与决策，快速探索新增长点。
合规，通过统一平台建设来满足各类数据方面的法规，政策，监管需求。

我们应该明确企业的业务诉求，针对性的设计数据战略和数据平台建设的规划。对于技术战略如何服务业务目标，也可以参考这篇资深工程师之路：技术战略[34]，这里就不详细展开了。

10.2 建设路径

从前面的架构图看到，整个平台的组成是相当复杂的，一般需要经过几年的时间来逐渐搭建与完善。这与企业本身的在线化，数字化，智能化演进路线需要保持一致，而不是无视企业数据现状，上来就开发部署流式数据平台，机器学习平台等看起来更新潮的技术。

我们观远在成立早期就深入思考并提出了数据分析与智能决策在企业落地的 5A 落地路径方法论[35]，包括从自助式分析，到场景化，自动化，增强化最终实现决策自动化的 5 个步骤。对应到数据平台的构建，也可以参考类似的策略框架，例如：

敏捷化，可以通过基础数仓体系搭建和自助式 BI 分析产品的应用来实现，达到“看见数据”的目标。
场景化，通过 metric layer 和 BI 产品中的应用市场，形成各个业务场景的最佳实践，让更多的用户知道“怎么看数据”。
自动化，需要平台有一定的编排能力，将各类分析结果与业务系统打通，自动化推送结果（反向 ETL），数据预警等，达到“数据追人”的效果。
增强化，在分析的基础上，进一步加入 AI 建模与预测的能力，需要平台支持算法类的数据处理与消费（如非结构化数据，notebook），实现“洞见未来”。
行动化，最终我们希望能在预测基础上更进一步，从分析型 AI 延展到行动化的 AI，需要平台提供更加综合的对外服务能力（API，实时数据，AB Test 等），结合一些低代码工具打造数据驱动的业务应用，有望实现“自动决策”。

数据分析成熟度历程

10.3 用户推广

除了从技术架构层面的演进方法论，如何在业务层面对平台进行宣传与推广也是一个重要课题。有太多的数据平台项目都是缺乏深入的业务沟通理解，在双方缺乏一致认知的情况下，推进复杂项目，建设周期极为漫长，最终导致中途的失败。我们更应该通过一些小型项目快速体现平台价值，增进双方的共识，获取用户的信任，并逐渐推广到更多组织部门；在得到更多应用之后，也会带动场景，需求的丰富，反过来也可以指导和促进平台本身的建设与发展，进入一个良性循环。这也是我们观远在持续探索和实践的“让业务用起来”的路线方法。

最后小小的打一个广告，我们观远数据在前面提到的产品技术层面和企业服务，业务推广方面都有非常丰富的经验。通过 Universe，Galaxy，Atlas 产品线，可以支撑处于各个数据分析成熟度阶段的企业数据平台，BI + AI 分析决策需求。在一些行业头部客户，我们的产品也成功达到了 20000 名以上活跃分析师和数据决策用户的里程碑，可以想象这样的企业在激烈的市场竞争中能够体现出来的决策效率与质量的巨大优势。非常欢迎有兴趣的朋友来一道探讨交流，寻求合作共建的机会 :)

参考资料

[1] 云原生机器学习平台的组成和搭建: https://zhuanlan.zhihu.com/p/383528646

[2] a16z 的一些分析报告: https://future.com/data50/

[3] modern data stack: https://www.moderndatastack.xyz/

[4] 算法平台中的数据湖系统: https://zhuanlan.zhihu.com/p/400012723

[5] tiered storage: https://www.confluent.io/blog/infinite-kafka-storage-in-confluent-platform/

[6] lakeFS: https://github.com/treeverse/lakeFS

[7] JuiceFS: https://github.com/juicedata/juicefs

[8] SeaseedFS: https://github.com/chrislusf/seaweedfs

[9] Confluent: https://www.confluent.io/

[10] Upsolver: https://www.upsolver.com/

[11] Materialize: https://materialize.com/