从“看报表”到“数据分析结果直接投入运营”，数字化正在深入企业经营，数据系统正在成为核心生产系统。相应的，企业对“作业挂了”、“系统崩了”、“算不出来”的容忍度越来越低——只有足够稳定、可靠、专业的数据系统，才能及时满足业务的数据需求。

数据写花了，是数据平台不行，还是代码出了bug？

任务失败了，是资源不够，还是调度有问题？

在不久前的2023 StartDT Day数智科技大会上，StartDT（奇点云）合伙人、CTO地雷聚焦企业数据基础设施的稳定性，探讨了典型问题，并分享了DataSimba的相关实践。

数据云平台DataSimba是奇点云的核心产品，具备跨平台、云原生、自主可控、数据安全的特性，从数据集成、数据研发、数据运维、数据治理到数据服务，围绕数据全生命周期提供能力。

但今天不聊版本迭代和功能更新，只讲一件事——企业级的稳定。

构建企业级稳定的数据基础设施，需要两方面的努力：数据开发团队建立软件工程的最佳实践，和一个专业可靠的数据云平台。

这就像驾驶员需要有培训、驾照，开车不能喝酒，车也要足够稳定、可靠、安全，有保障机制。这两者缺一不可。

本次发布，我们从企业级软件的“金标准”——“RAS”中分别挑选了几个典型问题，和大家分享。

*RAS，即Reliability（可靠性）、Availability（可用性）、Serviceability（可服务性），可分别简单理解为要确保数据不丢失不错误，要确保系统的停机时间在SLA内，要确保系统有变时可运维可修复。

#1 可靠性典型问题：数据备份和迁移

「非必要，不用“两地三中心”」

常有客户问，要不要做“两地三中心”？大多数情况下，不用做。

其一，分布式存储的三副本技术，已经提供了单机房内99.9999%以上的可靠性；

其二，数据平台类基建的集群规模大，数据量惊人。仅仅是跨机房1:1热备，就要高昂成本。

客户需要权衡风险（例如战争、天灾摧毁机房）和投入，综合评估备份策略。对于大多数客户而言，定期把关键数据导出冷备即可。

*两地三中心，即生产中心、同城容灾中心（数据同步复制）、异地容灾中心（数据异步复制）。能在基本不丢数据的情况下完成灾备应急切换，保持数据业务的连续性。

*冷备，在系统停机状态下进行，大规模数据及复杂系统更易于实现冷备，缺点是停机时间相对长，但也因此资源可控、成本更优；热备，在系统运行状态下同时进行，缺点是资源要求高（可能对系统性能产生影响），适合业务对恢复时间有极严格要求且资源充足的场景。

「大数据生产，必须有专业的作业调度和基线告警」

现代大数据引擎为了大幅提升吞吐，取消了事务锁。

这意味着数据开发团队必须有专业要求，避免两个作业同时往同一张表里写数据、造成数据损坏等情况。具体实践包括但不限于：

配置Task（任务）调度，以确保不会出现Job（作业）写入冲突；

配置基线告警，一旦Job执行过慢——意味着可能导致下一轮Job调度冲突，就应当自动告警，提醒数据运维及时干预。

*事务锁：一种用于管理并发访问数据的机制，在OLTP（联机事务处理）系统中较为常见，防止多个事务对同一数据进行不一致的访问和修改。与OLTP需要处理大量交易性操作、注重事务处理速度不同，OLAP（联机分析处理）系统主要用于复杂的分析查询，更注重查询性能，允许一定程度的数据冗余，因此几乎不依赖传统的事务锁机制。

「大数据是有“重量”的」

大数据跨域迁移，有极高的复杂度——数据量大，作业量大，复制PB级的数据和数千个Job并不像个人电脑拷贝几个文件那样简单。

一般来说，脚本执行耗时数天，迁移后新旧系统并跑，验证数据准确性还需要1个月。因为在此期间，有很高概率会发现磁盘损坏等等问题，需要重补数据。

“‘搬家’有风险，迁移需谨慎。”

如果一定要跨域迁移，建议雇佣专业的团队，为数据迁移做保障。

针对上述3个问题，DataSimba除了持续提升产品自身的可靠性，完善各项功能以便开发团队固化最佳实践，还分别提供：

1. DataSimba迁移发布助手，帮助客户完成数据定时导出、冷备；
2. 数据开发陪跑包，和客户的数据开发团队一起开发demo并配置，协助客户逐步建立起大数据生产的研发底线；
3. 迁移运维服务包，降低大数据跨域迁移风险，保障数据一致性、安全性及整体迁移效率。该项服务按数据量计费。

