最佳实践

9.1 数据分层

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

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

具体流程步骤如下：

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

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

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

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

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

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

9.3 控制云计算开销

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

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

9.4 避免紧耦合

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

（文章来源于网络，如侵删）

相关链接：

聊聊云原生大数据平台（一）——数据平台架构 https://www.dtstack.com/bbs/article/428

聊聊云原生大数据平台（二）——数据获取  https://www.dtstack.com/bbs/article/469

聊聊云原生大数据平台（三）——数据存储 https://www.dtstack.com/bbs/article/470

聊聊云原生大数据平台（四）——数据处理 https://www.dtstack.com/bbs/article/471

聊聊云原生大数据平台（五）——元数据 https://www.dtstack.com/bbs/article/472

聊聊云原生大数据平台（六）——数据消费 https://www.dtstack.com/bbs/article/473

聊聊云原生大数据平台（七）——流程编排与 ETL https://www.dtstack.com/bbs/article/474

聊聊云原生大数据平台（八）——数仓最佳实践 https://www.dtstack.com/bbs/article/475

聊聊云原生大数据平台（九）——大数据平台建设 https://www.dtstack.com/bbs/article/476

袋鼠云在大数据领域深耕7年，拥有丰富的大数据平台建设经验和成熟的产品体系，想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=bbs

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」，交流最新开源技术信息，群号码：30537511，项目地址：https://github.com/DTStack