分享云原生大数据技术和个人成长、职业发展相关内容

云计算的出现标志着从在本地服务器上交付和执行软件，转向共享数据中心和基于云的软件即服务 (SaaS) 解决方案。云共享基础架构承诺实现规模经济、极端可扩展性和可用性，并采用按使用量付费的成本模型来适应不可预测的使用需求。但是，只有当软件本身能够弹性地扩展到云资源池时，才能利用这些优势。传统数据仓库解决方案早于云计算。它们旨在运行在小型静态群集上，这使它们成为较差的体系结构选择。

其次，对于像HDFS这种分布式文件系统来说，为了控制数据同步的速率，可以通过DN的bandwith来控制台数据复制的带宽大小，如果服务本身的这种带宽限制比较小的话呢，也会影响数据同步的效率，所以一般而言，要根据整个集群的规模大小，所处的场景是单纯存储还是单纯计算还是存储和计算都有，如果是单存储场景的话，那么这个值就建议调大一些，可以放到Gb级别（注意：HDFS里面的带宽单位是大B，一个Byte等于8个bit，通常网卡传输是bit来传输的）当进行数据持续大量导入的时候，那么这里我们就要面临几个问题？

本文重点从基础性能方面对Starorcks进行了再不同规格、不同资源类型、不同并发下面的性能对比，从而也验证了在CPU和内存配比方面，1:4的配比是更为合适的资源配比，这对于Starorcks的资源选型方面提供了一定参考意义。后面我们还有对于Starrocks不同特性开启之后，对于读写性能的提升，比如异步物化视图、查询队列、中间结果落盘、Pipeline Engine 、QueryCache等相关特性的提升来输出相关报告如果想进一步交流的话，欢迎加我 V：kubedata分享创造价值、交流促进成长。

我们发现Kubernetes 并不是一定就比Hadoop Yarn的调度能力要好，甚至在兼容性、数据本地存储、权限限制等方面也存在诸多不足，OK，回归到技术架构设计的根本问题就是：适合OR不适合？怎么来判断是否适合做云原生化建设？可以建议你从一下几个方面来综合考虑：集群规模是否足够大：集群规模足够大之后，从数据跨区域存储、集群容错性、计算作业跨区域调度、数据存储成本。

在实际工作中，我们应该如何选择使用OLTP数据库还是OLAP数据仓库还是数据湖呢？有些同学会追求时髦前沿技术，不管业务需求是什么样的，直接就上数据湖架构，这样其实是一种不负责任的表现，单纯的以自己实践为主，业务需求为次的行为。这时候就需要架构师来评估具体业务的场景以及未来发展（2-3年）来看，最适合的架构模型是那种，而不是直接就上新技术，一般技术在2-3年会有一个迭代周期，你无法保证现在选择的技术栈未来看就是最优的。那么我建议从一下几个方面来进行选择

本文详细讲解了关于大数据离在线混部的背景，简单来讲，就是将多个应用服务部署在同一个节点中，提升节点的CPU和内存资源的利用率，将机器效能发挥到最大，帮助企业能够最大化的提升IT资源的利用率，从而减少IT资源成本投入，起到降本增效的作用

本文详细讲解了数据平台构建的背景，并深入讲解了基于hadoop生态构建数据平台所面临的问题，最后基于云原生技术如何构建数据平台，本文给出了详细的方案。