#2 可用性典型问题：防止线上生产故障

「数据生产应建立CI/CD体系」

“数据开发在生产系统上热改SQL，写出笛卡尔积，导致生产崩溃，结果第二天老板看不到经营报表。”

这不是编故事，而是发生在企业客户的真实案例。奇点云的数据运维On-call（值班）团队平均每周都会接到类似的“救火求援”。

大数据生产已不同以往，不再是“实验局”、“创新局”，而真正对日常业务运营产生影响。企业数据团队应当建立起CI/CD体系，来维护生产环境。

具体包括但不限于：设置测试环境，建立自动化测试、自动化发布流程。所有代码修改必须在测试环境通过验证后，由专人操作上线到生产环境。大部分程序员没有在生产环境修改或发布的权限。

「数据平台需要保证鲁棒性和可用性」

除了对“驾驶员”的数据工程规范要求，平台本身更应当保证鲁棒性和高可用性：

鲁棒性（Robust），即系统健壮性，可简单理解为承受故障和干扰的能力。即便在出现输入错误、故障、过载甚至攻击的情况下，平台也不会被“击垮”，能隔离故障，及时告警。

高可用，用大白话说，就是每个组件有多进程的back-up（备份），能自动重启failover（故障转移），其本质是用冗余硬件资源做热备，所以也存在一定的成本投入。

DataSimba从上述六个维度加固稳定性（详见《数据云场景指南》）

针对上述问题与场景，DataSimba提供：

1. DataSimba迁移发布助手，支持与各种版本管理和持续集成的工具联用；
2. 数据开发陪跑包，协助客户建立起自己的CI/CD流程；
3. VIP专属运维服务包，即原厂运维专家按规定在一定时间内为客户处理故障应急响应、备份管理、漏洞修复等问题；
4. DataSimba专业版及以上版本提供高可用部署方案，所有组件均可实现高可用，并已完成全面压力测试，可用性达到99.95%。

#3 可服务性典型问题：建立平台的可观测性

建立平台可观测性体系，是很多数据团队的理想——从Logs、Metrics、Traces和Meta抓取系统状态，建立模型和指标，用数据驱动运维。“吃自己的狗粮”，有趣且很有价值。

其实这项能力（功能）在数据库领域叫做Information Schema（直译为信息视图），一种标准的、系统元数据的查询接口，能帮助开发者快速了解系统结构，让系统更易于维护。而目前市面上许多数据平台产品还无法提供类似能力。

DataSimba的Schema不仅提供系统元数据，还提供了多种数据模型（提炼自行业经典方法论及历年实践），帮助企业更便捷地建立可观测性体系，为智能运维、平台管理、数据治理等场景提质提效。

目前，包含以下10种模型：

例如，依托“运维巡检模型”，可监控底层硬件、操作系统、中间件、大数据组件及SimbaOS各个对象的时序状态，记录历史状态信息，定期生成运维巡检报告，并根据历史数据进行异常预测；

“作业健康诊断模型”则支持对Hive、Spark、Flink等不同类型的作业进行针对性建模，诊断数据作业失败、长尾、数据倾斜、资源浪费等数据生产问题和编程失误，给出潜在建议和改进建议。

*DataSimba的Schema能力来自数据云操作系统StartDT SimbaOS。基于SimbaOS生长的全域数据安全管理平台DataBlack等产品同样调用了Schema，进行了对应设计和研发。

“好赛车”和“好车手”

如开篇所述，就像“好赛车”和“好车手”，构建企业级稳定的数据基础设施，离不开专业可靠的数据云平台，也需要数据开发团队建立并掌握数据工程的最佳实践。

为此，奇点云不仅提供安全、可靠的各档次“汽车”，即数据云平台DataSimba，还提供各类培训、陪跑等服务包，和客户的数据团队一同，保障数据生产的稳定，构筑数据赋能业务的坚实基础。

期待成为您的理想选择！

---

附Q&A

1、DataSimba和数据云操作系统 StartDT SimbaOS是什么关系？

DataSimba是SimbaOS生态的1号应用，SimbaOS Kernel的许多关键能力都脱胎自DataSimba，而DataSimba也几乎调用了Kernel的所有功能。

2、SimbaOS发布，对DataSimba的客户有什么影响？

目前，DataSimba R4及以上版本均进行了架构升级，切换为基于SimbaOS Kernel（数据云操作系统内核）迭代，享受SimbaOS的所有能力。相对老版本而言，新版本功能更丰富，体验更优。如果客户同时还在使用DataBlack、SimbaMetric等产品，可通过同一套SimbaOS统一管理数据资产，甚至完成多应用之间的数据交互。