我们行在澳门是主流行，携跨境优势，产品丰富，在澳门银行业有一定代表性。当然我们不是澳门首家使用GBase的，大丰银行走在前面，我们还专门去交流过。借GBase征文的机会，分享下我们行引入GBase的做法，为国产优质数据库产品打call。
我们行长期大量使用IBM产品，包括系统软硬件、数据库、中间件等，IBM有一套成熟的解决方案，比如LPAR、SAN存储、HA、GPFS、TSM备份，用户也比较依赖这套成熟的基础架构，除非有必要，一般不会换其它技术，而数据库就是DB2系列，包括DB2 for z/OS, DB2 for AS/400, DB2 for LUW等，我是十年前入行，这些平台都用过，使用经验也是基本从0开始积累，除了项目实践，也看牛新庄的三本书来提升功力。到2018年，我们的核心系统上收总行，就只剩下一些本地化系统在使用DB2 LUW了，都是单机版，提升性能一般通过Scale Up解决，就是提需求让系统组加资源，这对虚拟机来讲也是很方便的，近几年澳门发展电子支付，多家机构的APP都推出了扫码支付产品，我行推出的聚合支付也是明星产品，因小额支付带来的高并发，单机资源加到顶也顶不住，为此我行引入了Oracle一体机，相信可以撑较长一段时间了，就是贼贵。
数据仓库这块，我们也一直使用DB2 for AIX，有近20年历史了，现在运行在Power 8 LPAR上，有12 Core、256G内存，单机可扩展性能已经到顶，而且受License所限，我们的版本最多用16 Core、128G内存，面对性能压力，我们也尝试做一些调整：
1.调研DB2放开内存限制或BLU属性，这需要高阶版本才能支持，IBM报价过百万美刀，放弃了
2.因磁盘IO繁忙，我们全部换成了固定盘，性能有一定提升，预计搭配P9性能会提升更多
3.还有一些常规手段，表大到一定程度就物理拆分
总的来说，经过不断优化调整，DB2数仓在数据加载、加工运算方面仍可维持，但满足数据分析师的即席查询就比较吃力了，单一大表都查不动，更别说复杂点的关联了。数据挖掘就是要挖，我们不可能为每条SQL都建索引，也不能要求大家都提交优化得很好的SQL,另外，我们没有做读写库分离，ETL批量加工时要限制用户访问，不然容易锁表，所以用户体验较差，我们运维也很累，种种迹象表明，DB2底座难以支撑大数据创新发展了，所以，我们打算建设新的数仓。
经过调研选型，我们选择了国产的GBase 8a MPP Cluster新型数仓，用的是V8版本。原因也很简单，我们总行买了产品使用权。我们生产集群有6个节点，都是x86物理机，配置为2路16核CPU、128G内存、万兆网卡。从2020年项目投产至今，已有两年的时间，集群运行稳定，加载、查询和运算性能强劲，使用场景也不断拓展，积累数据量达到20T，一些主题表或历史表每天新增几百万记录，现在已超20亿，这样的量级在DB2上基本跑不动，不过我们也打算分表了，一般来说，当前表放去年+今年的记录已足够分析了，再早的就可以移到历史表了。我们有一群数据分析师，他们在GBase上提交的SQL也挺复杂的，比如有一次用户反馈系统报错：“SQL Error
[1116][HY000]Too many tables; Gbase can only use 61 tables in a join”，问我们能不能放宽表数据限制，当时把我们也惊到了。我们平常用可视化工具GBase Monitor来监控集群健康状况，也看看用户提交的查询，常看到有成百上千行的复杂SQL，一般能在百秒这个时间量级跑出来，作为一种低频的应用场景这是可以接受的，所以，当你把访问权限开给用户，他们就能玩出花来，只要不过度消耗资源或影响他人使用，我们就尽量不限制用户，我们也用了GBase资源管理来对即席查询与系统访问做一些隔离，前端工具现在是五花八门，像Tableau, Python,
SmartBI, dbeaver等等，但数据库是底座、是核心，应该足够稳定、强大、兼容，看起来GBase已表现出了这种潜质，我们对它也越来越有信心。近来我们与总行同事交流，对方说常会发生SQL中含有笛卡尔集，把磁盘撑爆了，然后就要杀掉。这种问题在我们行只发生过一次，而且是刚投产不久，占用了近100T磁盘，当时把我们吓得不行，以为集群出了故障，后来发现是用户提交了一条join条件为1=1的查询，杀掉之后磁盘占用率就降下去了，我们告诉用户以后要注意，到目前都没再发生过。投产初期我们在GBase Monitor看到有CPU使用率高的alarm就紧张，还想着调低加载并发度或者ETL作业并发度，现在基本忽略。从历史监控信息来看，集群主要是出CPU和IO报警，内存使用率很少报，我们就是在这种忐忑中，不断积累GBase运维和使用经验，对产品越了解就越放心，使用上就更加放得开，去年5月份，我们有几位同事参加了GBase举办的培训，获得了Gbase 8a数据库管理工程师认证。但必须得说，最好还是找个实际项目切入，不断拓展使用场景，同步提升运维水平，当然这少不了南大通用的技术支援，我们是保持紧密沟通的，目前也升了两个版本。
我们不少同事都问GBase会不会替换DB2？我们认为在可预见的几年内都不会。我们在DB2使用上积累了很多经验，也有很多数据资产，运行稳定，取代它是不太明智的。像引入Oracle也是一样，从具体使用场景着手，通过新技术解决用户痛点，这样更容易落地。在GBase设计时，我们定的策略就是两者并行，互为异构备份，合理分配负载。贴源层表，DB2和GBase同时加载，DB2数仓的加工表，加工完之后再下传给GBase，新的项目就尽量选择GBase，数据分析师挖得深，对性能要求高，咱们就对他们开放GBase，这样既保留了数据资产，也减小了对大部分对性能没那么敏感的用户的影响，有一个问题是，我们要努力确保两个平台的数据一致，主要是指DB2向GBase下传的加工表，但DB2可能会重跑或补跑之前的数据，那在设计时最好考虑支持增变量下传，比如每个表都有软删除标识，modified date这样的字段，不然就只能全量下传，全链路的压力都很大。
我们与数据仓库有数据交互的上下游业务系统也多是DB2，DB2之间交互数据首选IXF格式，export和load都非常简单，对数据质量的要求也不高，像换行符、列分隔符、lob类型，都不是问题，但我们在建设GBase时，为了避免让这些业务系统再另外导出一份CSV格式数据，我们是在ETL作业中加了格式转换，先把IXF文件load到一个DB2转换专用库，再导出CSV格式，如果某些栏位可能含有换行符，我们通过参数配置的方式，在导出时做替换，通过这种方式，上游的业务系统就完全不用配合改造，一套档案同时入库DB2和GBase。如果上游系统使用其它数据库，比如Oracle，SQL Server等，本身就只能采用CSV这种兼容性很高的格式来做数据传输，那改造起来会比较简单，入库效率也更高，IXF私有格式隐藏了不少复杂度，也隐藏了很多数据质量问题，只有数据治理做到一定程度才能解决，但这是最麻烦的，是一个长期的过程。
还有一个看似小问题但值得分享的。DB2加载文本格式文件，栏位分隔符只支持一个字符，例如是
| ,如果数据本身不巧含有 |，则格式就会乱，我们生产中就时有发生，而且格式乱了DB2不一定会报错，但GBase是支持多字符的，比如空格|空格，这样字段中含有分隔符的机会就较小，别看就这么一个特性，就让入库效率高了不少，此外，数据文件中栏位多了GBase会报错，而DB2 警告都没有，所以，GBase加载文本格式比DB2更鲁棒，更有利于保障数据质量，比如某天发现GBase加载错误，提示所有数据都多了一个字段，一般就是上游系统做了表结构变更但漏了通知，而只有少数几条数据报错，就一般是数据中含有分隔符导致，我们都会通知DB2排查下异常数据。
所以，我们的双平台方案是成功的，实现了DB2和GBase和谐共存，而且通过两相比较，更容易发现各自产品的优缺点，后续我们打算更好的拓展GBase的使用，比如建立数据实验室。
先分享这些吧，如果大家有什么使用上的问题或者经验，欢迎交流。也祝愿GBase发展得越来越好。
