网站手机验证码注册怎么做,wordpress 有没有漏洞,如何免费创建自己的网站平台,用dw做的网站生成链接吗*作者#xff1a;郑扬勇#xff0c;云粒星河数据中台产品负责人 云粒智慧科技有限公司成立于 2018 年 6 月#xff0c;是中国联通集团混改以来成立的首家合资公司#xff0c;是中国智慧城市数智化建设者。一直以来#xff0c;云粒智慧以数字化、智能化、集约化产品为核心郑扬勇云粒星河数据中台产品负责人 云粒智慧科技有限公司成立于 2018 年 6 月是中国联通集团混改以来成立的首家合资公司是中国智慧城市数智化建设者。一直以来云粒智慧以数字化、智能化、集约化产品为核心全面融合“5G大数据AICIM”等最新技术致力于构建未来城市数字化基础设施平台打造“绿色、互联、智能”的现代化智慧城市为政企提供符合政策导向及智慧城市发展趋势的“三中台智能化应用”解决方案实现城市智脑与生态环境可持续发展。 这里说到的“三中台”其最重要的中台即云粒星河数据中台是一套集“数据建设与运营方法论、软件行业资产包和数据技术服务”的中台体系提供数据采集、融合、治理、计算、分析、服务、可视化的全链路一站式管理与服务。经过四年 4 个大版本的迭代目前已累计完成 80 客户项目的落地交付实现产品销售总额超过 1.2 亿元的好成绩。 云粒星河数据中台作为大数据处理系统数据引擎是其最重要的核心中间件。云粒星河数据中台的数据引擎一直选用开源的 Apache Hive自诞生到 3.x 系列最后一个版本。总体上 Apache Hive 是一个非常优秀、久经考验的 OLAP 引擎但在项目落地实施的过程中我们也遇到了诸多痛点导致最终交付成本偏高拉低了项目的毛利率。 痛点 1组件众多运维困难云原生化不友好 Hive 依赖 Hadoop我们使用 HDFS 存储数据YARN 作为资源管理框架Tez 优化 Hive DAG 任务由于需要高可用每个节点都需要启动好几个相关进程这些进程的配置、监控、伸缩、保活等都极大地增加了运维工作量。由于 Hive 和 Hadoop 使用的是已经老旧的按节点方式扩缩容的架构设计因此云原生非常不友好社区至今也没有提供容器化部署方案自行尝试通过 Statefulset 方式运行在 Kubernetes 中并进行性能测试发现性能竟然有 30% 以上的下降因此我们仍然使用物理机或 VM 方式部署。 痛点 2资源利用率低, 任务调优繁琐复杂 由于 YARN 是双层悲观并发资源管理调度框架经过 Tez 优化后的 Hive DAG 任务向 YARN 申请资源仍然是按固定配额vCore 和 Mem的方式进行为了能够最大化利用资源提高并发需要在项目中根据任务处理数据量情况 Case By Case 做配置调优并且随着数据中台数据处理量的不断变化通常情况是逐步增加配置调优的工作需要持续进行无法一劳永逸。 痛点 3数据处理时延大用户体验差 由于诸多原因我们没有使用 Hive 的 LLAP 特性这会导致 Hive 即使处理极小的数据量如数百条记录由于需要冷启动最低两个 YARN Container含一个 App Master至少需要数秒才能返回无法做到亚秒级交互式查询难以支持数据大屏等实时性要求较高的下游应用为了解决这个问题我们追加部署了基于 MPP 架构的 Presto 引擎解决了这个问题但这也带来新的问题即对内存资源的需求也大大增加了这种成本的增加最终还是会转变为交付成本降低项目利润。 痛点 4不支持行级更新灵活性较低 Hive 是一个为数仓而生经典的 OLAP 引擎数据更新仅支持全表/分区级覆盖极低的情况下如果需要对远景冷区部分数据进行更新处理较为麻烦另外分区设置策略也颇为费脑——粒度太大更新效率较低粒度太小又容易发生分区和小文件数据量爆炸表现为还是效率低下…… 正是由于以上一些挑战自云粒星河数据中台 3.0 大版本发布支持多引擎并行能力开始公司内部一直在寻找一款稳定可靠、AP 和 TP 兼备、能够在集约资源环境下有较高效率表现的数据引擎。 但数据引擎作为基础软件百花齐放我们如何在一堆“好”软件中最好的只有更挑选更适合自己的以及怎么判断适合云粒总结了如下五点 开源软件友好的商业 License 支持云原生 支持集群模式 支持私有化部署 有较高成熟度社区、生态等。 经过较长时间的调研和比较初步满足条件的数据引擎仅剩以下 CockroachDB、YugabyteDB、PingCap TiDB、OceanBase 四款。其中CockroachDB 社区版限制较多例如较为基础的索引功能都需要获取商业版License 解锁YugabyteDB 在内部性能测试对比过程中表现较差因此两者排除较早而对于后两款OceanBase 相比 TiDB更适合我们的点在于以下三个方面 第一OceanBase 的架构较为简洁只有 OBServer 和 OBProxy。而 TiDB 由PD、TiDB、TiKV、TiFlash 四个组件构成。如果只是部署一套集群用于内部服务那么二者的区别不大但我们需要部署和运维几十甚至上百套集群配置、部署、运维等方面用 OceanBase 较为便利。 第二OceanBase 原生支持多租户资源隔离和控制模型也比较清晰。而 TiDB 对于多租户支持很晚生产可用应该是在 V7.0至今仍处于完善阶段。云粒数据中台作为一个原生多租户系统使用 OceanBase 的多租户体验更舒服。 第三OceanBase 的生态策略感觉更开放。例如数据集成方面专门为 DataX 开发了插件更贴合我们现有技术路线。TiDB 虽然提供了更丰富的数据集成组件包含 TiCDC、TiDB Data Migration、TiDB Lightning但我们整合进产品会比较重工作量会比较大。 基于上述因素自 2021 年 OceanBase 宣布开源开始其进入我们的候选名单2022 年OceanBase 发布 4.0 版本其迭代速度和性能改进更是让我们惊叹正是那时我们果断确定产品选型并启动适配工作。 因为项目体量较大及产品功能较多且大多数都与数据引擎相关整个适配过程大概持续了两个多月完美收工。数据引擎更换为 OceanBase 后的云粒星河数据中台得到了如下优化极大缓解甚至消除了之前的痛点。 优化 1更简介的架构更好的云原生 左-更换前HivePresto右-更换后单一OceanBase 从上图可以看出相比 Hive 引擎OceanBase 只需要在每个节点上启动 OBProxy 和 OBServer 两个进程即可通过 Prometheus 导出 Metrics监控运维便捷省力。得益于架构的简洁OceanBase 很容易实现云原生化官方已提供在 Kubernetes 中部署运行的详细方案这对云粒星河数据中台本身实现彻底云原生化至关重要。 优化2让每一核 CPU 发挥最大价值 私有化环境交付客户能够提供的资源不足已经是“家常便饭“这就要求云粒星河数据中台必须具备“螺蛳壳里做道场”的能力即在较低资源配置下也能有良好的处理能力表现。例如我们甚至遇到个别客户仅提供三台 8C32GB 规格的服务器部署数据引擎。以往采用 Hive 结合 Presto 作为数据引擎。部署完各类组件每个节点能够提供给 YARN 调度的内存往往就只剩下 10GB 左右每个作业Job还需要启动一个独立的用于协调的AppMaster通常占用 1GB 内存使得在小数据量高并发场景下的性能表现雪上加霜。 前文也提到需要对于 YARN 资源分配的参数反复调校费时费力。采用 OceanBase 作为数据引擎后单租户模式下为 OBProxy 分配 2GB 内存系统租户和租户 META 租户各分配 3GB 内存剩余内存全部用于租户本身通过试验小数据量场景单次处理数据量低于 1GB并发能力相比 Hive 有十数倍提升在较大的数据量单次处理数据量超过 10GB场景下也能做好处理轻松榨干 CPU 每一核。 优化 3数据治理从分钟级到准实时 准实时数据治理单次需要处理的数据量往往都较小得益于高效的分布式计算调度和数据存储结构即使是逻辑较为复杂的数据治理 SQLOceanBase 也能游刃有余地快速完成以下是测试数据治理工作流执行时间对比它由一个数据接入节点和两个数据更新写入节点构成每次处理的数据量接近 1GB资源配置同为三台 8C32GB 服务器集群。 Hive OceanBase 数据接入 21s 14s 数据更新1两个表关联 24s 1s 数据更新2五个表关联 39s 10s 可以看出OceanBase 在小数据量场景下各方面的时延都远低于 Hive。而相比定位为单一 OLAP 引擎的 Hive定位为 HTAP 引擎的 OceanBase 在 TP 方面的诸多优势不再赘述对于冷数据行级更新更不在话下。 当然对于团队中习惯使用 Hive 做数据交付的同学在使用 OceanBase 的过程中也有少量感觉不太方便的地方主要有两点 第一OceanBase 不支持 Insert Overwrite还好可以使用 Truncate/Delete Insert 曲线支持问题不大 第二OceanBase 不支持使用 List 分区策略时动态分区因此每次插入数据时都需要检查对应的分区是否存在如果不存在则需要先 ALTER TABLE· ADD PARTITION很不方便希望未来能尽快支持。 另外不可否认当单次需要处理的数据量上升到一定级别如 100GB 以上凭借 ORC 或 Parquet 列存格式优势Hive执行数据分析的性能表现是优于 OceanBase 的不过可喜的是列存计划已列入产品 roadmap希望在不久后可以看到更强的 AP 性能能力。 目前更换为 OceanBase 作为数据引擎的云粒星河数据中台 4.0 已经在项目上实施落地。总的来说OceanBase 更简洁的架构、更轻便的运维帮助我们加速了数据中台云原生的进程提升资源利用率的同时并发性能提升 10 倍数据处理时延降低 1.5-24 倍。这带来的直观效益是机器成本与运维人力的节约进而带来了 20% 的毛利率提升。 非常感谢 OceanBase 贡献优秀的数据引擎希望它能越做越好成为数据引擎领域“国产之光”向世界展现中国技术实力
