引言

星环科技于 2021 年 3 月发布了星环极速大数据平台 TDH 的 8.0 版本。相信很多用户都对这款产品非常感兴趣。本系列文章向您逐一介绍 TDH8.0 全新功能和技术创新。帮助企业级数据平台用户更全面、深入地了解前沿的大数据技术，更好地技术选型。

您也可以在星环科技官方视频号、星环社区服务号、以及 bilibili、腾讯视频等站点看到我们的视频。

往期内容:

TDH8.0 使用必读 ：为什么你需要存算解耦的多模型数据管理平台

https://mp.weixin.qq.com/s/89xXIoMxk8saBl9EiNE17A

TDH8.0 使用必读 2: 10 种数据模型全支持 未来属于多模型大数据平台

https://mp.weixin.qq.com/s/HeL8fjX-S68eVGolbJLT0w

谈谈 TDH 的产品使命

我们从 TDH 的名字的由来讲起。TDH 全称叫做 Transwarp Data Hub，所谓 Data Hub，简单来说，就是我们想做大数据的集线器。

从 2013 年星环创立开始，我们就想提供一个大数据平台和一系列的工具，用户可以把所有的数据都汇聚起来，通过工具对数据进行操作，帮助客户企业创造价值。要想做成这件事，这个平台希望能满足以下几个需求：

首先，这是一个企业化的软件，它是由很多子模块组成的，比较复杂；

第二，我们要满足一站式的数据处理需求，能帮助用户完成一个数据处理的全链路；

第三，我们要处理多种数据模型，结构化，图数据，文本数据等等；

最后，我们要有强大的存储和计算能力，有能力帮助客户在海量数据中探索价值；

要真的去实现一个企业级，一站式，多数据模型的大数据平台，其实还是挺难的。星环大数据平台也攻克了不少技术难题，今天我们话题的围绕多模大数据平台来展开。

我记得星环 2013 年刚刚成立，那个时候大数据技术非常火热，各种大数据技术层出不穷，市场普遍对这些技术也都处于一个摸索的状态。许多同时期的大数据基础软件公司，大多都会选用一些相对成熟的开源产品直接组合成为自己的大数据解决方案，理由是许多国内外的互联网企业已经证明了这个技术可靠，那我们没必要自己再从轮子做起。

时至今日，从技术角度看，我也不认为这是一个正确的做法，特别是对于底层软件来说。

我们面临的是企业的复杂系统，我们需要承认我们所面对的问题的复杂性。直接用开源产品堆积成为的解决方案，虽然在针对性场景下都有着一定的解决能力，但是对场景的划分需要有比较专业知识。更重要的是，我们的企业客户业务发展历史是很悠久的，远远超过了互联网公司，超过大数据技术的发展。

相比较他们的业务而言，大数据技术可以解决一些痛点问题，但是不够系统。用户没办法持续，长期只利用一两个产品来持续开发。这个原因有两个，一个开源的大数据技术功能比较少，第二个是大部分开源社区还是由国外技术人员主导，国内的场景面临的问题考虑的少一些。

这和互联网公司完全不同，互联网公司没有历史业务，完全可以就着技术来进行业务的开发，所以我们不能认为开源的技术在互联网公司被验证，就一定可以应用于传统企业。

当然，时至今日，大数据技术已经被验证是可以应用于企业关键的生产系统的，这点也是星环所坚持的。但是怎么样做一个好的产品，把这些技术融入，同时又能支撑企业复杂的场景，则是一个令我和我的团队头疼不已的事情。

TDH 架构设计原则-用户第一，效率第二

首先是成本问题，作为一个创业型公司，特别是刚刚创业的头几年，我们没有足够的研发人手，所以不可能去把市面上的开源产品都拿回来研究透彻，所以我们选择的路就是一方面学习核心的大数据技术，同时产品代码尽量自主研发，并且在研发的过程中对一些技术做迭代改进。

自主研发虽然在产品构建初期，速度可能偏慢，质量上也会难以把控，但是一旦完成雏形，后续的迭代速度会很快，道理非常简单，就是你很熟悉自己的产品架构，哪里该去扩展，哪里可以重构，都非常清楚，代码的演进和迭代是在合理的规划和控制中的。引用我的一个同事的话说就是，都是自己写的代码，有啥不能实现的。

因为人手有限，平台需要的功能又比较多，所以最早在设计的时候，TDH 的整体架构模块化的是比较好的。每个研发都可以聚焦在自己的模块内工作，这样效率比较高，也好测试，有经验的研发负责人则会把接口定义的可扩展性强一些，我们也考虑到了日后需求的进一步迭代。

所以一方面外因我们面临的是复杂的企业化场景，内因上我们也想用高效的方法去实现一个自主可控的大数据平台。内外因结合，使得我们最终确定了抽象出一个统一的分布式计算引擎和统一的分布式存储引擎，再由各个产品团队来实现各自的存储结构来满足客户业务需求的这么一个架构。这样设计也为我们今天这样一个多模型的大数据平台打下了基础。

