使用 TapData，化繁为简，摆脱手动搭建、维护数据管道的诸多烦扰，轻量替代 OGG, Kettle 等同步工具，以及基于 Kafka 的 ETL 解决方案，「CDC + 流处理 + 数据集成」组合拳，加速仓内数据流转，帮助企业将真正具有业务价值的数据作用到实处，将“实时数仓”方法论落进现实。
TapData 持续迭代产品能力，优化用户体验的同时，也在不断探索各行各业数据需求的底层逻辑，力求为行业用户提供更加简洁、更具针对性的解题思路。本期内容便是我们在公共卫生领域做出的实践以及展望。
案例速览：
- 客户：某政务体系下的公共卫生机构
- 需求：SAP Sybase → PostgreSQL 的数据迁移
- 挑战：Sybase CDC（变更数据捕获）能力，数据源与目标间的持续、无缝同步
在数据库技术的发展史上，Sybase 无疑是一个重要的名字。作为最早的商业关系型数据库管理系统之一，Sybase 自 20 世纪 80 年代问世以来，在金融、通信等多个领域都得到了广泛应用。其高性能、高可靠性和强大的事务处理能力，使其在过去的几十年中成为众多关键业务系统的核心支柱。
然而，在 2010 年被 SAP 收购后，其发展轨迹发生了变化。收购后，SAP 逐渐将其重点转向自身的旗舰产品 SAP HANA，这直接导致了 Sybase 数据库的迭代节奏放缓。根据官方生命周期文档等现有信息显示，SAP 计划在 2025 年结束对 Sybase ASE（Adaptive Server Enterprise）16.0 版本的主流维护支持。
对于许多仍然依赖 Sybase 的组织而言，这一计划背后无疑是巨大的挑战。尽管 Sybase 依然是一款现代化程度很高的数据库，具备大多数业务数据库所需的特性和能力，但维护终止的风险意味着这些组织必须为未来做好准备，以避免潜在的安全漏洞和技术支持中断。
某公共卫生机构（以下简称“该机构”）也是众多受影响的组织之一。多年来，该机构的关键业务数据一直存储在 Sybase 数据库中，且系统运行稳定。但随着停止维护计划的临近，该机构开始着手为未来做出战略调整。为了确保业务的持续性和系统的安全性，决定将现有的 Sybase 数据库迁移到 PostgreSQL 这一同样现代化且社区支持强大的数据库平台上。
一、Sybase ASE 数据迁移的必要性和挑战性
尽管如今的 Sybase 仍然具备强大的业务支持能力，但其未来的不确定性使得迁移成为某种必然。一旦失去官方的技术支持，随之而来的安全风险、性能问题以及无法应对的技术故障将逐步显现。对于牵连甚广的政务体系而言，这种风险尤其不容忽视。特别是对于公共卫生机构这样一个依赖于稳定和安全的数据库系统来处理大量敏感数据的组织而言，无法获得及时的安全更新和技术支持，意味着系统将暴露在日益增多的潜在威胁之下。
因此，这一迁移决定并非轻率之举，而是基于对长期发展与风险管理的深思熟虑。对于该机构而言，选择 PostgreSQL 一方面是为了获得长期的技术支持，另一方面也是希望利用一个能够随着业务发展而扩展的灵活平台。但迁移任务也并非易事，该机构需要面对的不仅仅是数据迁移的技术复杂性，还包括在迁移过程中如何保持数据的一致性和系统的连续性。
必要：面对潜在风险的预管理
首先，安全性问题迫在眉睫。随着 Sybase 停止维护，数据库不再接收安全更新，这意味着系统将面临越来越多的安全漏洞。一旦这些漏洞被利用，整个机构的核心业务数据可能会遭受严重的威胁。对于处理敏感公共卫生数据的机构而言，数据泄露或损坏的后果将是不可承受的。
其次，可用性和性能问题日益凸显。随着时间的推移，旧有的Sybase系统在面对现代化应用的需求时，表现出明显的性能瓶颈。数据库响应速度变慢、查询效率下降，严重影响了业务的正常运作。同时，由于缺乏有效的技术支持，系统故障的修复时间也显著增加，给机构的日常运营带来了巨大的不确定性。
此外，随着时间的推移，数据库管理和维护的难度也会增加。缺乏更新的数据库系统可能无法适应新的业务需求和技术环境，导致整体系统的灵活性下降。这种情况将给机构的 IT 团队带来巨大的压力，并可能影响其业务的持续性和扩展性。
挑战：数据迁移的复杂性
数据库迁移本身是一项复杂且充满挑战的任务。该机构在多个 Sybase 数据库中存储了大量关键的业务数据和历史记录。迁移的过程中，必须确保数据的完整性和一致性，任何数据的丢失或错误都会对机构的业务运营产生不可估量的影响。
特别是在涉及实时数据处理的场景中，该机构的业务系统需要在整个迁移过程中保持不间断的运行，这就要求迁移方案不仅要考虑如何将历史数据顺利迁移到新的 PostgreSQL 平台上，还要确保在迁移过程中，迁移期间，Sybase数据库和PostgreSQL数据库必须能够同时运行，所有的数据变化能够实时捕捉和同步，以避免数据不一致的问题。迁移过程中需要灵活应对各种潜在的技术挑战。
在这些挑战中，则以 Sybase CDC 能力为主要难点，原因在于：
- 业务连续性要求：停机时间最小化。许多企业和机构，特别是像公共卫生机构这样的组织，通常需要 24/7 不间断地处理数据和运行核心业务系统。一次性迁移可能需要长时间的系统停机，这在业务连续性要求高的环境中是不可接受的。CDC 在迁移过程中实时捕捉并同步数据变化，确保系统的无缝过渡，几乎不影响业务的正常运行。
- 数据一致性与完整性：确保数据同步。在迁移过程中，如果数据在源库中继续发生变化（例如新增记录、修改数据、删除数据），一次性迁移可能无法捕捉到这些变化，从而导致目标数据库的数据不完整或不一致。CDC 可以在迁移过程中持续捕捉这些变化，确保所有数据在最终切换时保持同步和一致。
- 降低迁移风险：渐进式迁移。CDC 允许迁移过程分阶段进行，降低一次性迁移失败的风险。如果一次性迁移出现问题，可能会导致业务中断，数据丢失或不一致。而通过 CDC，迁移可以逐步实施，测试每个阶段的结果，确保所有问题都在切换前被发现和解决。
- 数据量与复杂性：处理大规模数。对于涉及大量历史数据和复杂数据结构的系统，一次性迁移可能需要很长时间，这不仅会导致业务中断，还可能因为时间太长而导致数据陈旧。CDC 允许在初期阶段迁移静态数据，并在最终切换前捕捉和同步所有动态变化的数据。
- 测试和验证的灵活性：平行运行和验证。通过 CDC，源数据库和目标数据库可以在一段时间内平行运行，IT 团队可以实时验证数据在目标系统中的一致性和准确性。在确保新系统完全稳定并且所有数据都已正确迁移后，再进行最终的系统切换。这种方式提供了更多的测试和验证机会，降低了数据迁移的风险。
- 逐步切换用户和系统：避免一次性大规模切换。在一次性迁移中，所有用户和系统都需要在一个时间点切换到新系统，这可能会带来巨大的压力和潜在的问题。通过 CDC，机构可以逐步切换用户和系统到新数据库，减少负载和可能出现的错误。
由于该机构的业务是连续运行的，即使在迁移过程中，数据也在不断变化。因此，实时捕获并同步数据变化成为了迁移过程中的关键环节。如果不能有效实现CDC，数据的不一致和延迟将直接影响到迁移的成功与否，并可能对业务运作造成无法挽回的损害。
鉴于上述种种迁移的紧迫性和复杂性。在保障数据安全、提升系统性能的同时，如何在不影响业务连续性的前提下，顺利完成这场大规模的数据库迁移，成为了机构决策层最为关注的问题。面对这一系列难题，选择一个强大的迁移工具和合作伙伴至关重要。正是在这种背景下，TapData 凭借其出色的 CDC 技术优势和丰富的行业经验，成为了该机构重点评估的合作对象。
二、解决方案：TapData CDC 助力迁移
在与该机构沟通的过程中，TapData 充分意识到 Sybase CDC 能力支持这一迫切需求在行业内的实际价值，研发团队遂投入大量精力推进该连接器的开发工作，并在稳定性上进行了反复的测试和优化，最终为客户呈现了一个易用且可靠的版本（支持的 Sybase 版本：ASE 16.0）。
技术实现难点：Sybase 的日志机制
Sybase 将数据库的存储内容分为了数据区与日志区两部分，在创建数据库时， 可以将两个部分分别分配到不同的设备中，如下命令：
# 创建一个设备, 名字为 s1_data, 存储在 /opt/sybase/data/s1_data.dat 文件中, 大小为 1G
DISK INIT name='s1_data', physname='/opt/sybase/data/s1_data.dat', size='1G';
# 创建一个设备, 名字为 s1_log, 存储在 /opt/sybase/data/s1_log.dat 文件中, 大小为 1G
DISK INIT name='s1_log', physname='/opt/sybase/data/s1_log.dat', size='1G';
# 创建一个数据库, 数据部分在 s1_data 上, 日志部分在 s1_log 上
Create Database s1 on s1_data='1G' log on s1_log='1G';执行 sp_helpdb $db 命令，可以看到设置的结果：
在使用数据库进行增删改时，数据部分会以 db/schema/table/record 为组织层级进行记录。
日志部分会以 page/row 为组织层级进行记录。
数据部分可以使用 jTds 驱动进行读取， 与其他数据库并没有明显的差别。
关于日志部分，Sybase 并没有像 MySQL 或者 Oracle 一样，提供比较完善的读取和解析接口, 也没有任何可用的文档可供参考，这为实时事务的变更获取带来了极大的难度。
如何实现实时变更获取
在对 Sybase ASE 进行实时数据变更获取之前，需要了解一系列这个数据库的的运行机制，这包括：
- 日志清理机制： 数据库的日志保留机制一般包括固定大小与固定时长两种，这两个方式容易理解，但是在遇到短时间批量事务，或者极长未提交事务等场景，都会出现日志丢失导致的错误恢复困难，与 PG 类似， Sybase 采用了第三种方案：标记防止清理，一个事务开始时，将会在数据库中放置一个标记位，这个标记位旨在告诉数据库，请不要清理标记位之前的日志信息，标记位往往随着事务的提交或者回滚消失，在进行日志读取时，合理设置与更新标记非常重要，如果错误设置标记位，除了会导致来不及读取的日志被清理之外，还会导致 Sybase 自身的内部异常，长期积累以后，Sybase 有可能终止服务。
- 日志满异常：在正常情况下，Sybase 会维护自身的日志使用情况，在日志空间被用光时，对数据库的任何写操作都会被阻塞，直到日志空间被释放为止，在异常情况下，Sybase 对自身日志的使用情况会出现计数错误，这会让数据库对自身的保护失效，新的写入会使数据库崩溃。
- 日志读取限制：Sybase 日志以 DB 为基本存储单位，一个 DB 内所有的 schema，以及所有的 table 都记录在同一块区域内，对同一个 DB 的日志获取进程只能同时存在一个。
基于此，就可以逐步开始进行事务日志的读取与解析，并解决以下问题：
- 对读取到的事件进行尝试解析，识别出关键的 DDL / DML 数据，并抓取所需数据, 完成 DEMO。
- 了解数据库的日志换页机制，保证可以逐步推进日志读取进度，开始调试。
- 了解在线/归档日志的概念，避免读取在线日志时的数据丢失, 得到基本工作的 V1 版本。
- 了解长时间未提交事务，部分提交事务，日志序号回退，日志序号重用等问题，得到数据准确的 V2 版本。
- 了解 Sybase 623 错误，sp_configure 命令，config_admin 命令，了解 aux 描述符，事务描述符等概念，了解 tablealloc，dbrepair 等指令，得到可长时间工作，数据准确，且尽可能最小影响 Sybase 数据库的 V3 版本。
- 处理不可避免的事件重复，了解日志块重新分配概念，得到 V4 版本。
- 了解字符编码，了解 Text/Binary 等 Lob 数据，了解 Sybase 存储 Lob 原理，了解 TimeStamp 类型是什么，得到可以处理 Lob/Timestamp 以及多字符编码的 CDC 的 V5 版本。
- 改造 TPCC 工具，适配 Sybase SQL，进行数周的长时间测试，处理连接复用，自动清理日志等问题，得到更加稳定的 V6 版本。
到此为止，一个可以线上使用的 Sybase CDC 实时事务变更获取功能就基本完成了，效果如下：
TapData 的 Sybase CDC 连接器允许实时捕捉 Sybase 能够高效捕捉并同步 Sybase 数据库中的数据变更，并将这些变更实时传输到包含 PostgreSQL 在内的各类目标数据库。这一功能确保了在整个迁移过程中，数据的一致性得到了可靠保障，同时避免了数据延迟或丢失带来的业务中断风险。
不仅如此，可视化的操作界面，以及极简的拖拉拽操作模式，也是 TapData 的一大优势。不同于传统的大规模数据库迁移通常涉及的复杂步骤，有效减少了人工干预的需求，降低了人为错误的风险。这使得整个迁移过程更加流畅，节省了大量的时间和资源。
三、成果与反馈
在 TapData 的支持下，该机构顺利推进了 Sybase 数据库到 PostgreSQL 数据库的持续迁移同步，帮助机构在复杂的技术环境中实现了业务的平稳过渡与持续发展。该迁移方案的实施，一方面预防了 Sybase 停止维护可能带来的风险，顺利实现了数据库的现代化转型。另一方面，顺利突破了以 Sybase 为数据源的实时数据同步场景的技术挑战，为未来的业务发展提供数据层面的便利。
在本次合作中，TapData 在高效性、可靠性、易用性，以及技术支持与协作等方面，得到了该机构的充分认可。在整个项目期间，TapData 团队始终与该机构的 IT 团队紧密合作，提供了全程的技术支持和指导。无论是前期的 CDC 难点攻克，还是后续的持续优化与维需求，TapData 团队都做出了积极支持与响应，并最终提供有效的解决方案。
从挑战到成功的关键因素
在回顾整个项目时，该机构总结了从挑战到成功的几个关键因素：
- 明确的迁移策略：在正式着手前，机构制定了详细的迁移计划，确保了每个步骤都经过充分的测试与验证。这种严谨的策略规划，是项目成功的关键所在。
- 实时数据同步的保障：TapData 的 Sybase CDC 能力，在项目中发挥了至关重要的作用。通过实时捕捉并同步数据变化，机构确保了迁移过程中数据的一致性和业务的连续性。
- 技术支持与团队协作：与相关供应商的紧密合作，是项目顺利实施的另一个关键因素。从前期的方案制定，到实际的技术实施，内外部的共同支持贯穿了整个项目周期，确保了迁移的成功。
未来展望
随着业务的不断扩展与新增，越来越多的企业和机构将面临类似的数据库迁移和升级需求。TapData 在此过程中所展现出的灵活性、可靠性和高效性，使其成为应对这些挑战的理想合作伙伴。无论是处理实时数据同步、跨平台数据集成，还是确保数据的安全和一致性，TapData 都能够提供强有力的支持，帮助客户实现其数字化转型目标。
四、总结：Sybase 数据库替换方案
Sybase 数据库已经进入“生命倒计时”，作为业务核心选型之一的数据库系统，不应该再考虑使用这个数据库，已经使用这个数据库的场景，应该考虑尽快开始 Sybase 的淘汰与替换计划。
由于业务使用的复杂性，数据库的替换往往是一个极为长期，循序渐进的过程，一般会分为几个步骤：
- 新业务使用新的数据库。
- 旧的业务逐渐替换。
- 所有业务完成替换后，旧数据库下线。
在步骤 2 的过程中，在新旧数据库之间，一般情况下会存在一个较长时间的数据同步架构，如下图所示：
由于 Sybase 是闭源数据库，且没有足够的文档来说明实时数据同步的工作原理，能够稳定运行 Sybase 到其他数据库实时同步的数据集成产品，相比 Mysql 或者 Oracle / PG 等数据库来讲就相对少很多。
如果您有 Sybase 数据库替换的场景需要使用数据实时集成工具，TapData 会是个合适的选择。如果想要试用，欢迎点击文末「阅读原文」通过获取企业版来获取体验。
【推荐阅读】
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。