这里需要注意的重要一点是链式方法不一定以随机顺序出现。这些方法调用所表示的操作不是从左到右直接应用于数据的一些关联转换。
每个方法调用都可以编写为一个单独的语句，其中每个语句生成一个结果，该结果将输入到下一个操作，依此类推，直到生成结果为止。

fire_ts_df.                           
  select("CallType")                  # selects column CallType into a 1-col DF
 .where(col("CallType").isNotNull())  # Filters rows on the 1-column DF from select()
 .groupBy("CallType")                 # Group filtered DF by the one column into a pyspark.sql.group.GroupedData object
 .count()                             # Creates a new DF off the GroupedData with counts
 .orderBy("count", ascending=False)   # Sorts the aggregated DF, as a new DF
 .show(n=10, truncate=False)          # Prints the  last DF

只是用你的例子来解释为什么这不起作用，打电话给 count() 在 pyspark.sql.group.GroupedData 创建包含聚合结果的新Dataframe。但是 count() 拜访了一位 DataFrame 对象只返回记录数，这意味着下面的调用， .where(col("CallType").isNotNull()) ，是长的，这根本没有意义。long没有那种过滤方法。
如上所述，您可以通过在单独的语句中重写代码来实现不同的可视化：

call_type_df = fire_ts_df.select("CallType")
non_null_call_type = call_type_df.where(col("CallType").isNotNull())
groupings = non_null_call_type.groupBy("CallType")
counts_by_call_type_df = groupings.count()
ordered_counts = counts_by_call_type_df.orderBy("count", ascending=False)

ordered_counts.show(n=10, truncate=False)

如您所见，排序是有意义的，因为操作的连续性与它们各自的输出是一致的。
链式调用产生了所谓的fluent api，可以最大限度地减少冗长性。但这并不能消除这样一个事实：链式方法必须适用于前一个调用的输出类型（事实上，下一个操作将应用于前一个调用生成的值）。