架构师公众号推送了一篇文章，一上来就拿数十个提升sql性能的实战例子，引入了spl （Structured Process Language）集算器，花30分钟浅尝辄止。 顾名思义，集算器，侧重‘集’+‘算’，将 数据集 结合 本地计算，产生结果。所以是非分布式的，所以场景有限。以下是结论。 场景：用于跨数据源查询（join/union） 或 大数据量复杂查询优化（使用游标load to file，再由spl提供的算子分析查询） 竞品：pandas/numpy 优点：代码量较小，适合不熟悉python的用户，否则还是上python或使用可视化平台，如redash/davinci 缺点：单点，质量不可控，社区不活跃 使用对象：分析师 提升示例 https://mp.weixin.qq.com/s/iFdZr1mhBSdYhfPd94OnaQ 产品介绍 http://www.raqsoft.com.cn/p/esproc-spl https://cloud.tencent.com/developer/article/1930545 https://www.modb.pro/db/430573 源码 https://github.com/SPLWare/esProc
最近比较少有精力更新博客，热情锐减可能是一部份原因。 https://archsummit.infoq.cn/2022/shenzhen/schedule 2022架构师峰会 2021的资料ppt https://www.modb.pro/topic/67021 2021年ppt 2022 data summit ppt https://www.modb.pro/topic/411230
https://xie.infoq.cn/article/fad821a83e19c6478458e0b03 https://cloud.tencent.com/developer/article/1791911 https://aws.amazon.com/cn/blogs/china/application-and-actual-combat-of-new-features-of-apache-spark-3-0-in-freewheels-core-business-data-team/ trino cbo https://trino.io/blog/2019/07/04/cbo-introduction.html spark cbo https://docs.databricks.com/spark/latest/spark-sql/cbo.html spark cbo http://www.jasongj.com/spark/cbo/ 升级的成本考量：每个公司的大数据架构不一，统一的架构管控更能够适应这种计算引擎的升级。参考上文freewheel的数据平台，它做spark升级较为容易。 有没有必要升级，是基于公司成本和迁移难度的考量。spark 3.0提供的很多优秀特性，可以提高集群的资源利用率，同时提高数据处理效率。如果是云上的集群，确实可以节约可观的成本。 AQE解决了历史性难题。所以Flink和Spark哪个好，老生常谈。做流式做了4年多，总结到，批量还是看spark，spark streaming基本上大多数业务场景spark完全cover了，没必要上技术要求比较高的flink，flink对开发人员的水平要求目前还是太高了。flink checkpoint用的好不好，决定着lambda是否还是需要建设，可以肯定的是基本上二线城市或二线公司没有这个能力完全流批一体。
windows环境，开发桌面应用有强大的QT。熟悉Java、Scala不熟悉C++的同学该怎么办，入门QT？ 除了这个办法，可以看一下SWT, IBM提供的eclipse ui库。对标ORACLE的AWT。 Standard Widget ToolKit。 基于它开发的，有Eclipase IDE，也有最近火爆的数据库管理工具，Dbeaver，开源、基本上纯Java开发。浏览代码，记得github打开主页，点一下键盘的“.”。
why schema? 引用Jay kreps的话，关于topic的schema。原文见《Why Avro for Kafka Data?》。 one thing you’ll need to do is pick a data format. The most important thing to do is be consistent across your usage。 json虽然表达能力强，但冗余，尤其对于kafka这类数据存储。 引入序列化协议及schema注册中心，可以优化数据存储、支持schema evolve，保证生产消费对同个字段的相同解析，简化etl处理。 但也有折衷，引入注册中心无于多了组件，如果registry宕机，kafka 不可用。所以很多公司不会使用json，而是使用自已约定的消息格式，除非像一些传统公司技术能力欠缺或者kafka消息体量很小还不考虑吞吐和性能问题，当然也有可能公司不差钱。 confluent官方提供了schema registry，用于schema的注册等级，生产消费都会从它那里登记或获取消息序列反序列化schema。 官方支持的schema类型有avro,json,protobuf，推荐avro，原因见上面的链接，摘要如下 We chose Avro as a schema representation language after evaluating all the common options—JSON, XML, Thrift, […]
