共计 3708 个字符，预计需要花费 10 分钟才能阅读完成。
星环科技于 2021 年 3 月公布了星环极速大数据平台 TDH 的 8.0 版本。置信很多用户都对这款产品十分感兴趣。本系列文章向您逐个介绍 TDH8.0 全新性能和技术创新。帮忙企业级数据平台用户更全面、深刻地理解前沿的大数据技术，更好地技术选型。
您也能够在星环科技官网视频号、星环社区服务号、以及 bilibili、腾讯视频等站点看到咱们的视频。
往期内容:
TDH8.0 应用必读：为什么你须要存算解耦的多模型数据管理平台
TDH8.0 应用必读 2: 10 种数据模型全反对 将来属于多模型大数据平台
谈谈 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 能够帮忙客户发明更大的价值。
如果想退出咱们一起来做系统软件，欢送分割咱们，给咱们 mailto:talent@transwarp.io 投简历。