在后续的架构演进过程中，通过客户的需求也不断验证了我们这个设计的正确之处。

这里举个例子，我们在某个图数据库实施过程中，发现构建图的时候有一个点的出入度特别大，就是那种成千上万倍的大于这个图的平均出入度。我们想好奇想查一下这份原始数据，于是我们就把图数据库用的引擎通过 session 的一个热配置切换到了 SQL 的状态，发现是数据和 schema 对错了，导致大量的错误数据。 这个过程其实就是所谓统一引擎的一个好处。统一的存储引擎类似，当遇到扩缩容，磁盘损坏等情况下，不用管是什么数据模型，运维方式，命令都一样，不需要针对每个组件都学一套运维方式。且不说诸如 ElasticSearch 这样的分布式运维方式比较独出心裁的一种分布式方案，光是不同的命令套系学起来就都还要费些功夫的。 当然星环的多模大数据平台还有一些很不错的功能，比如多种模型处理可以在一个进程里，也可以独立进程使得资源使用率上比较容易调配；优秀的 SQL 的支持度可以降低业务迁移成本；统一的运维方式和理念可以让运维变得容易一些等。

团队积累 8 年的成果：TDH 架构先进性的体现

我们可以通过做一些具体的比较来说明这个问题：

一、集成式 vs 拼装式

开源社区的软件往往是针对某一个，或者几个特定场景，要支持一个企业级的需求，开源的大数据平台需要用很多组件来拼装而成。星环的大数据平台软件和开源的大数据软件栈相比，功能更为强大，架构复杂度远远低于 Hadoop 生态圈。在同等功能复杂度下，星环的组件和模块个数是远远小于开源产品的组装出来的方案的，这个是优势。

因为简单，去掉了不必要的交互。当然在功能需求单一的一些场景下的时候，目前我们的大数据平台还是偏重了一些，不过随时软件越来越成熟，我们会通过模块化等方式去瘦身，针对一些小场景做好软件的瘦身工作。

二、传统企业场景 vs 互联网场景

这个话题，之前也提到了，这里我们再细聊一下。传统企业历史悠久，比如就拿银行的场景来看，实际上业务的完善度是很高的。我们在说创造新场景创造新价值的时候，首先需要考虑兼容性。我们不能绕过原来的业务去创造新的业务，那不切实际。所以实际上，原有业务能够怎么比较顺利的迁移到 TDH 上，是我们考虑的第一个问题。

我觉得互联网和传统企业的问题，是两类的问题。在解决问题的时候，技术是可以互相借鉴的，但是不能说谁更先进或者谁更有用。这个有点关公战秦琼的意思。

TDH 在选择技术路线的时候，是比较喜欢尝试新的技术的，但是不一味地追求新，而是追求能适用。新的技术，有价值的技术，必须能够在企业应用里落地。落地是我们在做技术选择的时候最重要的一个指标。因此我们的 TDH 在技术上，用的是新的大数据技术，同时在落地上也是非常的接地气，围绕客户的需求不停的迭代，这个是良性的发展，也会逐步形成产品的核心竞争力。

三、JVM vs C Lang

技术圈的朋友其实经常面临一个选择。我直接谈我们的观点，Java，易学难精；Native 的语言，上限高一些。星环的统一计算引擎是用 JVM 为主的，而存储引擎则是 C++写的。这样的组合搭配是比较合适的目前的客户的需求的。存储引擎稳定，我们用 C++做了很好的内存模型，事务管理，同时容灾，扩容等能力也在随着版本的迭代不断的增强。计算引擎功能强大，我们在编程上，会更注意适配 JVM 的 GC 模型和 Jit，使得我们可以快速的开发出性能和功能都比较强大的计算引擎。

难点·尝试·目标·等你

在过去的一年多时间以来，为了突破几个关键性能，我们团队始终在不断尝试。其实我们从一开始想做这个结构，到把这个结构做出来，也不是一帆风顺，其实可以说是比较坎坷的。开发过程其实是一路踩坑的过程，印象比较深的就是去解决操作系统啊，JVM 等偏底层的运行环境组件的问题。当然最经典的就是和 GC 去做搏杀，不过这个实在太习以为常以至于没什么可以聊的，今天可以聊聊一个稍微偏冷门一点的故事，和 Jit 相关。 Jit 是 java 程序运行的性能关键，一段 Java 代码运行的到底如何全看 C2 编译器的表现，我们遇到过很多运行过程中性能衰减的情况，简单来说就是越跑越慢，我们通过看 jit 的汇编发现了一些问题的关键。 后面我们的工程框架设计的时候特别在意在 jit 的编译之后的表现。如果不解决这些问题，我们也没办法在同一个 JVM 里放这么复杂的功能，去支持很多种数据模型。 国产基础软件发展时间还很短，我们还有很多很多的工作要做。我们会把更多的精力投入在平台的易用性，稳定性，性能，同时也会开发更多的功能。希望 TDH 可以帮助客户创造更大的价值。 如果想加入我们一起来做系统软件，欢迎联系我们，给我们 talent@transwarp.io 投简历。